Hi Jolan,
On 2/22/21 1:57 PM, iwd(a)jolan.org wrote:
Hi,
I was deploying some new access points and reconfigured all the 5GHz channels on the old
access points to spread out the spectrum usage. When I restarted my iwd-using computers,
I noticed they all came up on 2.4GHz instead of 5GHz. I quickly realized that this is
because the quick path is reducing the scan to only the known frequencies in the cache. I
left iwd running and figured it would eventually find the old APs on their new frequencies
but it never did. Looking through the code, I see why this is. The quick connect/roam
path will only do a full scan if it can't connect at all, so it will happily stay
associated at lower bandwidth indefinitely.
Yes, you're correct. iwd tries pretty hard not to scan, unless asked to, so we
can certainly end up in the situation you describe. However, there are several
paths out of this condition which normally happen:
- A user requests a full scan via D-Bus, which should update the cache.
- A failed roam or quick scan that fails to find any candidates will trigger a
full frequency scan
- If Neighbor Reports are supported, then any neighbor frequencies will also get
added. iwd will ask for a neighbor report shortly after connecting. APs can
also send these unsolicited.
- If band steering is supported on the AP, AP can ask iwd to move to another
channel.
I can think of some other situations where this behavior may not be desired:
- AP is using a DFS channel, AP detects radar and falls over to a non-DFS channel
- a new frequency is deployed (Wi-FI 6E)
I tried to find a quick, easy way to forcibly full scan and cache but there really
wasn't good place to do so except on start up so I've resorted to deleting the
cache on boot-up until I've finalized WLAN configuration.
Somewhat of a large hammer, but fair enough.
I haven't been following iwd development much until now so maybe this has already
been discussed. Perhaps the cache needs to be a little less naive and take other factors
into account like cache creation time, the BSS/frequency of the last connection, or
perhaps all BSS/frequencies so a quick scan result could be checked to see how complete it
is compared to the fully cached BSS/frequency list and fall back to a full scan if the
current network topology varies greatly from the cached result.
Agreed. I definitely think there's room for improvement here. The devil is in
the details though, so concrete proposals / ideas are definitely welcome.
Do note that running a full scan would defeat the purpose of getting connected
quickly, which is what quick_scan state does. We value getting connected faster
over picking the 'optimal' bss in hopes that the network will steer us to the
right AP if iwd's initial choice is wrong. Admittedly, many networks aren't
that smart yet.
One thing we could explore is to be more aggressive in roaming if new BSSes in
the ESS are detected. Right now we are conservative and only do this if the
signal is getting low.
Thank you for your work on iwd and your time/consideration,
Regards,
-Denis