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

[Dan Williams <dcbw redhat com>]

On Fri, 2014-05-02 at 07:06 +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.
> > >
> > > 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'
> Thanks for the suggestion - using wpa_supplicant -dddtu -f /var/log/wpa_supplicant.log produced the 
> attached output.
>
> It's odd that this times out - if I use wpa_supplicant manually it connects in a few seconds as do windows 
> and iOS devices.

So I see with the manual bits you're setting ap_scan=2 for this network.
Would you mind removing the ap_scan=2 for the manual case and retrying?
Ensure that scan_ssid=1 is still present.  There shouldn't be any need
for ap_scan=2 with a driver from the past 8 years, so lets just rule
that out for now.

Also, when you're trying with NetworkManager, are you deleting the
existing stored connection and re-creating it?  Or are you waiting for
NM to start the existing stored connection?

There are two ways NM handles connections to hidden networks:

1) after the original connection is created, NM caches the BSSID<->SSID
mapping of the hidden AP. If that AP is found in a later scan, NM fills
in the SSID and then it's able to connect automatically

2) When connecting to a hidden network from the UI, the UI/nm-applet/etc
should be setting the "hidden" flag on the stored connection. This
causes NetworkManager to request that the supplicant probe-scan that
SSID, which makes the AP announce itself, and thus the SSID is
available.  This is more-or-less what you're doing with the manual
supplicant runs where you set scan_ssid=1.

When NM is running, could you:

1) nmcli con
2) find the stored connection ID for bobnet (which is the human-readable
name, not the long hex UUID)
3) nmcli con list id "<ID of stored connection for bobnet>" | grep -i
hidden

And lets see what we get...  If hidden is not set, then we should set
it, and that should get the probe-scanning working correctly.  This
should result in the supplicant debug logs showing:

1399026688.003160: nl80211: Scan probed for SSID 'bobnet'

Dan