Bug 516788 - [NetworkManager] Unable to connect to system AP (wlan0) with hidden ESSID
[NetworkManager] Unable to connect to system AP (wlan0) with hidden ESSID
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
14
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 574845 600667 607523 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-11 10:22 EDT by Joachim Frieben
Modified: 2012-08-16 13:55 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 13:55:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Screenshot of panel "Connect to Hidden Wireless Network..." after choosing "system <ESSID> (wlan0)" (33.54 KB, image/png)
2009-08-11 10:25 EDT, Joachim Frieben
no flags Details
Tail of /var/log/messages after running 'iwlist wlan0 scan essid AP_NAME' (6.09 KB, text/plain)
2010-04-13 04:58 EDT, Joachim Frieben
no flags Details
var log messages of fc14beta-gnome where couldnt connect with hidden wifi (166.71 KB, text/plain)
2010-09-29 05:30 EDT, collura
no flags Details
var log messages of fc14beta-kde where couldnt connect with hidden wifi (64.61 KB, text/plain)
2010-09-29 05:31 EDT, collura
no flags Details
"iwlist wlan0 scan" from fc14beta-kde where couldnt connect with hidden wifi (1.68 KB, text/plain)
2010-09-29 05:35 EDT, collura
no flags Details
Scan and Setup with F14-gnome (2.33 MB, application/x-gzip)
2011-01-17 15:40 EST, Robert Lightfoot
no flags Details

  None (edit)
Description Joachim Frieben 2009-08-11 10:22:08 EDT
Description of problem:
On a current "rawhide" system, a wireless connection is defined in files "ifcfg-wlan0" and "keys-wlan0". NetworkManager is unable to use this (exhaustive) information for connecting to an AP when its ESSID is hidden.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.995-2.git20090804.fc12.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Set up system connection wlan0 for an AP with hidden ESSID.
2. Restart NM.
  
Actual results:
NM does not bring up wireless connection.

Expected results:
NM does bring up wireless connection.

Additional info:
- Unhiding the ESSID allows NM to connect sucessfully.
- "Connect to Hidden Wireless Network..." allows to add a working connection
  for a hidden ESSID using the same information already stored in
  "ifcfg-wlan0" and "keys-wlan0". Thus, a connection "system <ESSID> (wlan0)"
  should work for a hidden ESSID, too. This is important because in the
  latter case, NM is able to bring up the wireless connection early during
  the boot process instead of connecting late only after a user has initiated
  a GNOME session.
- Choosing connection system <ESSID> (wlan0) in "Connect to Hidden Wireless
  Network..." brings up a panel in which all items/buttons are disabled/
  greyed out except for the connection selector and button "Cancel" (?).
Comment 1 Joachim Frieben 2009-08-11 10:25:01 EDT
Created attachment 357025 [details]
Screenshot of panel "Connect to Hidden Wireless Network..." after choosing "system <ESSID> (wlan0)"

Output to .xsession-errors when choosing "system <ESSID> (wlan0)" in "Connect to Hidden Wireless Network...":

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'Frequency' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'Frequency' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'RsnFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'WpaFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'Frequency' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'RsnFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'WpaFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'WpaFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist

** (nm-applet:1548): WARNING **: _nm_object_get_property: Error getting 'RsnFlags' for /org/freedesktop/NetworkManager/AccessPoint/4: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
Comment 2 Joachim Frieben 2009-09-01 04:51:16 EDT
After updating to current Koji, NM also fails to connect to an AP with a hidden ESSID set up locally. File .xsession-errors shows:

(nm-applet:2215): GLib-GObject-WARNING **: invalid uninstantiatable type
  `(null)' in cast to `NMAGConfConnection'

