RE: dhcpcd kills all connections on Wi-Fi roaming betweenaccesspoints
Boris KrasnovskiyThu Dec 24 06:43:00 2020
> In previous emails you've indicated that in the roaming state it never actually
> goes down, just back up again which could take time to find an AP. As such,
> you'll have a hard job convincing me that the working ethernet you just plugged
> into should not take precedence by default.
If Ethernet would always take precedence it would be ok, but that was not what happened.
Before roaming Wi-FI took precedence after Ethernet.
In the particular test, I did not have ‘-m’ set, not sure what are the defaults.
Yes, using route metric, if non set on the command line is ok.
But if metric specified on the dhcpcd command line it should be used.
From: Roy Marples
Sent: Thursday, December 24, 2020 1:29 AM
To: Boris Krasnovskiy
Cc: bls s; dhcpcd-discuss@xxxxxxxxxxxx
Subject: Re: dhcpcd kills all connections on Wi-Fi roaming betweenaccesspoints
On 24/12/2020 03:43, Boris Krasnovskiy wrote:
> HI Roy,
> sorry, my mistake, I used a config file with disabled DNS options.
> The code partially works, the problem is: after roaming DNS interfaces get
> reordered, and this is incorrect.
> DNS interfaces should be ordered according to their metric always.
The rules are these: Precedence list, fallthrough on equality:
In previous emails you've indicated that in the roaming state it never actually
goes down, just back up again which could take time to find an AP. As such,
you'll have a hard job convincing me that the working ethernet you just plugged
into should not take precedence by default.
Now this could be an issue where the route metric == the interface metric (ie
Linux, not NetBSD where my testing is) so we need to adjust the code to change
the route metric to reflect roaming vs carrier up.
DNS interfaces should be ordered according to their metric always.
DNS interfaces should be ordered according to their route metric always.
Then we are both happy if the route metric reflects the above ordering
Does this sound OK?
This means I need to test on my Linux laptop where I broke the OS - it's a
pinebook and the upgrade using KDE neon failed hard. A reflash should fix, but
as always that takes time. I've attached a new patch which should work. Be aware
that existing route offset values have been updated to start from 1000 rather
than 100. All the offsets are now set in route.h rather than magic numbers in
the code to make things clearer. The existing route code *should* already change
the route metric on before running a hook, but that's not been tested in years.
Hopefully you can test while I refresh my laptop.
Archive administrator: firstname.lastname@example.org