dhcpcd-discuss

Hi RJ

On 15/06/2017 18:51, 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: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.

No, it would not make sense.
Here is some text copied from the URL you referenced:

============================================================================
Known Issue

The 'keepalive' probe sent by the switch is a L2 check. As such from the
switch's point of view, the IP addresses used as source in the ARPs are
not important: this feature can be used on devices with no IP address
configured at all, so the IP source of 0.0.0.0 is not relevant.

When the host receives this messages, it replies back and populates the
destination IP field with the only IP address available in the received
packet, which is its own IP address. This can cause false duplicate IP
address alerts, because the host that replies sees its own IP address as
both the source and the destination of the packet; refer to the
Duplicate IP Address 0.0.0.0. Error Message Troubleshoot article for
more information about the duplicate IP address scenario.
============================================================================

Roy