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

On Sat, 2014-05-03 at 11:34 +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
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 -
    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
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'

I tried to connect manually with wpa_supplicant without "ap_scan=2", but it
would not connect in five or six attempts. As soon as I added "ap_scan=2"
back, it connected first time.

The only way to get my wifi hardware to work is by using the Broadcom wl

$ dmesg | grep Hybrid
eth1: Broadcom BCM4359 802.11 Hybrid Wireless Controller

$ lsmod
02:00.0 Network controller: Broadcom Corporation BCM43228 802.11a/b/g/n

$ uname -a
Linux boxdell 3.8.13-tinycore64 #777 SMP Fri Oct 18 15:13:45 UTC 2013 x86_64
GNU/Linux it is definitely not 8 years old.

Trying to connect to a Cisco WAP4410N

As tinycorelinux is analogous to a live CD distribution (the file system is
copied to RAM on boot), nothing is saved between boots, so the
networkmanager wifi connection is re-created each time when I try to use
network-manager-applet to connect to a hidden network.

$ nmcli con list id bobnet | grep hidden
802-11-wireless.hidden:                 no

..but I cannot find a way to change this to "yes" - "nm-connection-editor"
does not show the "hidden" parameter and if I edit system-
connections/bobnet to read as follows:


.."hidden=yes" seems to be ignored, so how do I change it?

Thanks for the continuing support

I just noticed that I was not using the most recent Broadcom wl driver - after compiling the most recent 
driver ( things now work.

wpa_supplicant will connect manually without "ap_scan=2" and network-manager-applet will also connect.

Good to know.

 However, "nmcli con list id" still shows "hidden=no"

The hidden=no is simply a hint that NetworkManager should ask the
supplicant to probe-scan for the network, which will speed up subsequent
connections to some degree.  If things are working, I would say don't
bother setting it.


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