Hide Forgot
+++ This bug was initially created as a clone of Bug #752116 +++ 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. --- Additional comment from Jiri Popelka on 2011-11-09 19:32:32 CET --- 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 538661 [details] dhclient-script: arping the address in BOUND|RENEW|REBIND|REBOOT
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 5, and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.