On Wed, 2018-08-15 at 13:21 -0700, Michael Butash wrote: > > On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via networkmanager- > > list < > > [email protected]> 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 uses a combination of RSSI and expected throughput of the AP based on advertised capabilities and channel widths (eg HT, VHT, etc). I'm not saying that wpa_supplicant is perfect, and I've personally patched it in the past to roam less frequently. What I am saying is that we were I to diagnose this issue, I don't have enough information to blame the roaming algorithm. What are the actual issues? When it roams, does a video you are watching suddenly downgrade from 1080p to HD? When it roams, does the connection completely break and you get a new IP address and all your SSH sessions die? Do downloads die? When it roams, does your Skype call stall for a second before recovering? Or does it hiccup your FPS game and you die? If the answer to those questions is "yes" then we have something to work with and we can figure out whether the roaming is the cause of them. Just saying "I want to be on 5GHz and it's not on 5GHz" isn't a necessarily a problem, because there are many factors in play and 5GHz is just one of those factors. I hope that explains my questions better. Again, I'm not saying that wpa_supplicant's roaming is perfect. But its roaming algorithm has been basically the same for at least 4 or 5 years so it clearly works well enough in many cases already. Dan > 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 > < > [email protected]> 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-whi > > > > le-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 > > > [email protected] > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > _______________________________________________ > > networkmanager-list mailing list > > [email protected] > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > _______________________________________________ > networkmanager-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
