Issue with losing static IP because of a non standard ARP request (who has).

[chuck-forbish]

Non standard as "Sender IP address" in ARP packet is "0.0.0.0".

There seems to be an issue with an altered ARP probe (who has). Altered as the requester has no ipv4 address so the "Sender IP address" is 0.0.0.0 in the ARP packet. This causes dhcpcd to give up a static IP and we lose connection as we get two of these packets in less than 10 seconds.

Attached is 5_packets_share.pcap that we have permission from the customer to share with you. Attached is a demo_issue.py that uses python scapy to reproduce the issue. I run this script on an Ubuntu box where I have sudo privileges. Also attached is dhcpcd.log that came from running the script (customer's logs look the same).

Customers report that older versions of dhcpcd code did not have this issue in the same environment. I notice that these versions do not have the "arp_read: eth0: Resource temporarily unavailable" entry in the log.

We have a change that filters for the broadcast "Target MAC Address" in the ARP packet, but are unsure if this is the correct change.

5_packets_share_pcap.log
demo_issue.log
dhcpcd.log

[rsmarples]

I've looked at the packets.
The only non standard thing about them is that the target MAC address in the ARP payload is the broadcast MAC address.
It SHOULD be all zero's. That's not a fixed requirement though because we ignore the field here.

RFC 5227

A host probes to see if an address is already in use by broadcasting
an ARP Request for the desired address. The client MUST fill in the
'sender hardware address' field of the ARP Request with the hardware
address of the interface through which it is sending the packet. The
'sender IP address' field MUST be set to all zeroes; this is to avoid
polluting ARP caches in other hosts on the same link in the case
where the address turns out to be already in use by another host.
The 'target hardware address' field is ignored and SHOULD be set to
all zeroes. The 'target IP address' field MUST be set to the address
being probed. An ARP Request constructed this way, with an all-zero
'sender IP address', is referred to as an 'ARP Probe'.

Now, lets look at what else you said.

Customers report that older versions of dhcpcd code did not have this issue in the same environment. I notice that these versions do not have the "arp_read: eth0: Resource temporarily unavailable" entry in the log.

Older versions may not have supported ARP ACD or may have a bug or may have an exclusion somehow. You not said which versions don't trigger this ARP condition.

Please open a separate issue for arp_read: eth0: Resource temporarily unavailable so we can look at that by itself and see if we can fix it. Attach the dhcpcd.log you have here there please, or reference this issue.

We have a change that filters for the broadcast "Target MAC Address" in the ARP packet, but are unsure if this is the correct change.

Well, according to the RFC we should ignore the "Target MAC Address" field as the contents don't matter.

From dhcpcd's perspective it's trying to defend it's IPv4 address, it fails to do this and so drops the DHCP lease. This is correct behavior as per the RFC. If customers are reporting this, there are some possible solutions:

1. Remove the node sending these probes from the network
2. Stop the node sending these probes in the first place - bonus points, work out why!
3. Use the noarp setting in dhcpcd.conf so that dhcpcd will no longer defend its lease from the node

Note that 3 is the official solution to the problem your filter change also fixes.

One benefit of this is that I've used this data to open a wireshark bug because they think it's not an ARP probe as well.

Thoughts?

[chuck-forbish]

Thank you Roy for the quick response. I think dhcpcd is a really nice piece of software.

I have logged issue 481 for the "arp_read: eth0: Resource temporarily unavailable" issue, per your request.

To answer your questions:

1. Remove the node sending these probes from the network
The nodes in question are a key part to this customers network so there is push back.

2. Stop the node sending these probes in the first place - bonus points, work out why!
We are working with the switch provider to understand why these packets are getting generated. Either to have them modify the packets or stop sending them altogether.

3. Use the noarp setting in dhcpcd.conf so that dhcpcd will no longer defend its lease from the node.
Just experimented with this causes our device to not send out ARP Announcements or ARP Probes.

I noticed that I failed to say this involves a static IP.

Since this is a static IP and RFC 5227 section 2.4 part c says:

If a host has been configured such that it should not give up its address under any circumstances (perhaps because it is the kind of device that needs to have a well-known stable IP address, such as a link's default router or a DNS server) then it MAY elect to defend its address indefinitely.

Can we get a runtime configurable option to not drop the address if the connection is from a static IP?

[rsmarples]

Thank you Roy for the quick response. I think dhcpcd is a really nice piece of software.

Thanks :)

I have logged issue 481 for the "arp_read: eth0: Resource temporarily unavailable" issue, per your request.

This is now resolved.

To answer your questions:

1. Remove the node sending these probes from the network The nodes in question are a key part to this customers network so there is push back.

2. Stop the node sending these probes in the first place - bonus points, work out why! We are working with the switch provider to understand why these packets are getting generated. Either to have them modify the packets or stop sending them altogether.

3. Use the noarp setting in dhcpcd.conf so that dhcpcd will no longer defend its lease from the node. Just experimented with this causes our device to not send out ARP Announcements or ARP Probes.

Well yes. Disabling ARP will do that.
But also it will ignore any incoming ARP probes for your address and thus not defend or drop.

I noticed that I failed to say this involves a static IP.

Since this is a static IP and RFC 5227 section 2.4 part c says:

If a host has been configured such that it should not give up its address under any circumstances (perhaps because it is the kind of device that needs to have a well-known stable IP address, such as a link's default router or a DNS server) then it MAY elect to defend its address indefinitely.

Can we get a runtime configurable option to not drop the address if the connection is from a static IP?

That's fair.
I've been testing with a static IP too because it's easy and it just infinite loops now which isn't great either.

Could you open a new issue on this please and we'll keep this one just about your the nefarious node ARP probe.

[chuck-forbish]

Roy,

Thank you again. The new issue is:
Enhancement to have runtime option to allow for using part c of RFC 5227 section 2.4 for static IP addresses.