Behavior over preference of APs and bands?

Dan Williams dcbw at redhat.com
Wed Jun 4 10:27:01 EDT 2014


On Tue, 2014-06-03 at 22:50 -0700, Rubin Abdi wrote:
> 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.

I think at this point we'd have to add some debug logging to the
supplicant and figure out what it's doing, and why it's choosing the
slower AP.  It might well be that the device hasn't completed a full
scan yet, and the supplicant could be using partial scan information.
Do you happen to know if, when this problem occurs, that the "slow" AP
you connect to is a 2.4GHz AP?

> 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

NM shouldn't care what the SSID is, it uses a byte array internally and
doesn't treat the SSID as a string.  So it could be 0x01 even :)  Here's
what you can do to debug this...

Stop NM
Run NM manually with:
NetworkManager --log-level=debug
--log-domains=core,hw,device,wifi,wifi-scan

and then let the problem occur.  You'll get a lot of log output, but NM
will show you exactly what it's doing and when it finds the Unicode AP,
and when it decides to connect to it.  Part of the issue is that not all
SSIDs are found in each scan all the time, so if your AP doesn't show up
in the card's first scan, NM won't know about it (and thus won't
auto-connect) until the second scan about 15 or 20 seconds later.  I'm
not sure that's the case though, and the debugging info would help
figure that out.

> 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
> appreciated.
> 
> > 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
> /etc/NetworkManager/system-connections ?

NM 0.9.9+ have the patches to lock to a band (by abusing the
supplicant's freq_list parameter) but that didn't make it to 0.9.8.10.
I've just cherry-picked those patches back though, so if we do a
0.9.8.12 they'll be there.  You could grab those and rebuild locally
too:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-8&id=c2a4d5569b60d39ef2edf298de824f06b08aa497
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-8&id=4a06948b5d66e6ac65497b4c82ab45c03d6315cd

> > 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.

I don't think it's detailed anywhere but the code; I went and read the
code and then wrote that paragraph based on my 5 minute look at it.

> 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.

Yeah, that's something that can best be solved by modifying the
supplicant, since the supplicant is what picks the best AP to associate
with...

Dan



More information about the HostAP mailing list