Behavior over preference of APs and bands?

Rubin Abdi rubin
Tue Jun 3 22:50:31 PDT 2014

Thanks for your reply Dan.

Dan Williams wrote, On 2014-06-03 07:43:
> At the moment NM's priority is "last used, if seen in a scan."
> We're going to add priorities in the near future, but that won't have
> any effect on your setup if you're using a single SSID.  Signal
> strength also doesn't factor into the decision at this time.

I'm actually having some issues with this new functionality/behavior and
am trying to figure out which project to file some bugs against.

The first is I've generally noticed this post-sleep-reconnect-last-used
reconnects me to the AP at very sub-par connection speeds. An example
would be generally when I connect to my Unifi Pro AP over 5GHz I get
somewhere around 100-300 Mb/s listed in iwconfig, but on post-sleep it's
typically around 5-20 Mb/s with abnormally high latency and dropped
packets. When this happens I typically have to tell NM to disconnect
from the AP and then reconnect by hand a second later. Once I do
everything is fast and snappy again.

The second issue I believe is related to the fact that I'm crazy and I
like to use a single unicode character for my SSID. Using NM I get the
impression it has a hard time comparing the name of this unicode SSID to
its list of preexisting remembered APs (with all the saved passwords and
everything). Sometimes when I wake from sleep at my house NM is able to
recognize that it has a record of this unicode SSID and to auto-connect
to that network. Most of the time however it'll wake and not
auto-connect to anything. After I manually select my unicode SSID, a new
duplicate record is added to the list and
/etc/NetworkManager/system-connections, it reconnects, and oddly doesn't
display the SSID in "Active connections" in the NM drop down in my KDE
system tray.

Any advice on which projects to file these bugs against would be greatly

> NetworkManager doesn't normally do anything with 5GHz vs. 2.4GHz
> bands, that's left up to the supplicant and driver to figure out.  NM
> and later *do* have the capability to lock a network to a
> specific frequency band though.

Through the KDE interface I can see a spot to lock onto BSSID but
unfortunately not band. Is there a way to do this through nmcli or
nm-tool, or simply the profiles saved in
/etc/NetworkManager/system-connections ?

> wpa_supplicant is the originator of this behavior, possibly in
> collusion with the drivers.  But normally, the supplicant decides
> which specific AP to connect to from the list of matching APs based
> on SSID and security settings.  Based on wpa_scan_result_compar(),
> what appears to happen is that normally, the highest signal strength
> AP within the SSID is chosen.  If the signals are close to each
> other, the AP with the fastest rates is chosen.  If the AP rates are
> similar, then 5GHz APs are preferred.

Is this logic detailed somewhere? Specifically I want to know what
constitutes similar rates? Because honestly with a difference of 10%
noise, I'm not seeing this behavior.

What I would really like is some control or say on how this behavior
should work on my machine. I imagine much of this is baked into bits of
wpa_supplicant and the driver I don't actually want to futts around with.

Anyhow, it's just all frustrating that the Apple devices my friends have
can figure it out, while I have to run these radios through different
SSIDs simply because something on my machines thinks that 10% drop in
signal noise is more worth while than a 200 Mb/s gain in throughput.

rubin at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Hostap mailing list