dhcpcd-discuss

Re: dhcpcd kills all connections on Wi-Fi roaming between access points

Boris Krasnovskiy

Mon Dec 07 22:18:26 2020

Hi Roy,

I did some investigation, and the Roaming event is actually clearly
indicated by the Wi-Fi stack.
CARRIER events in the dhcpcd are indicated but IFF_RUNNING flag, that is
not quite correct for Wi-Fi.

The way it works is:
- when IFF_RUNNING drops, but IFF_LOWER_UP stays Up it is the Roaming event
- when IFF_RUNNING and IFF_LOWER_UP drop, it is the Disconnect event.

I appreciate the conversation about making sure the IP is validated on the
Network, but it seems for Wi-Fi it should be the supplicant job to
determine if one is on the same network, not dhcpcd.

I tried roaming scenarios and did not observe kernel dumping IPv6
addresses.
And by description it should not be during the Roaming event interface
stops Running, but never transitions into down state.

Rebuilding the routing tables in dhcp_abort, does cause IP address discard,
once I disable that it works correctly

I still hope you will be interested in fixing the issue.

On Mon, Dec 7, 2020 at 10:19 AM Roy Marples <roy@xxxxxxxxxxxx> wrote:

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


-- 
Thank you,
Boris Krasnovskiy

Follow-Ups:
Re: dhcpcd kills all connections on Wi-Fi roaming between access pointsRoy Marples
References:
dhcpcd kills all connections on Wi-Fi roaming between access pointsBoris Krasnovskiy
Re: dhcpcd kills all connections on Wi-Fi roaming between access pointsRoy Marples
Archive administrator: postmaster@marples.name