Re: dhcpcd kills all connections on Wi-Fi roaming between access points
Roy MarplesMon Dec 07 15:19:00 2020
On 05/12/2020 11:24, Boris Krasnovskiy wrote:
The problem here is that dhcpcd destroys routes on CARRIER up/down events, that
maybe correct for the Ethernet. For Wi-FI though Carrier Up/Down events
generated on roaming from one access point to the other even on the same
network, destroying routes during roaming is very bad as it is destroying all
the TCP connections. The desired behavior is to preserve routes on carrier
up/down for Wi-Fi connections, but issue RENEW/REQUEST on carrier up.
dhcpcd behaves like this for good reasons!
Plenty of RFCs specify that a network address should be verified before it is
used. This is either during initial setup or if the link state changes.
dhcpcd cannot say to the OS "Hey, stop using this address until it can be
verified", so it takes the route of safety and deletes it and associated routes
until it can be verified.
I noticed NOCARRIER_PRESERVE_IP setting in the code that seems to do a similar
thing, but it is disabled and it is global. I would greatly appreciate it if you
could provide a solution to the problem.
The solution to the problem is to use NetBSD as your OS :)
NetBSD-8 shipped with full kernel support for IPv4 and IPv6 address verification.
When the interface link state goes down, the address is marked as DETACHED and
the kernel will silently discard data sent through it or any associated routes.
Once the link comes up again, it will move the address to the TENTATIVE state
until address verification is completed at which point data will flow once more.
This is exactly the solution you need.
But it's not :)
So Linux by default will flush any addresses added by RA or DHCP6 (basically any
address with a lifetime) when carrier goes down. This matches dhcpcd behaviour!
So, the solution to your problem is to really improve your roaming
infrastructure to avoid carrier down events.
Archive administrator: firstname.lastname@example.org