dhcpcd-discuss

On 26/03/2019 20:10, Marcin Cieslak wrote:
> (Reviving old thread for the archives)
>
> On Thu, 15 Jun 2017, RJ Ascani wrote:
>
> > 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:52 eth0: hardware address ac:7e:8a:18:ef:90 claims 172.18.1.127
>
> We have observed dhcpcd (6.11.5-1rpt7 for Raspberry PI) reporting ARP conflicts
> when the Cisco IP Device Tracking is used even with a fully static dhcpcd configuration.
>
>  From a little sniffing we have done it seem that although Cisco IP Device Tracking
> ARP probes are being sent with the source IP of 0.0.0.0, they are sent via Ethernet
> unicast to our device's MAC address and not broadcast, so maybe we can ignore them this
> way?

You are talking about Unicast Poll, RFC 1122

To remain compliant with RFC 5227 we would need to inspect the L2 frame 
to see if it's broadcast or not. So we would need to do this at the BPF 
level and not the ARP code itself.

This is more complex and will only work for frame types dhcpcd knows 
about - currently only ethernet. But this should be fine as IPDT only 
works on ethernet I think.

Any dhcpcd patch for this will go into dhcpcd-7 as that has much better 
BPF support at the frame level than -6.
I'm also not sure when I can look into this myself, maybe a few weeks.

> Neither static ifconfig on Linux nor static IP configuration on FreeBSD generates
> false positive ARP warnings in this case, maybe dhcpcd is a bit overzealous here?

The only OS I know of that supports RFC5227 in the kernel is NetBSD.
I wrote it, and there is an exclusion for what I said above, but as it's 
in the kernel it's easy as the mbuf has the M_BCAST flag set by the link 
layer.
https://nxr.netbsd.org/diff/src/sys/netinet/if_arp.c?r2=%2Fsrc%2Fsys%2Fnetinet%2Fif_arp.c%401.242&r1=%2Fsrc%2Fsys%2Fnetinet%2Fif_arp.c%401.241

So please don't base dhcpcd being overzealous on kernels that don't even 
support the feature :)

Roy