GNOME.org
 

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

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


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 driver:

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

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

http://www.broadcom.com/support/802.11/linux_sta.php
hybrid-portsrc_x86_64-v5_100_82_112.tar.gz

$ uname -a
Linux boxdell 3.8.13-tinycore64 #777 SMP Fri Oct 18 15:13:45 UTC 2013 x86_64 GNU/Linux

..so 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:

[802-11-wireless]
ssid=bobnet
mac-address=64:27:37:22:AB:51
security=802-11-wireless-security
hidden=yes

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

Thanks for the continuing support

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