GNOME.org
 

Re: wifi permanently switching between 2.4 and 5 GHz

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]