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

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

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

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'


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]