From: Alexander Ganslandt <alexanga@axis.com>
To: iwd@lists.linux.dev
Subject: Roaming questions
Date: Thu, 13 Feb 2025 16:01:10 +0100 [thread overview]
Message-ID: <7b7d342f-0487-423b-86d0-fbbf5987ecfd@axis.com> (raw)
Hello,
I'm looking into different roaming solutions and currently evaluating
iwd, which seems promising so far! My use-case is a device live
streaming video while moving around large areas, and the goal is to do
so without hiccups in the live stream. I have a few questions:
Looking at station_roam_failed(), it will schedule a full scan if the
previous limited scan failed to find a better BSS to roam to. A full
scan on our chip takes about 7 seconds, which is often enough time for
the signal to get low enough to deauthenticate the station when you're
moving. It seems to me that a better approach would be to schedule a
scan for either the "known frequencies", 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?
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?
Thanks in advance!
Best regards,
Alexander
next reply other threads:[~2025-02-13 15:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 15:01 Alexander Ganslandt [this message]
2025-02-13 15:24 ` Roaming questions Denis Kenzior
2025-02-13 15:42 ` James Prestwood
2025-02-17 10:15 ` Alexander Ganslandt
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=7b7d342f-0487-423b-86d0-fbbf5987ecfd@axis.com \
--to=alexanga@axis.com \
--cc=iwd@lists.linux.dev \
/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