Re: WiFi AP selection



On Fri, 2019-10-25 at 14:48 -0700, Clive McCarthy wrote:
I think the data rate reported is the maximum data rate that the
channel can support. It isn't a measure of the possible throughput
which would take into account noise (noise being "anything other than
the desired signal", which was what I was taught many, many years
ago). It is clear that the algorithm isn't taking into account
possible co-channel interference. If a 5GHz 500Mbps connection is
30dB down from a 2.4GHz 54Mbps signal then the 500Mbps is just pie-
in-the-sky. A connection with a lot of co-channel interference will
cause the many, many retries and the effective data rate collapses.

Please think in dBm. The percentage numbers mean absolutely nothing.
As I said, my phone measured a 10dB difference and nmcli reported
only a 90% to 55% ratio -- which is flat-out wrong. The percentage
numbers are bogus and should NOT be used to compare signal strengths.
The antenna on my phone will have a different gain to the antenna on
my laptop but the signal strength ratio is valid. Whoever wrote the
signal strength code isn't a radio engineer.

NetworkManager itself does not at all care about the signal strength.

- for example, when autoconnecting a Wi-Fi device with having multiple
candidate profiles in range, then the winner is not chosen based on the
signal strength. Instead, it's chosen based on "connection.autoconnect-
priority" and "connection.timestamp".

- roaming is not done by NetworkManager, but by wpa-supplicant. Hence,
NetworkManager doesn't care about the signal strengh in this case
either.

- no matter how bad a signal gets, NetworkManager won't decide to pull
the plug. It will stay connected until wpa-supplicant says that it lost
the connection.

The only place where the signal strength matters it to sort (and color-
code) the output of `nmcli device wifi`. It's purely informational
output for the user. Of course, that output should reflect the actual
situation, but your actual Wi-Fi expirience is unaffected by the
accuracy of the strength/percentage.


Please think in dBm. The percentage numbers mean absolutely nothing.

in dBm, better signal strength means a lower dBm number.
Likewise, when converted to percentage, then a lower dBm always means a
higher-or-equal percentage. So, a better percentage does mean a better
signal!

What is however not clear how much better 1% is. For example, there
might be better conversions from dBm to a percentage value that reflect
the actual signal strength better ([1]).

Anyway, the formulay for converting the numbers is quite simple. See
[2]. We certainly would welcome help from a radio engineer to improve
this!


[1] https://www.adriangranados.com/blog/dbm-to-percent-conversion
[2] 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/wifi/nm-wifi-utils.c?id=487b5df7169895cf132997b0bc7f402479043066#n784


best,
Thomas



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

 
 

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]