Behavior over preference of APs and bands?
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
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
> 0.9.8.10 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
> 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 starset.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the Hostap