On Sat, 2018-11-24 at 11:06 +0100, Shawn Adams wrote:
> 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
The supplicant estimates each SSID's AP's throughput based on the
advertised rates and HT/VHT information versus the SNR/RSSI for that
AP.
See scan_est_throughput() in wpa_supplicant's scan.c for the estimated
throughput calculations.
When deciding to roam or not between APs of the same SSID, that
estimated throughput is used in conjunction with signal level.
See wpa_supplicant_need_to_roam() in events.c for the comparison when
deciding to roam or not. Start with the line:
if (selected->est_throughput > current_bss->est_throughput + 5000) {
and everything below that is relevant.
> on the advertising BSSID ? or is there actual channel measurement,
> IE
> Load taken into account ?
Yes, actual channel measurement (RSSI of the scan result and noise of
the channel, if the driver reports it) is factored into the
calculations.
Dan
>
> 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 <
> > > 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 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
> > > <
> > > 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-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
> > > > > 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
> > _______________________________________________
> > 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
