Re: [PATCH RFC 3/3] station: improve roam scan strategy

Hi Alexander,

 >
> Yes, it will start reusing frequencies and might never reach the less common 
> frequencies depending on how long time the scans take. That's definitely not 
> ideal. Looking at the age as you suggest has the problem that it will eventually 
> spend time scanning uncommon frequencies when that time would have been better 
> spent scanning common frequencies that are getting old.

DFS frequencies are valid and it is quite common for APs to operate on them. 
Not scanning them or delaying the DFS scan excessively can lead to really 
terrible user experience.  In fact, we're having this problem on some older 
FullMAC hardware.  The firmware doesn't initially scan DFS frequencies, even 
though it is being told to.  This has led to all sorts of fun issues and lots of 
$/time wasted.

The less 'preferred' frequencies can be scanned last, but I think we still need 
to scan every valid frequency before starting the next roaming attempt.

> 
> Maybe this is an impossible task to solve perfectly as there will always be a 
> trade-off, maybe it's better left as configs for the user? In my livestream use 

A typical user cannot be expected to optimize something like this.  Our 
principle is to not rely on the user for any configuration.  The default 
behavior should be good enough for typical uses.

> case the APs should be configured such that most good frequencies are in 
> "neighbor" or "known", so I would like to spend most time on these frequencies. 
> However, for a use case where the network setup is unknown, having more 
> exploration of uncommon frequencies might be better.
> 

+1

> We could have configs instead where users can define the subsets and age 
> threshold. If they don't set anything, the default is the current behavior. If 

No.  You should not be relying on the user for anything like this.

> they set subsets, the roaming algorithm will pick frequencies from those in the 
> prioritized order, just like this patch does. It could still get stuck scanning 
> the same frequencies if the age threshold is too low, but then it would be a 
> user configuration error. We then also get rid of hard-coding frequencies in IWD 

Strong no.  It is not the user's problem and never should be.  Also, I really 
question using 'age' in seconds.  I strongly suspect it is something that will 
likely fail in all kinds of unexpected ways.  Hardware has all sorts of strange 
behaviors outside of iwd's control.  Scan times vary wildly.  A more stable 
solution is needed.

> and all problems that causes, but still give users the possibility to do so if 
> needed. Does this make more sense?
> 
> On 4/16/25 19:19, Denis Kenzior wrote:
>> Have you considered maintaining a scan_freq_set of all the frequencies scanned
>> by the neighbor and known-frequency stages instead of maintaining an hashtable
>> based on age?
> 
> I don't completely follow what you mean here. The reason for having the 
> hashtable is to know how long ago a certain frequency was scanned in order to 
> not scan it again too soon. So that info will have to be stored somehow, or did 
> you have some other approach in mind?

See my comment above about using a time based age value.  I would push more 
towards a solution that scans every (enabled) frequency in some sort of 
preference order.  My opinion is that using a set of previously scanned 
frequencies, rather than a hashtable, would fit better into that sort of strategy.

Regards,
-Denis