** (nm-applet:2215): CRITICAL **: nma_gconf_connection_get_gconf_path:
  assertion `NMA_IS_GCONF_CONNECTION (self)' failed

** (nm-applet:2215): WARNING **: <WARN>  activate_device_cb(): Device
  Activation failed: Connection was not provided by any settings service

Removing the old local wireless connection and creating a new one does not help either. Note however, that the latest NM had already been installed yesterday.
The problem occurred after updating:

deltarpm-3.5-0.git.20090831.1.fc12.x86_64
eclipse-jdt-3.5.0-0.9.fc12.x86_64
eclipse-pde-3.5.0-0.9.fc12.x86_64
eclipse-platform-3.5.0-0.9.fc12.x86_64
eclipse-rcp-3.5.0-0.9.fc12.x86_64
eclipse-swt-3.5.0-0.9.fc12.x86_64
fontconfig-2.7.2-1.fc12.x86_64
fontconfig-devel-2.7.2-1.fc12.x86_64
git-1.6.4.2-1.fc12.x86_64
gupnp-0.12.8-4.fc12.x86_64
gupnp-devel-0.12.8-4.fc12.x86_64
libuuid-devel-2.16-8.fc12.x86_64
libXtst-1.0.99.2-3.fc12.x86_64
libXtst-devel-1.0.99.2-3.fc12.x86_64
maven2-2.0.8-1.4.fc12.noarch
maven-surefire-2.3-7.7.fc12.noarch
mysql-libs-5.1.37-5.fc12.x86_64
nss-3.12.3.99.3-30.fc12.x86_64
nss-devel-3.12.3.99.3-30.fc12.x86_64
nss-softokn-3.12.3.99.3-24.fc12.x86_64
nss-softokn-devel-3.12.3.99.3-24.fc12.x86_64
nss-softokn-freebl-3.12.3.99.3-24.fc12.x86_64
nss-tools-3.12.3.99.3-30.fc12.x86_64
openssh-5.2p1-21.fc12.x86_64
openssh-askpass-5.2p1-21.fc12.x86_64
openssh-clients-5.2p1-21.fc12.x86_64
openssh-server-5.2p1-21.fc12.x86_64
openssl-1.0.0-0.6.beta3.fc12.x86_64
openssl-devel-1.0.0-0.6.beta3.fc12.x86_64
parted-1.9.0-14.fc12.x86_64
perl-Git-1.6.4.2-1.fc12.noarch
phonon-backend-gstreamer-4.5.2-13.fc12.x86_64
qt-4.5.2-13.fc12.x86_64
qt-x11-4.5.2-13.fc12.x86_64
sane-backends-1.0.20-7.fc12.x86_64
sane-backends-libs-1.0.20-7.fc12.x86_64
selinux-policy-3.6.30-1.fc12.noarch
selinux-policy-targeted-3.6.30-1.fc12.noarch
setroubleshoot-2.2.24-1.fc12.x86_64
setroubleshoot-server-2.2.24-1.fc12.x86_64
yum-3.2.23-15.fc12.noarch
Comment 3 Bug Zapper 2009-11-16 06:20:19 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Jonathan Colon 2009-12-18 16:43:23 EST
even with update NetworkManager-0.7.997-2.git20091214.fc12.i686 i cant connect to hidden networks (iwl3945)
Comment 5 Jonathan Larmour 2010-01-11 22:00:43 EST
I can also confirm this bug in NetworkManager under F12 (including latest update). In my case, I can click on the nm applet, and choose "Connect to Hidden Wireless Network, select my connection (which includes the desired ESSID configured), and click Connect. That works fine. But after a reboot, or a "service NetworkManager restart", NetworkManager fails to restore the connection.

Additionally setting the BSSID does not help.

I'm not sure I agree this is low priority - new users will probably not be able to get their wireless going, and it will be far from clear that they need to take the explicit step every time they reboot of choosing "Connect to Hidden Wireless Network". So while there is an awkward workaround, it will not always be an obvious one.
Comment 6 Jonathan Larmour 2010-01-11 23:47:02 EST
I have tried to debug this further by adding -dddt to wpa_supplicant's invocation.
 Now in my case, I have configured the connection in NM not to use any encryption, so it's not even clear why wpa_supplicant is being used at all. But in any case, here is a log of a scan with hidden ESSID:

1263269280.001065: Setting scan request: 0 sec 0 usec
1263269280.001168: State: INACTIVE -> SCANNING
1263269280.001233: Starting AP scan (broadcast SSID)
1263269280.018135: Scan requested (ret=0) - scan timeout 5 seconds
1263269285.023266: Scan timeout - try to get results
1263269285.024655: Received 726 bytes of scan results (3 BSSes)
1263269285.024713: CTRL-EVENT-SCAN-RESULTS 
1263269285.025694: wpa_supplicant_select_bss_and_associate: qual 0 (0)  qv=0  bv=0
1263269285.025734: No suitable AP found.
1263269285.025754: Setting scan request: 5 sec 0 usec
1263269290.030875: No enabled networks - do not scan
1263269290.030933: State: SCANNING -> INACTIVE

Interestingly here is a scan of what happens if I manually do "iwconfig eth1 essid myessid":

1263269598.536106: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263269598.536188: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263269598.536211: Wireless event: cmd=0x8b15 len=24
1263269598.536232: Wireless event: new AP: 00:0f:66:ed:b7:98
1263269598.536254: State: DISCONNECTED -> ASSOCIATED
1263269598.536348: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1263269598.536376: WEXT: Operstate: linkmode=-1, operstate=5
1263269598.536622: Associated to a new BSS: BSSID=00:0f:66:ed:b7:98
1263269598.536650: No keys have been configured - skip key clearing
1263269598.536668: Select network based on association information
1263269598.536898: No network configuration found for the current AP
1263269598.536920: wpa_driver_wext_disassociate
1263269598.537496: No keys have been configured - skip key clearing
1263269598.537534: State: ASSOCIATED -> DISCONNECTED
1263269598.537615: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1263269598.537642: WEXT: Operstate: linkmode=-1, operstate=5
1263269598.537673: EAPOL: External notification - portEnabled=0
1263269598.537697: EAPOL: External notification - portValid=0
1263269598.537724: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263269598.537747: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263269598.537768: Wireless event: cmd=0x8c02 len=35
1263269598.537788: WEXT: Custom wireless event: 'Conn Disassoc 00 08'
1263269598.537811: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263269598.537832: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263269598.537851: Wireless event: cmd=0x8b15 len=24
1263269598.537871: Wireless event: new AP: 00:00:00:00:00:00
1263269598.537892: BSSID 00:00:00:00:00:00 blacklist count incremented to 8
1263269598.537917: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
1263269598.537946: wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
1263269598.538146: wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
1263269598.538805: wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
1263269598.539030: wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
1263269598.539100: wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
1263269598.539186: wpa_supplicant_event_disassoc: scheduled DISCONNECT spam handler
1263269598.539208: State: DISCONNECTED -> DISCONNECTED
1263269598.539225: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1263269598.539243: WEXT: Operstate: linkmode=-1, operstate=5
1263269598.539269: EAPOL: External notification - portEnabled=0
1263269598.539289: EAPOL: External notification - portValid=0

Note that it does successfully associate, but something (NM via dbus?) makes it disconnect. When I run "iwconfig" I see that the ESSID is always clear even if I manually set it - presumably NM sets it back to empty. It seems to me that as long as NM does this, scanning for hidden ESSIDs will not work.

Finally here is what happens if I manually tell NM to connect to a hidden wireless network using my saved connection info (which results in a successful connection):

1263270877.592320: key_mgmt: 0x4
1263270877.592375: scan_ssid=1 (0x1)
1263270877.592394: ssid - hexdump_ascii(len=6):
     xx xx xx xx xx xx xx                                 myessid          
1263270877.592423: BSSID - hexdump(len=6): xx xx xx xx xx xx
1263270877.592983: Setting scan request: 0 sec 0 usec
1263270877.593050: State: INACTIVE -> SCANNING
1263270877.593091: Starting AP scan (specific SSID)
1263270877.593128: Scan SSID - hexdump_ascii(len=6):
     xx xx xx xx xx xx xx                                 myessid          
1263270877.615190: Scan requested (ret=0) - scan timeout 5 seconds
1263270882.620345: Scan timeout - try to get results
1263270882.620701: Received 206 bytes of scan results (1 BSSes)
1263270882.621361: CTRL-EVENT-SCAN-RESULTS 
1263270882.621649: wpa_supplicant_select_bss_and_associate: qual 0 (0)  qv=0  bv=0
1263270882.621673: Selecting BSS from priority group 0
1263270882.621690: Try to find WPA-enabled AP
1263270882.621706: 0: 00:0f:66:ed:b7:98 ssid='myessid' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
1263270882.621727:    skip - no WPA/RSN IE
1263270882.621742: Try to find non-WPA AP
1263270882.621757: 0: 00:0f:66:ed:b7:98 ssid='myessid' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
1263270882.621777:    selected non-WPA AP 00:0f:66:ed:b7:98 ssid='myessid'
1263270882.621800: Trying to associate with 00:0f:66:ed:b7:98 (SSID='myessid' freq=2412 MHz)
1263270882.621819: Cancelling scan request
1263270882.621837: WPA: clearing own WPA/RSN IE
1263270882.622202: Automatic auth_alg selection: 0x1
1263270882.622442: WPA: clearing AP WPA IE
1263270882.622461: WPA: clearing AP RSN IE
1263270882.622476: WPA: clearing own WPA/RSN IE
1263270882.622493: No keys have been configured - skip key clearing
1263270882.622509: wpa_driver_wext_set_drop_unencrypted
1263270882.622727: State: SCANNING -> ASSOCIATING
1263270882.622801: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1263270882.622823: WEXT: Operstate: linkmode=-1, operstate=5
1263270882.622853: wpa_driver_wext_associate
1263270882.623147: wpa_driver_wext_set_psk
1263270882.642913: Association request to the driver failed
1263270882.642957: Setting authentication timeout: 10 sec 0 usec
1263270882.642971: EAPOL: External notification - EAP success=0
1263270882.642983: EAPOL: External notification - EAP fail=0
1263270882.642994: EAPOL: External notification - portControl=ForceAuthorized
1263270882.643933: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263270882.643967: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270882.643978: Wireless event: cmd=0x8b06 len=12
1263270882.643991: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263270882.644002: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270882.644012: Wireless event: cmd=0x8b04 len=16
1263270883.095137: RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
1263270883.095208: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270883.095227: Wireless event: cmd=0x8b15 len=24
1263270883.095244: Wireless event: new AP: 00:0f:66:ed:b7:98
1263270883.095262: State: ASSOCIATING -> ASSOCIATED
1263270883.095915: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1263270883.095960: WEXT: Operstate: linkmode=-1, operstate=5
1263270883.096224: Associated to a new BSS: BSSID=00:0f:66:ed:b7:98
1263270883.096251: Associated with 00:0f:66:ed:b7:98
1263270883.096268: WPA: Association event - clear replay counter
1263270883.096292: WPA: Clear old PTK
1263270883.096308: EAPOL: External notification - portEnabled=0
1263270883.096328: EAPOL: External notification - portValid=0
1263270883.096345: EAPOL: External notification - portEnabled=1
1263270883.096361: EAPOL: SUPP_PAE entering state S_FORCE_AUTH
1263270883.096377: EAPOL: SUPP_BE entering state IDLE
1263270883.096394: Cancelling authentication timeout
1263270883.096412: State: ASSOCIATED -> COMPLETED
1263270883.099125: CTRL-EVENT-CONNECTED - Connection to 00:0f:66:ed:b7:98 completed (auth) [id=0 id_str=]
1263270883.099224: wpa_driver_wext_set_operstate: operstate 0->1 (UP)
1263270883.099243: WEXT: Operstate: linkmode=-1, operstate=6
1263270883.100414: Cancelling scan request
1263270883.100471: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
1263270883.100493: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270883.121202: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
1263270883.121263: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270883.121283: Wireless event: cmd=0x8c03 len=24
1263270883.121326: RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
1263270883.121347: RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
1263270883.121363: Wireless event: cmd=0x8c02 len=34
1263270883.121382: WEXT: Custom wireless event: 'Conn Success 00 00'

So we can see that (at a guess) NM is not setting the ESSID to the (configured) hidden value, preventing the supplicant/driver from looking for it in its scan. And even if set by hand, something (probably NM?) doesn't like it. NM is only happy when manually instructed to connect to a hidden network.

I have tried manually setting the BSSID of the AP in the connection settings, but that doesn't help. And even after NM is told to connect to the hidden network, once NM is restarted (by service NetworkManager restart, or by a reboot) we're back to square one.

FAOD yes I am fully aware of the limitations of hiding the ESSID. However you'll have to trust me that it is appropriate to my environment.
Comment 7 geoffs_aus 2010-03-27 00:58:42 EDT
Is there any way to get the priority revised?  Or as a stopgap change the functionality so there's the option to automatically attach to a network with a hidden SSID is removed so it's not a bug?

At least if the option wasn't there users wouldn't get frustrated trying to get something working that doesn't.
Comment 8 Dan Williams 2010-04-08 21:21:48 EDT
What wifi hardware are people using?

Next, does the access point provide two SSIDs, one hidden and one public, both using the same BSSID?  Try doing an 'iwlist wlan0 scan' and looking for your AP; next do 'iwlist wlan0 scan essid <your hidden SSID>' and then look again for your
AP.  Can you post the output of those two here?
Comment 9 Jonathan Larmour 2010-04-09 20:10:38 EDT
I have a Linksys WAP54G, and I also had used a similarly set up Belkin F5D7230 ADSL gateway (with wireless) at one point.

[root@lert ~]# iwlist eth1 scan 
eth1      Scan completed :
          Cell 01 - Address: 00:0F:66:ED:B7:98
                    ESSID:""
                    Mode:Managed
                    Frequency:2.412 GHz (Channel 1)
                    Quality:4/5  Signal level:-60 dBm  Noise level:-92 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
          Cell 02 - Address: 00:23:4D:47:89:E0
[snip subsequent irrelevant APs]

[root@foo ~]# iwlist eth1 scan essid myessid
eth1      Scan completed :
          Cell 01 - Address: 00:0F:66:ED:B7:98
                    ESSID:"larmour"
                    Mode:Managed
                    Frequency:2.412 GHz (Channel 1)
                    Quality:4/5  Signal level:-61 dBm  Noise level:-90 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s

[root@foo ~]#
Comment 10 Jonathan Larmour 2010-04-09 20:12:04 EDT
Oops, I was going to change the quoted ESSID to "myessid" as I had done to the command line but forgot.... whatever :).
Comment 11 Joachim Frieben 2010-04-13 04:58:44 EDT
Created attachment 406177 [details]
Tail of /var/log/messages after running 'iwlist wlan0 scan essid AP_NAME'

Running 'iwlist wlan0 scan essid AP_NAME' explicitly after starting a new GNOME session triggers a successful attempt of NM to bring up wlan0 almost all the time even when the ESSID is hidden.

Likwise, adding 'iwlist wlan0 scan essid AP_NAME' to /etc/rc.d/rc.local allows NM to connect to the hidden AP successfully as indicated by nm-applet after starting a GNOME session.

Wireless connectivity is provided by a D-Link DWL-G520 (Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter [168c:0013] (rev 01)) using driver ath5k ver 0.6.0 [srcversion: 58CC806C7FEA85AD34B678D] as included in kernel 2.6.33.2-43.fc13.x86_64.
Comment 12 Dan Williams 2010-06-28 16:30:07 EDT
*** Bug 600667 has been marked as a duplicate of this bug. ***
Comment 13 Dan Williams 2010-06-28 16:31:25 EDT
*** Bug 574845 has been marked as a duplicate of this bug. ***
Comment 14 Dan Williams 2010-06-28 16:31:46 EDT
*** Bug 607523 has been marked as a duplicate of this bug. ***
Comment 15 Riku Seppala 2010-07-17 04:04:31 EDT
Ping?

Does this bug happen only if the AP is D-link or NetGear?
Comment 16 Michael Monreal 2010-07-17 04:50:47 EDT
(In reply to comment #15)
> Does this bug happen only if the AP is D-link or NetGear?    

No, it happens with my AVM Fritz!Box, too.
Comment 17 Riku Seppala 2010-07-17 10:36:41 EDT
hm, Fritz!Box advertises that it can "Increases the range of your wireless network quickly and easily". My wlan card is tp-link tl-wn551g that has "eXtended range technology" and I have trouble connecting to my wlan box less than 10 metres even without hidden ssid. Are these operating differently than normal wlan products and Linux doesn't fully support it? I really have no idea, just guessing here...
Comment 18 Jonathan Larmour 2010-07-19 00:03:05 EDT
Riku: Yes you are guessing :). This bug is only to do with the problem where NetworkManager cannot automatically reconnect to wifi networks with hidden SSIDs. It can connect to such networks if you manually tell it to connect to the hidden network. But it doesn't do it itself, even when the connection is marked with "Connect Automatically".

If you are experiencing a different problem such as with wifi range, then this bug is not the place for that discussion. Create a different bug if that's what you need.

@Joachim: Your suggested workaround of doing an explicit scan for the hidden essid also works for me *provided* it's done very soon after network manager starts. Specifically before network manager completes its own first scan. If you scan too late, then it won't help. Of course this is only a workaround, not a fix.

From my own debug output, after running the scan and NM successfully associating, I see that it claims it only found the AP associated with the hidden ESSID in its scan, and it can see its name (normally it would give the ESSID as "(none)"). It didn't see the other two APs which are also in range of my laptop. Just the one that was explicitly scanned for.

So I suspect the reason this workaround works is unrelated to the actual cause of the problem, which is that NM doesn't even attempt to associate with connection.

I have also analysed the output of "dbus-monitor --system" when using nm-applet to manually associate with a hidden network. When that happens there are some key dbus messages:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
signal sender=:1.9656 -> dest=(null destination) serial=138 path=/org/freedesktop/NetworkManager/Devices/0; interface=org.freedesktop.NetworkManager.Device.Wireless; member=AccessPointAdded
   object path "/org/freedesktop/NetworkManager/AccessPoint/3"
signal sender=:1.9656 -> dest=(null destination) serial=139 path=/org/freedesktop/NetworkManager/AccessPoint/3; interface=org.freedesktop.NetworkManager.AccessPoint; member=PropertiesChanged
   array [
      dict entry(
         string "Ssid"
         variant             array [
               byte 108
               byte 97
               byte 114
               byte 109
               byte 111
               byte 117
               byte 114
            ]
      )
   ]
signal sender=:1.9656 -> dest=(null destination) serial=140 path=/org/freedesktop/NetworkManager/Devices/0; interface=org.freedesktop.NetworkManager.Device.Wireless; member=PropertiesChanged
   array [
      dict entry(
         string "ActiveAccessPoint"
         variant             object path "/org/freedesktop/NetworkManager/AccessPoint/3"
      )
   ]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The ssid is indeed my hidden ssid. I expect these messages are from NM to the supplicant.

NM doesn't do anything similar on startup however. It appears it never even attempts to tell the supplicant to try and associate with the ESSID, despite the connection having been marked as "Connect Automatically".
Comment 19 Riku Seppala 2010-07-19 00:26:21 EDT
well so far I've been unable to connect to network with hidden ssid no matter what I do...
Comment 20 matt.productdesign 2010-07-24 01:15:26 EDT
I'm having the same problem in Fedora 13.  I have a wep 40/64 with a hidden ssid network.  Fedora 13 won't connect from 3 different machines.  I still have Fedora 12 on one machine that connects just fine- every time.  Fedora 13 won't connect- ever.  Router is Linksys Wireless N Gigabit router kicking out a G signal.   Ubuntu and Windows also connect fine.  Just Fedora 13 won't.
Comment 21 collura 2010-09-29 05:30:16 EDT
Created attachment 450420 [details]
var log messages of fc14beta-gnome where couldnt connect with hidden wifi
Comment 22 collura 2010-09-29 05:31:55 EDT
Created attachment 450421 [details]
var log messages of fc14beta-kde where couldnt connect with hidden wifi
Comment 23 collura 2010-09-29 05:35:06 EDT
Created attachment 450422 [details]
"iwlist wlan0 scan" from fc14beta-kde where couldnt connect with hidden wifi
Comment 24 Joachim Frieben 2010-09-29 07:11:34 EDT
(In reply to comment #20)
Referring to my initial report please note that it is always possible to use the dialog "Connect to Hidden Wireless Network..." accessible through nm-applet. This bug is -solely- about NM not showing/connecting to an AP with hidden SSID even when SSID and WEP key are already stored in files ifcg-wlan0 and keys-wlan0 respectively.
Comment 25 Bug Zapper 2010-11-04 06:32:52 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Robert Lightfoot 2011-01-17 15:38:16 EST
This appears to be a continuation of Bug 448437 and I can vouch that on my Linksys WRT300N running DD-Wrt V24-sp2 firmware and my Dell B130 Laptop running F14 this is still an issue.  I'll post my config and iwlist scan data as an attachement .  Hopefully this can be resolved since it's been an issue since F9.
Comment 27 Robert Lightfoot 2011-01-17 15:40:49 EST
Created attachment 473930 [details]
Scan and Setup with F14-gnome

Hidden-1 is before and Hidden -2 is after connexction
Comment 28 collura 2011-01-22 23:19:08 EST
still cant connect as of fc15-rawhide-kde
Comment 29 Mike Parker 2011-01-31 03:49:20 EST
You might want to look at comment 35 of Bug 448437 for a potential workaround to this problem.

Mike
Comment 30 Bug Zapper 2011-06-02 13:51:06 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Joachim Frieben 2011-06-14 05:04:01 EDT
Comment 11 still fully applies to current F14 including NetworkManager-0.8.4-1.fc14: failure to connect on boot but success after running 'iwlist wlan0 scan' from an active GNOME session.

(Note: issue -resolved- for current F15 including NetworkManager-0.8.9997-3.git20110613.fc15)
Comment 32 collura 2011-06-24 05:12:20 EDT
just noticed f15-gnome seems to be autoconnecting the wifi after reboot 
as of last few days, yay. 

not sure what triggered it but currently running:

  NetworkManager-1:0.8.9997-4.git20110620.fc15 (x86_64)
  gnome-settings-daemon-3.0.1-6.fc15 (x86_64)

(f15-kde wifi still broken but probably unrelated)
Comment 33 Fedora End Of Life 2012-08-16 13:55:23 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.