dhcpcd-discuss

Hi Roy,

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

Thank you,
Boris Krasnovskiy

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.

I disagree.
The rules are these: Precedence list, fallthrough on equality:

Carrier UP
Roaming
Not IPv4LL
Interface Metric
Oldest

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.

Your quote:
DNS interfaces should be ordered according to their metric always.
becomes:
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.

Roy