dhcpcd-discuss

Hi Roy,

I'm running into an issue whereby dhcpcd declines a valid IP address from the dhcp server because of a well timed ARP probe from our Cisco switch with a source IP of INADDR_ANY. Our Cisco switch has IP Device Tracking<http://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html> enabled, which is sending ARP probes with a SIP of 0.0.0.0 to all devices every 30 seconds. In the below log, you can see that after dhcpcd gets the offer and starts probing, it encounters a conflict with hardware address ac:7e:8a:18:ef:90 (the Cisco switch).

Jun 15 15:32:48 DUID 00:01:00:01:20:d5:65:20:00:16:25:10:4e:aa
Jun 15 15:32:48 eth0: IAID 25:10:4e:aa
Jun 15 15:32:48 eth0: delaying IPv6 router solicitation for 0.0 seconds
Jun 15 15:32:48 eth0: delaying IPv4 for 0.2 seconds
Jun 15 15:32:48 eth0: soliciting an IPv6 router
Jun 15 15:32:48 eth0: sending Router Solicitation
Jun 15 15:32:49 eth0: using ClientID 01:00:16:25:10:4e:aa
Jun 15 15:32:49 eth0: soliciting a DHCP lease
Jun 15 15:32:49 eth0: sending DISCOVER (xid 0x796e288d), next in 3.9 seconds
Jun 15 15:32:49 eth0: offered 172.18.1.127 from 172.18.2.10
Jun 15 15:32:49 eth0: sending REQUEST (xid 0x796e288d), next in 3.9 seconds
Jun 15 15:32:49 eth0: acknowledged 172.18.1.127 from 172.18.2.10
Jun 15 15:32:49 eth0: probing address 172.18.1.127/24
Jun 15 15:32:49 eth0: probing for 172.18.1.127
Jun 15 15:32:49 eth0: ARP probing 172.18.1.127 (1 of 3), next in 1.5 seconds
Jun 15 15:32:50 eth0: ARP probing 172.18.1.127 (2 of 3), next in 1.3 seconds
Jun 15 15:32:52 eth0: ARP probing 172.18.1.127 (3 of 3), next in 2.0 seconds
Jun 15 15:32:52 eth0: hardware address ac:7e:8a:18:ef:90 claims 172.18.1.127
Jun 15 15:32:52 eth0: sending DECLINE with xid 0x796e288d
Jun 15 15:32:52 eth0: sending Router Solicitation
Jun 15 15:32:53 eth0: soliciting a DHCP lease

I saw that in 7.0.0 development, you changed some of the checks in dhcp_arp_conflicted() to ignore ARP conflicts that have a SIP of 0 and a matching TIP (commit eadb413f660c<https://dev.marples.name/rDHCeadb413f660cbfe456820b58ff9c81c502c6c9c7>). However, there remains one more check in that function that still considers a SIP of 0 and matching TIP.

/* RFC 2131 3.1.5, Client-server interaction
* NULL amsg means IN_IFF_DUPLICATED */
if (amsg == NULL || (state->offer &&
   (amsg->sip.s_addr == state->offer->yiaddr ||
   (amsg->sip.s_addr == 0 &&
   amsg->tip.s_addr == state->offer->yiaddr))))

Would it make sense to remove that (amsg->sip.s_addr == 0 && amsg->tip.s_addr == state->offer->yiaddr) just like the other conditionals in this function? It seems like receiving an ARP probe for the address we just got offered shouldn't trigger a DHCP decline.

-RJ Ascani