Re: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast ssid

[Dan Williams <dcbw redhat com>]

On Sun, 2014-04-27 at 09:56 +0000, John Frankish wrote:
> > -----Original Message-----
> > From: John Frankish
> > Sent: Friday, 25 April, 2014 17:41
> > To: networkmanager-list gnome org
> > Subject: networkmanager-0.9.8.9 will not connect to wifi with non-broadcast
> > ssid
> >
> > I've been trying to connect to a wap that does not broadcast the ssid for a
> > while without success.
> >
> > Using the same setup with wpa_supplicant manually works using the
> > wpa_supplicant.conf below.
> >
> > Apparently "scan_ssid=1" is required for non-broadcast ssid (and perhaps
> > also ap_scan=2).
> >
> > I cannot find where networkmanager/network-manager-applet stores the
> > wpa_supplicant.conf to check if it is using scan_ssid=1, is there a way to find
> > out?
> >
> > The connection details are also copied below and the networkmanager
> > debug output attached - maybe networkmanager doesn't wait long enough
> > to connect?
> >
> > Regards
> > John
>
> After some more checking I can confirm that networkmanager/network-manager-applet will connect to a wap 
> that does broadcast the ssid, which seems to confirm that the issue is with wap that do not broadcast the 
> ssid.

I've just verified that I can do both a new connection and a
reconnection to a hidden-SSID access point here with 0.9.8.10, though
with WEP not WPA (which shouldn't be an issue).  From your logs:

NetworkManager[1139]: <info> Config: added 'ssid' value 'bobnet'
NetworkManager[1139]: <info> Config: added 'scan_ssid' value '1'

NetworkManager doesn't store a supplicant config file, because the
network blocks are created on-the-fly based on the NM configuration and
what you type in, and a config file is pretty useless.  But the logs
show what NetworkManager is sending to the supplicant, which is exactly
what would be written to the supplicant config file.

So you can see that NM is sending scan_ssid=1.  ap_scan=2 is *not*
required for working WiFi drivers.  It's only required for older broken
drivers, and for Ad-Hoc mode.

NetworkManager[1139]: <info> (eth1): supplicant interface state:
inactive -> scanning
<30 seconds pass>
NetworkManager[1139]: <warn> Activation (eth1/wireless): association
took too long, failing activation.

This is a problem much lower down, either with the AP, or with the
supplicant and kernel.  The scanning process for the AP should take
anywhere between 1 and 10 seconds, often less than 2 or 3.

To debug that, can you grab some detailed wpa_supplicant logs?  Run
these two commands, and the supplicant should start dumping logs
to /var/log/wpa_supplicant.log:

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"

You should see something like this when you ask NetworkManager to
connect, or when NM tries to connect automatically:

wlp12s0: State: INACTIVE -> SCANNING
Scan SSID - hexdump_ascii(len=8)
    66 6f 6f 62 61 72 32 32    foobar22
...
nl80211: Scan SSID - hexdump_ascii(len=8)
    66 6f 6f 62 61 72 32 32    foobar22
...
wlp12s0: BSS: Add new id 15 BSSID <...> SSID 'foobar22'

Which indicates that the hidden SSID was indeed probe-scanned and found.

Dan