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

Reply via email to