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

Hi Denis and James,

On 5/7/25 18:31, Denis Kenzior wrote:
> Hi Alexander,
> 
> 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.

Good point. What is the definition of a "roaming attempt" here? You mean 
that all valid frequencies should be scanned before any frequency is 
re-scanned?

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

I agree, default should be good enough but for some use cases I think 
this kind of configuration could give big benefits. Maybe having a 
general config that limits which frequencies iwd uses is more 
reasonable? For example wpa-supplicant has the "scan_freq" config for 
this, which provides a simple way to optimize scans if the user knows 
what they're doing.

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

Gotcha. I still think neighbors will have to be scanned more often 
though. Maybe something like this would make more sense:
1. Scan neighbors
2. Scan knowns
3. Scan X un-scanned frequencies (ordered in some nice way)
4. Scan neighbors
5. Goto 3

And then use a list to track which frequencies have been scanned, as you 
say. The time until neighbors are re-scanned would then be dependent on 
how long the hardware takes to scan the other frequencies, but that 
seems hard to avoid. I'm only working with one type of hardware at the 
moment, so I don't have the full picture of how other hardware behaves 
and how big the difference is between fast and slow hardware.

I will also look in to ordering the frequencies in a more sustainable 
way, rather than hard-coding values. Also 6 GHz will have to be added to 
this somehow, not sure how to handle that in terms of priority.

Do you still see problems with this approach? It should eventually scan 
all frequencies, but might take a bit longer due to extra neighbor scans.

Regards,
Alexander