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: [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.
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' Dan _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
