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" (?).
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
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
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
even with update NetworkManager-0.7.997-2.git20091214.fc12.i686 i cant connect to hidden networks (iwl3945)
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.
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.
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.
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?
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 ~]#
Oops, I was going to change the quoted ESSID to "myessid" as I had done to the command line but forgot.... whatever :).
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.
*** Bug 600667 has been marked as a duplicate of this bug. ***
*** Bug 574845 has been marked as a duplicate of this bug. ***
*** Bug 607523 has been marked as a duplicate of this bug. ***
Ping? Does this bug happen only if the AP is D-link or NetGear?
(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.
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...
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".
well so far I've been unable to connect to network with hidden ssid no matter what I do...
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.
Created attachment 450420 [details] var log messages of fc14beta-gnome where couldnt connect with hidden wifi
Created attachment 450421 [details] var log messages of fc14beta-kde where couldnt connect with hidden wifi
Created attachment 450422 [details] "iwlist wlan0 scan" from fc14beta-kde where couldnt connect with hidden wifi
(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.
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
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.
Created attachment 473930 [details] Scan and Setup with F14-gnome Hidden-1 is before and Hidden -2 is after connexction
still cant connect as of fc15-rawhide-kde
You might want to look at comment 35 of Bug 448437 for a potential workaround to this problem. Mike
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 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)
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)
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