Re: Roaming questions

Alexander Ganslandt <[email protected]>
Newsgroups dev.linux.lists.iwd
Message-ID <[email protected]>
>>> or all non-DFS frequencies (since passive scanning takes extra time)
>>> or some other popular group of frequencies that won't take long to
>>> scan. If we're lucky there is a good BSS in that scan, otherwise we
>>> schedule a scan for the rest of the frequencies. In the worst case,
>>> this should be identical to a full scan with minor extra overhead. Do
>>> you have any thoughts about this from your side? Is it something that
>>> could be accepted into iwd or could it cause issues for other use-cases?
>>
>> If you find that full scans do indeed happen when roaming, then
>> introducing intermediate limited / non-DFS scan(s) prior to the
>> catch-all scan would be just fine.
> 
> This is an area I want to improve since we do see full scans routinely.
> Not because we didn't see any acceptable BSS's via neighbor reports, but
> because the current one was simply better. Likely another limited scan
> using the very same neighbor reports, just done later, would result in a
> successful roam. But its tough because you can't always the APs are
> sending accurate neighbor reports.

Yes, I also see full scans routinely for exactly the reason you 
highlighted, that no other BSS is better than the current one. I also 
see that the neighbor report doesn't include all nearby BSSes, it seems 
to prioritize 2.4 GHz and leave out 5 GHz, but maybe that's a config 
issue on the AP side or the 5 GHz signal is too weak for it to pick up. 
Either way, immediately going for a full scan seems a bit overkill.

I plan on doing some more testing to see if I can improve this, will 
report back if that's the case!

>>> Another question is about the "CriticalRoamThreshold". There seems to
>>> be a config for this and some functions for lowering and raising the
>>> roam threshold, but I can't see that they're called from anywhere? It
>>> seems to me that only "RoamThreshold" is used, or am I missing
>>> something? There's also a hardcoded delay of 5 seconds from the point
>>> where the roam threshold is passed before a scan is started, is that
>>> just a "hysteresis" to not immediately start a scan if the signal
>>> temporarily drops, or does it have some other function?
>>
>> This is currently used with the Affinities property on the Station
>> interface. For now it is only useful to lock the station to the
>> currently connected BSS to prevent roaming.  For example, for the
>> duration of firmware upgrade or similar scenarios.

Ah, Yocto Styhead is using iwd 2.20 and in that version the functions 
for using CriticalRoamThreshold were implemented but no one was using 
them. I've now updated to 3.2 and see it used for affinities. Thank you 
for the pointer!

BR,
Alexander
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.