Re: wifi permanently switching between 2.4 and 5 GHz



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:
> On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via networkmanager-list <networkmanager-list gnome org> 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
  

On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via networkmanager-list <networkmanager-list gnome org> wrote:
On Tue, 2018-08-14 at 23:04 -0500, Greg Oliver via networkmanager-list
wrote:
> On Tue, Aug 14, 2018 at 2:24 PM "Jürgen Bausa" <Juergen Bausa web de>
> wrote:
>
> > I have a Xiaomi Air 12 Laptop (Intel Core m3-7Y30, Network
> > controller:
> > Intel Corporation Wireless 8260
> > (rev 3a)). I use debian Stretch (linux 4.9.0-7-amd64) with KDE and
> > Network-Mananger (1.6.2-3).
>

This is behavior specific to wpa_supplicant and how it decides to roam
between access points.  It attempts to roam to a BSSID within the same
SSID that has a better speed/signal.  It is expected that it might jump
between BSSIDs when conditions change.

Does the switching cause an actual problem?  It's supposed to happen
very quickly, within a couple 10s of ms.

Dan

> > Until now, wifi worked fine. However, after I exchanged my router
> > (which
> > had only 2.4 GHz) against a
> > newer model that has both 2.4 and 5 GHz (both frequencies with the
> > same
> > ssid), I experienced the
> > following problem: The computer switches permanently between both
> > frequencies. This happens approximately
> > every 2 minutes. In /var/log/messages I find the following:
> >
> > Aug 12 14:45:12 lina kernel: [ 2256.208621] wlp1s0: disconnect from
> > AP
> > xx:xx:xx:xx:xx:xx for new auth to yy:yy:yy:yy:yy:yy
> > Aug 12 14:45:12 lina kernel: [ 2256.213032] wlp1s0: authenticate
> > with
> > yy:yy:yy:yy:yy:yy
> > Aug 12 14:45:12 lina kernel: [ 2256.223163] wlp1s0: send auth to
> > yy:yy:yy:yy:yy:yy (try 1/3)
> > Aug 12 14:45:12 lina NetworkManager[564]: <info>  [1534077912.6843]
> > device
> > (wlp1s0): supplicant interface state: completed -> authenticating
> > Aug 12 14:45:12 lina kernel: [ 2256.228342] wlp1s0: authenticated
> > Aug 12 14:45:12 lina kernel: [ 2256.229481] wlp1s0: associate with
> > yy:yy:yy:yy:yy:yy (try 1/3)
> > Aug 12 14:45:12 lina kernel: [ 2256.230627] wlp1s0: RX AssocResp
> > from
> > yy:yy:yy:yy:yy:yy (capab=0x11 status=0 aid=1)
> > Aug 12 14:45:12 lina kernel: [ 2256.231932] wlp1s0: associated
> > Aug 12 14:45:12 lina NetworkManager[564]: <info>  [1534077912.6931]
> > device
> > (wlp1s0): supplicant interface state: authenticating -> associated
> > Aug 12 14:45:12 lina NetworkManager[564]: <info>  [1534077912.7338]
> > device
> > (wlp1s0): supplicant interface state: associated -> 4-way handshake
> > Aug 12 14:45:12 lina NetworkManager[564]: <info>  [1534077912.7414]
> > device
> > (wlp1s0): supplicant interface state: 4-way handshake -> completed
> >
> > where xx:xx:xx:xx:xx:xx the MAC of 2.4 and yy:yy:yy:yy:yy:yy the
> > MAC of 5
> > GHz net is.
> >
> > However, this happens not at all places in my house. Near the
> > router, 5
> > GHz is much stronger than 2.4 Ghz
> > and the system keeps th 5 GHz net. But in the living room, both
> > nets have
> > nearly the same strength and the
> > systems switches all the time.
> >
> > I found a lot of description of exactly this problem, but no
> > solution on
> > the net. See e.g.
> > https://forum.manjaro.org/t/frequent-wifi-disconnect/12211
> >
> > https://jeremyfelt.com/2017/01/02/things-i-learned-or-broke-while-t
> > rying-to-fix-my-wireless-in-ubuntu-16-10/
> >
> > https://www.archybold.com/blog/post/intermittent-connectionhigh-pac
> > ket-loss-intel-wireless-driver-iwlwifi-ubuntu-linux-networkmanager
> >
> > I think there should be some treshold that avoids switching between
> > nets
> > based on small fluctiations. But
> > where can I set this treshold. And is the switching caused by NM or
> > by the
> > driver? As the bugreports
> > mention different adapters, I think its not driver specific.
> >
> > Any hints welcome.
> >
> > juergen
> >
> > This is a long time nuisance of mine with NM and wpa-supplicant in
> > Linux.
>
> I just set the BSSID in NM to the MAC of the 5Ghz chip on the AP
> .  This also keeps it from scanning into 2.4 and causing 10 seconds
> drop
> outs.
>
> Unfortunately, I do not think a better way exists in Linux, which is
> unfortunate for us desktop users.  IMO, it is a major flaw that needs
> to be
> reworked ground up - it only happens on Linux (compared to MacOS and
> Windows on the same AP anyway - I have never run *BSD variants on a
> desktop
> machine).
>
>
> -
> Greg
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list



_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]