From: Alexander Ganslandt <alexanga@axis.com>
To: James Prestwood <prestwoj@gmail.com>,
Denis Kenzior <denkenz@gmail.com>,
iwd@lists.linux.dev
Subject: Re: Roaming questions
Date: Mon, 17 Feb 2025 11:15:11 +0100 [thread overview]
Message-ID: <9772b360-2d94-447c-90c6-c72849b5a74f@axis.com> (raw)
In-Reply-To: <7ddbf418-e8c2-4d2a-9495-3a1cce2ddb3e@gmail.com>
>>> 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
prev parent reply other threads:[~2025-02-17 10:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 15:01 Roaming questions Alexander Ganslandt
2025-02-13 15:24 ` Denis Kenzior
2025-02-13 15:42 ` James Prestwood
2025-02-17 10:15 ` Alexander Ganslandt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9772b360-2d94-447c-90c6-c72849b5a74f@axis.com \
--to=alexanga@axis.com \
--cc=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox