dhcpcd-discuss

Hi Boris

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 :)

https://serverfault.com/questions/842542/why-are-ipv6-addresses-flushed-on-link-down

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.

Roy