dhcpcd5 "10 second defence" takes zero time
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Raspbian |
New
|
Undecided
|
Unassigned | ||
Bug Description
dhcpcd5 version 1:8.1.2-1+rpt1
Raspberry Pi OS buster
I have two routers/wifi access points, with one providing a DHCP service and the other bridging its wifi network so that all hosts can talk to each other. I have several Raspberry Pis, each of which may connect via ethernet, or either wifi network, or some combination. Because the raspberry pi antenna is very weak and the environment is noisy, they very frequently drop packets, lose signal, and reconnect.
I'm finding that frequently (up to tens of times per day per host) the pis come to believe that their IP address has been "claimed" by another host. In fact the MAC address is that of the bridging router. I believe they are seeing their own ARP messages re-broadcast (possibly delayed) by the bridging router, and misreading that as coming from the router itself.
But never mind that, this bug report is about this:
Aug 9 19:40:01 localhost dhcpcd[486]: wlan0: hardware address XX:XX:XX:XX:XX:XX claims 192.168.2.165
Aug 9 19:40:01 localhost dhcpcd[486]: wlan0: defended address 192.168.2.165
Aug 9 19:40:01 localhost dhcpcd[486]: wlan0: hardware address XX:XX:XX:XX:XX:XX claims 192.168.2.165
Aug 9 19:40:01 localhost dhcpcd[486]: wlan0: 10 second defence failed for 192.168.2.165
Aug 9 19:40:01 localhost dhcpcd[486]: wlan0: deleting IP address 192.168.2.165/24
There are no previous messages from dhcpcd for minutes beforehand. The intention seems to be that dhcpcd notices another host using its address, attempts to "defend" it with an ARP message, then waits 10s for the defence to be confirmed. But in fact you can see it gives up immediately.
Looking at the upstream repo, I *think* this bug may have been fixed in version 8.1.3:
commit ae46ddb6423ac5e
Author: Roy Marples <email address hidden>
Date: Wed Jan 22 16:32:09 2020 +0000
ARP: Fix defend time check
However, I haven't been able to build from sources to check <https:/
| Matthew Exon (ubuntubugs-mexon) wrote | #1 |
This bug should be closed. It was due to a misunderstanding on my part.
The "10 second defence" means that if two conflicting ARP packets from another host arrive within 10 seconds, then the lease should be abandoned. In my case the two packets are arriving immediately. I previously misread this behaviour as sending a defence, and expecting that "defence" to last 10 seconds.
I still have weird problems with my network, so I will keep looking for another solution.