Hide Forgot
Description of problem: dhclient and dhclient-script do not try an arping before sending DHCPACK reply to DHCP server. Version-Release number of selected component (if applicable): dhclient-4.1.1-19.P1.el6_1.1x86_64 How reproducible: 100% Steps to Reproduce: 1) configure client1 to use dhcp 2) create a ip/mac reservation on DHCP server for above client1 3) boot client1; shutdown client1 5) statically assign client2 same ip as client1 and boot 6) reboot client1, both servers now have same conflicting IP Actual results: Client1 DHCPACKs an offer for an IP that is already in use. Expected results: Client1 DHCPDECLINEs an offer for an IP that's already in use. Additional info: Code is in place in /sbin/dhclient-script (Look for ARPCHECK or ARPSEND) but $reason for performing arping is never sent to dhclient-script.
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