GNOME.org
 

Re: wifi permanently switching between 2.4 and 5 GHz

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 <

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