> > > > > > -----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' > > 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
I just noticed that I was not using the most recent Broadcom wl driver - after compiling the most recent driver (6.30.223.141) things now work. wpa_supplicant will connect manually without "ap_scan=2" and network-manager-applet will also connect. However, "nmcli con list id" still shows "hidden=no" _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
