Re: WiFi AP selection



So this is what I find very odd about WiFi quality and bars for WiFi:



Microsoft



Linux
dBm dB-ratio x 1M Quality relative
dBm dB-ratio x 1M Quality relative
-50 10.0000 100% 100.00%
-40 100.00000 100% 100.00%
-55 3.1623 90% 31.62%
-45 31.62278 93% 31.62%
-60 1.0000 80% 10.00%
-50 10.00000 86% 10.00%
-65 0.3162 70% 3.16%
-55 3.16228 79% 3.16%
-70 0.1000 60% 1.00%
-60 1.00000 71% 1.00%
-75 0.0316 50% 0.32%
-65 0.31623 64% 0.32%
-80 0.0100 40% 0.10%
-70 0.10000 57% 0.10%
-85 0.0032 30% 0.03%
-75 0.03162 50% 0.03%
-90 0.0010 20% 0.01%
-80 0.01000 43% 0.01%
-95 0.0003 10% 0.00%
-85 0.00316 36% 0.00%
-100 0.0001 0% 0.00%
-90 0.00100 29% 0.00%





-95 0.00032 21% 0.00%





-100 0.00010 14% 0.00%





-105 0.00003 7% 0.00%





-110 0.00001 0% 0.00%

For Microsoft at a so called 60% signal the actual signal is just 1% of the 100% level. For Linux at 57% the signal is actually at 0.1% of the 100% level -- 'splain it to me Lucy.



On 10/25/19 2:21 PM, Dan Williams wrote:
On Fri, 2019-10-25 at 11:17 -0700, Clive McCarthy wrote:
I've done a quick survey around the building and NM is always
selecting the highest data rate AP despite stronger signals from
other APs. This happens even when the data rate difference is
relatively small.
Again, it's actually the supplicant making the choice. But since NM is
the face of things here, it gets ultimate responsibility for the
behavior I guess.

As an example:
signal 90% data rate 54 Mbps
signal 55% data rate 65 Mbps -- active
 a bad choice. If the signal numbers were in dBm things would be
clearer. 
Typically you want faster data rates, not stronger signal (to a point).

For example if you were right next to your 802.11g AP with a max of
54Mbps, but had a 50% signal to an 802.11ac AP with a likely rate of
400+Mbps, why would you want to connect to the stronger-but-slower AP?

Dan

I put my Android phone next to my Linux laptop and got:
-48dBm
-58dBm
 respectively for the two channels a ~10dB difference. Way, way more
that the ratio of 90% to 55%. So forget this % nonsense.

On 10/23/19 12:41 AM, Thomas Haller wrote:
On Tue, 2019-10-22 at 15:02 -0700, Clive McCarthy via
networkmanager-
list wrote:
You know, I wish that the Network Manager would report the signal
strength in dBm instead of the silly sector icon. But that is for
another day.
nmcli -f SIGNAL,BSSID,SSID device wifi
nmcli -f ALL device wifi


best,
Thomas

On 10/22/19 2:24 PM, Dan Williams wrote:
On Tue, 2019-10-22 at 13:37 -0700, Clive McCarthy wrote:
I rand the commands you suggested but the response doesn't
look
like
a log dump. I guess they just enable logging.

method return time=1571775394.161873 sender=:1.8 ->
destination=:1.507 serial=32493 reply_serial=2
method return time=1571775429.864202 sender=:1.8 ->
destination=:1.508 serial=32496 reply_serial=2
method return time=1571775528.578915 sender=:1.8 ->
destination=:1.510 serial=32636 reply_serial=2

Can you point me to where the log files might be or at least
their
names.
If your distribution uses systemd, they may be available with:

journalctl -b -u wpa_supplicant

if your distro does not uses systemd, then it'll be wherever
syslog
dumps that kind of output, like:

/var/log/messages
/var/log/wpa_supplicant.log
/var/log/daemon.log

Dan

On 10/22/19 12:16 PM, Dan Williams wrote:
On Tue, 2019-10-22 at 11:17 -0700, Clive McCarthy wrote:
Thanks for your reply.
My laptop, when first opened, reports (via the Network
Manage, I
suppose) that it is disconnected from the network. After
a
second
or
two it reports being connected. And it is. However, as I
noted,
the
manager seems to choose the last known connection. This
is a
satisfactory algorithm for a fixed computer and for a
computer
connecting to a single AP. It isn't good for a movable
computer
with
multiple APs.

The Intel WiFi adapter is forced to shutdown when the
computer is
closed because there is a bug in the Intel-WiFi driver
that
doesn't
handle suspend correctly. That is why there is a
disconnect-
connect
sequence.
In this case we'd need the wpa_supplicant logs described
below
to
diagnose why the supplicant is picking that specific AP
rather
than
another.

Dan


On 10/22/19 10:05 AM, Dan Williams wrote:
On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via
networkmanager-
list wrote:
I have a situation where I have multiple APs in a
building
all
with
the same SSID and WPA key but set to non-clashing
frequencies.
When I
close my laptop and WiFi shuts down and I move to a
new
location
the
Network Manager seems to connect to the original AP,
rather
than
one
with a much stronger signal.

The algorithm for AP connection is suboptimal (in
other
words
dumb).
The selection process should scan ALL APs, figure out
which
ones
are
known (SSID and WPA); measure their signal strength
and
then
choose
the known AP with the strongest signal.

How hard is that?
This is what NetworkManager should already be doing.

Two things to check:

1) NetworkManager depends on being notified by systemd
or
upower
that
the laptop has suspended so that it can reconfigure
when it
wakes
up.
It should be pretty clear if that's happening through
the
NetworkManager logs because it will say that it's going
to
sleep
and
waking up. For example:

NetworkManager[1198]: <info>  [1571720491.7590]
manager:
sleep:
sleep requested (sleeping: no  enabled: yes)
NetworkManager[1198]: <info>  [1571720491.7599] device
(wlp61s0):
state change: disconnected -> unmanaged (reason
'sleeping',
sys-
iface-state: 'managed')
NetworkManager[1198]: <info>  [1571720491.7615]
manager:
NetworkManager state is now ASLEEP
NetworkManager[1198]: <warn>  [1571752873.5481] sup-
iface[0x55f38553aaa0,wlp61s0]: connection disconnected
(reason
-3)
NetworkManager[1198]: <info>  [1571752873.5504] device
(wlp61s0):
supplicant interface state: completed -> disconnected
NetworkManager[1198]: <info>  [1571752873.5803]
manager:
sleep:
wake requested (sleeping: yes  enabled: yes)
NetworkManager[1198]: <info>  [1571752873.6556] device
(wlp61s0):
state change: activated -> unmanaged (reason
'sleeping',
sys-
iface-
state: 'managed')

2) enabling debug logging in wpa_supplicant with these
two
commands
will show you exactly what's going on:

sudo dbus-send --system --print-reply --
dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1
org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugTimestamp
variant:boolean:true
sudo dbus-send --system --print-reply --
dest=fi.w1.wpa_supplicant1
/fi/w1/wpa_supplicant1
org.freedesktop.DBus.Properties.Set
string:fi.w1.wpa_supplicant1 string:DebugLevel
variant:string:"msgdump"

this will dump logs to wherever your system typically
sends
system
logs, like the systemd journal or syslog. Once you have
these
logs,
please review them to ensure there is no private
information
and
then
attach them to a reply so that we can figure out what's
going
on.

Thanks!
Dan

 
 
 
_______________________________________________
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]