| Summary: | dhclient and dhclient-script do not send arping before sending DHCPACK reply to dhcp server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Justin I. Nevill <jnevill> | ||||
| Component: | dhcp | Assignee: | Jiri Popelka <jpopelka> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.1 | CC: | jpopelka, ljozsa, mdimaio, mganisin, ovasik | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | dhcp-4.1.1-27.P1.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 758766 (view as bug list) | Environment: | |||||
| Last Closed: | 2012-06-20 12:43:43 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 756082, 761078 | ||||||
| Attachments: |
|
||||||
|
Description
Justin I. Nevill
2011-11-08 15:44:07 UTC
Yes, the problem is reproducible. The reason why nobody has noticed the problem so far is that the server itself does some testing (sends ICMP ECHO_REQUEST) before it offers (DHCPOFFER) the address to client. So the duplicate address detection (DAD) is usually not necessary on client side, because the server detects already used address before DHCPOFFERing it to client. The reason why you noticed the problem is that in case of client rebooting the server doesn't send DHCPOFFER, only (N)ACK. Yes, we should fix it because RFC 2131 says that the client SHOULD perform some check and MUST send DHCPDECLINE if the address received in DHCPACK is already in use. So we should add an arping in BOUND|RENEW|REBIND|REBOOT section (the ARPCHECK|ARPSEND is blind alley). Everything in dhclient code is ready for this. But note that this will only influence dynamically assigned addresses (i.e. defined with 'range' statement on server), because only these addresses can be marked (as a result of receiving DHCPDECLINE) as abandoned on server. Statically assigned addresses (i.e. defined with 'fixed-address' statement on server) won't be marked as abandoned. That's how it's designed. So in your case (the steps to reproduce) the client will send DHCPDECLINE and restarts configuration process but then it gets the DHCPOFFER with the same address as previously because it's statically assigned address. So it will be restarting the process of obtaining address via dhcp forever. On the other side this is much better (to detect where the problem is) that blindly using address that's also in use by some rogue (user who refuse to follow your address management policy) machine. In case of dynamically assigned address everything should be ok, i.e. client sends DHCPDECLINE and restarts the configuration process, server marks the address as abandoned and offers client other address. Created attachment 532635 [details]
dhclient-script: arping the address in BOUND|RENEW|REBIND|REBOOT
Verified on RHEL6.3-20120411.1, dhcp-4.1.1-30.P1.el6.x86_64. The client station now sends DHCP Decline if the offered address is in use. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0793.html |