Re: NM less reliable than wpa_supplicant (and more confusing) when forcing a BSSID?

[Dan Williams <dcbw redhat com>]

On Tue, 2008-11-18 at 12:58 -0500, Andrew Lutomirski wrote:
> Hi all-
> 
> I work in a building with a lot of APs and a lot of users (MIT, in
> case anyone's interested).  We have some APs that are overloaded (fail
> association with "too many clients" or some such -- code 0x1100
> according to Wireshark), and we have some APs that just plain don't
> work (I can see traffic but I don't get a lease).  We also have plenty
> of APs with strong enough signals that work fine.  Conveniently, they
> all have ESSID "MIT."
> 
> Using wpa_supplicant directly, I can connect almost instantly using
> something like:
> 
> network={
>  ssid="MIT"
>  scan_ssid=1
>  key_mgmt=NONE
>  bssid=<bssid of a good AP>
> }
> 
> and then dhclient gets a lease quickly enough.
> 
> With NM, maybe one in ten tries works.  I tried to force a BSSID by
> going to Edit Connections and creating a new connection with a
> specific BSSID, which had no apparent effect whatsoever -- nothing
> showed up on the menu, nothing connected, etc.  So, guessing at random
> "connect to a hidden network," and selected my new connection (ahem,
> "hidden?"), and clicked connect.  Didn't work either.
> 
> The NM logs say:
> 
> Nov 18 12:29:54 iridium NetworkManager: <info>  Config: added 'ssid' value 'MIT'
> 
> Nov 18 12:29:54 iridium NetworkManager: <info>  Config: added 'scan_ssid' value
> '1'
> Nov 18 12:29:54 iridium NetworkManager: <info>  Config: added 'bssid' value '00:
> 11:88:28:a6:50'
> Nov 18 12:29:54 iridium NetworkManager: <info>  Config: added 'key_mgmt' value '
> NONE'
> Nov 18 12:29:54 iridium NetworkManager: <info>  Activation (wlan0) Stage 2 of 5
> (Device Configure) complete.
> Nov 18 12:29:54 iridium NetworkManager: <info>  Config: set interface ap_scan to
>  1
> Nov 18 12:29:54 iridium NetworkManager: <info>  (wlan0): supplicant connection s
> tate change: 0 -> 2
> Nov 18 12:30:19 iridium NetworkManager: <info>  Activation (wlan0/wireless): ass
> ociation took too long, failing activation.
> 
> wpa_supplicant still works fine if I run it manually, even with ap_scan=1.
> 
> So, two sane questions...
> 
> 1. Any ideas why NM can't connect when wpa_supplicant has no trouble?

Not really, can you add "-dddt" to the end of the Exec= line
in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPSupplicant.service, then 'killall -TERM wpa_supplicant' and then try to get it to fail?  This will dump a lot of output to /var/log/wpa_supplicant.log that's quite useful in figuring out what's going on.

> 2. Can you explain how the NM UI is supposed to work?  I know what a
> BSSID is and I still can't figure it out how to use it properly.

That should be how you use it; if you enter the BSSID is, it should
direct NM tell the supplicant to only ever connect to that BSSID, which
seems to be working.  So it looks like there's other issues going on
here.  What exact kernel version, and do you know if the Ubuntu iwlwifi
driver is the upstream kernel's, or the compat-wireless stuff?  That's
more a question for the Ubuntu kernel maintainer I guess, but quite
useful.  NM targets the _upstream kernel_ drivers, and distros sort of
shoot themselves in the foot when they ship stuff that's not upstream or
closely derived from upstream. *cough* madwifi *cough*

Do you happen to have more than one network block in your supplicant
config that works?

> ...and two UI questions...
> 
> 3. I'd love some kind of subtle control on the list of SSIDs that pops
> up that lets me manually choose which AP to use.  ISTM it could be
> done with less confusion that creating a manual network (what are
> those "Auto" things, anyway?) and it would be handy in places with
> lots of APs of which many don't work.  Of course, it would be even
> better if NM could handle management frames saying that an AP is
> overloaded and fall back to a different one.  Any chance of
> reconsidering the UI a little to make this easier?

Handling the management frames and connect failures is something Linux
doesn't do well at the moment anyway, because these errors aren't
propogated up to the supplicant or NM.  I desperately want the
result/status codes from association sequences, but the drivers don't
pass that up yet.  If they did, we could certainly try something else.

However, NM doesn't pass the BSSID to the supplicant if you don't set it
in the connection editor, thus the supplicant is free to choose whatever
AP it likes best.  This should be no different than a supplicant network
block that does not specify bssid, and uses ap_scan=1 + scan_ssid=1.
The supplicant will use the "strongest" ap first.

> 4. When NM fails to connect, all I get is a message that the network
> is disconnected.  Could these be made more descriptive (e.g. "Unable
> to communicate with the access point at all," "Unable to find the
> access point," "Connected successfully but could not obtain an
> address," "The access point is overloaded," etc.)?

Yes, it does need to be more descriptive, but there's a current limit on
how descriptive that can be due to the driver information retrieval
issues I mention above.  We can get at least to the level of "couldn't
associate" versus "can't get an IP address" though.

Dan