Bug 81887
| Summary: | dhcpd sends ACK to a renew request received on wrong interface | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <jrover> |
| Component: | dhcp | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-01-14 22:04:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
DHCP information: redhat 7.1, kernel: 2.4.2-2 dhcp-2.0p15-4.src.rpm Please check Current release of dhcp 3.0 to see if this solves the problem I believe adding an: authoritative; line to the beginning of dhcpd.conf causes the NAKs to be sent out if renew requests are receieved from clients w/ IPs from other subnets. This functionality is present in the release mentioned, so upgrading is not necessary (although I did so). |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Description of problem: DHCPD sends ACK on a renew request on a pool not assigned to an interface whereas it should send out a NAK. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: configure a dhcp server w/ multiple interfaces (in this case 5) create pools of addresses for 4 of the 5 and no pool for the 5th. 1. acquire an address from eth0, e.g. 134.134.16.25 2. Disconnect from eth0 network 3. Connect to eth1 network. 4. Client sends a renew 134.134.16.25 to dhcp on eth1 Actual Results: 5. DHCP responds with an ACK out eth1 for 134.134.16.25 Expected Results: DHCP should have sent a NAK out eth1 to the client, then the client would initiate discovery. Additional info: Also seen the ACK and/or NAK getting sent out eth0 and eth4. eth1 and eth4 share an IRQ, all other adapters have their own IRQ. Is there an update that takes care of this issue?