> > > > -----Original Message----- > > > > From: John Frankish > > > > Sent: Friday, 25 April, 2014 17:41 > > > > To: [email protected] > > > > 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. > In case it's useful I've attached the log from using wpa_supplicant manually - in this case it connects in a few seconds, even via a wifi repeater, which does not broadcast the ssid.
wpa_supplicant_no_ssid_repeater_manual.log.tar.gz
Description: wpa_supplicant_no_ssid_repeater_manual.log.tar.gz
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
