Dan, I wanted to ask more details about this statement, I'd like to understand more:
> 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. The RSSI portion is clear, accounting for expected throughput is what id' like to understand more of: Is this solely based on beacon/probe responses and the theoretic maximum TX/RX rates achievable on the advertising BSSID ? or is there actual channel measurement, IE Load taken into account ? Best Regards, Shawn Adams On 15.08.18 23:17, Dan Williams via networkmanager-list wrote: > 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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
