Michael,
One view of band-steering is to ensure 5Ghz always looks better
by ensuring 5Ghz transmits at 6-8dB higher than 2.4Ghz .Some
band-steering mechanisms rely on exactly this. usually it's
desired that all clients connect 5ghz.
"I think there should be some treshold that avoids switching
between
> > nets based on small fluctiations"
This is the hysteresis or delta value, thus, AP_2 must be X
stronger than the current AP_1 for the client to initiate roaming.
(or at least initiate roam scanning)
Ideally, if one had multiple APs, each with lower TX power, and
using only the higher data rates, 5Ghz TX power ~6dB stronger than
2.4Ghz you'd create small "Cells" where only the nearby AP
provides strong signal and good data rates. (as one might find in
a corporate office) - it always looks much better than 2.4Ghz
Then again, there seem some people who think a strong 2.4Ghz
signal on an overcrowded and interference-laden channel is better
than a wonderfully clean 5Ghz channel with 5dB lower signal....
Might this help you ? setting the roam threshold and hysteresis:.
Play with the 8 value the higher, the machine band roaming will be
less sensitive. with only 1 AP, there is no BSSID roaming, so the
threshold isn't critical.
iw wlan5 cqm rssi -70 8
I'm not aware of anything in linux that affects band selection, I'd
be curious to know.
Not sure which makes more sense, to have NM set up "iw" commands or
edit the wpa_supplicant.conf
For general roaming, I think it would be great for NM expose the
bgscan and related configs, if 802.11k
has good wpa_supplicant support, this would be a real help for
roaming, and maybe this IW command.
-SA
On 15.08.2018 22:21, Michael Butash
wrote:
>
> Does
the switching cause an actual problem? It's supposed to
happen
>
very quickly, within a couple 10s of ms.
I have run into like roaming/band-selection issues with
linux around various wireless environments for some time,
pretty much any time I've has 2.4ghz and 5ghz co-existence on
the same ssid's. I seem to remember the few times I've gone
to look into it, there was no granular way to control 2.4/5ghz
either with iwconfig, wpa_supplicant, or nm, other than
mentioned static bssid, which is messy when you have more than
one ap around in high-density deployments. It seems it's just
far too hair-trigger to flip between AP's, and even enabling
band-steering features on enterprise ap/controller side
doesn't really seem to help influence which band a linux
system will end up using. I'm presuming it chooses generally
the best rssi, which 2.4 will probably always win, and often
I'll get my systems just refusing to use a 5ghz in places when
available.
It would be nice to have a bit better local control over
band selection, roaming sensitivity, and other client radio
behaviors since there really is no native ccx-like support to
control better these things in enterprise environments, and
consumer multi-ap solutions like this samsung probably don't
even properly offer any proper roaming support to control
client behavior in the first place.
-mb
_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
|