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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list