Re: dhcpcd kills all connections on Wi-Fi roaming between access points
Boris KrasnovskiyTue Dec 08 23:56:41 2020
and sorry, I mis-spoke your patch does not work even for the simplest
roaming case, the route still get deleted on roaming.
The patch I sent you earlier does work.
On Tue, Dec 8, 2020 at 3:21 PM Boris Krasnovskiy <borkra@xxxxxxxxx> wrote:
> Hi Roy,
> thank you for the patch. It does work, in a simplest scenario, like
> roaming between 2.4 and 5 GHz on the same router, although it does not for
> the enterprise networks.
> There is another function that needs to be there, on the roaming event it
> is prudent:
> - abort any in-progress DHCP/RA negotiations
> - force the RENEW request for the IP addresses on reconnect
> The problems are:
> - After the roaming client is connected to a different access point, which
> is a different network device, with different IP and MAC so routing needs
> to change on the infrastructure side. That process takes time and effort,
> together with the time client was not accessible during roaming itself. So
> likely DHCP/RA messages got lost during disruption. As such it would
> be much faster not to wait for the DHCP timeout, but just force restart
> DHCP/RA negotiation.
> - There is a network misconfiguration (in modern days it's extremely rare
> to see it), where after roaming you endup on a different subnet of the same
> I attached the patch that implements this functionality and according to
> our testing works well.
> On Tue, Dec 8, 2020 at 12:15 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>> Hi Boris
>> On 07/12/2020 22:18, Boris Krasnovskiy wrote:
>> > 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
>> > - 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
>> > 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
>> > And by description it should not be during the Roaming event interface
>> > 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.
>> Attached is a patch to try and deal with this.
>> It does this by ignoring interface flags without IFF_RUNNING but with
>> IFF_LOWER_UP set in link_netlink().
>> Otherwise, a lack of IFF_RUNNING is treated by dhcpcd as down by dhcpcd.
>> The only downside of this approach is that if the netlink socket
>> overflows any
>> interfaces in the roaming state will then be marked down. Hopefully this
>> I've not tested this at all really and will do so on the one machine I
>> Linux on baremetal with a wireless interface (yay, Pinebook) but that
>> might take
>> a few days to find.
>> As such I'd appreciate any testing on this by list members if at all
>> with both wired and wireless interfaces.
> Thank you,
> Boris Krasnovskiy
Archive administrator: firstname.lastname@example.org