Description of problem: NM is unable to automatically connects to networks with hidden ESSID, but profile of this site is stored. Version-Release number of selected component (if applicable): 0.7.0 - F9 standard How reproducible: New installation of F9 x86 Steps to Reproduce: New installation, nothing to reproduce. Actual results: When you first time connect to site with hidden ESSID, informations are stored for next connections, which should be automatic. But problem is, when you have network with hidden ESSID, NM is unable to connect automatically (but profile is stored), so you must connect manually. Expected results: Automatic NM connects to networks with hidden ESSID - like connects to networks with visible ESSID. Additional info: This is my first reported bug, so please be tolerant to me, because I am really new and I can make some mistakes ;).
I confirme this: I've always had a hidden SSID with WPA2 personal + TKIP on my Wifi network and since Fedora 7 I can't connect to my wifi LAN via NetworkManager: it ALWAYS fails. The problem seems to be that it timeouts when negociatingthe connection. I've written a bash script to connect to my wifi network, it never failed to connect (I'm using it since 1 year now). here it is: #!/bin/bash MYSSID=my_ssid_name MYCHAN=8 echo cleaning eth1... /sbin/dhclient -r eth1 killall wpa_supplicant # the following is not used anymore since Fedora8 #echo Modprobing ipw2200 module ... #/sbin/modprobe -r ipw2200 #sleep 2 #/sbin/modprobe ipw2200 #sleep 10 echo configuring eth1 /sbin/ifconfig eth1 up /sbin/iwconfig eth1 mode managed channel $MYCHAN key off essid $MYSSID # sometimes you need to do that: (remove if not needed) #/sbin/iwconfig eth1 ap xx:xx:xx:xx:xx:xx echo WPA configuration ... # manual conf: echo PASS: echo 'ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel ' > /etc/wpa_supplicant/wpa_supplicant.conf wpa_passphrase $MYSSID |grep -v "^#" | grep -v "#psk=" >> /etc/wpa_supplicant/wpa_supplicant.conf # to autoconfigure the WPA encryption: #echo 'ctrl_interface=/var/run/wpa_supplicant #ctrl_interface_group=wheel #network={ # ssid="$MYSSID" # psk=77 #}' > /etc/wpa_supplicant/wpa_supplicant.conf echo starting WPA layer... wpa_supplicant -B -ieth1 -Dwext -c /etc/wpa_supplicant/wpa_supplicant.conf echo DHCP... /sbin/dhclient eth1 echo END! ########################### So there IS a problem with NetworkManager and hidden SSID on WPA (personal) + TKIP because when I disable "hide SSID", NetworkManager lists my wifi network and is able to connect to it.
Created attachment 324677 [details] System log excerpt related to NM failure and subsequent manual association Same issue for final F10 plus updates including NetworkManager-0.7.0-0.12.svn4326.fc10.x86_64. The wireless connections is defined in ifcfg-wlan0 (only connection apart from ifcfg-lo): # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. DEVICE=wlan0 TYPE=Wireless HWADDR=XX:XX:XX:XX:XX:XX BOOTPROTO=dhcp DHCP_HOSTNAME=fedora ONBOOT=yes USERCTL=no PEERDNS=yes IPV6INIT=no NM_CONTROLLED=yes WIRELESS_HIDDEN_SSID=yes ESSID=WLAN MODE=Managed RATE=Auto CHANNEL=Auto After associating manually by executing: iwconfig wlan0 key XXXXXXXXXXXXXXXXXXXXXXXXXX iwconfig wlan0 essid WLAN NM eventually succeeds in activating the wireless connection. There are related entries in /var/log/dmesg: wlan0: authenticate with AP XX:XX:XX:XX:XX:XX wlan0: authenticated wlan0: associate with AP XX:XX:XX:XX:XX:XX wlan0: RX AssocResp from XX:XX:XX:XX:XX:XX (capab=0x471 status=0 aid=2) wlan0: associated wlan0: disassociating by local choice (reason=3) wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate wlan0: authenticate with AP XX:XX:XX:XX:XX:XX wlan0: authenticated wlan0: associate with AP XX:XX:XX:XX:XX:XX wlan0: RX ReassocResp from XX:XX:XX:XX:XX:XX (capab=0x471 status=0 aid=2) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present After unhiding the SSID on the access point, NM connects without problem.
When this happens, can somebody run 'iwlist wlan0 scan' and report whether or not your hidden AP's BSSID shows up in the list? It won't report the SSID, but the hidden network's BSSID and other details should be there. If they aren't, there's no possible way for NM to automatically connect to the AP. Causes of this could be non-standard beacon timing settings on the AP, or just bad drivers.
(In reply to comment #3) For a D-Link DWL-G520 using driver ATH5K, the following observations hold: - 'iwlist wlan0 scan' does report the corresponding cell. However, NM does not succeed to establish a network connection with the hidden access point. The access point is not displayed by nm-applet, not even when the wireless network is defined in ifcfg-wlan0. - 'Connect to Hidden Wireless Network...' actually -does- set up a working wireless connection after entering ESSID and key. However, it is of course preferable to have an active network connection at an earlier stage. - Adding "WIRELESS_HIDDEN_SSID=yes" to ifcfg-wlan0 does not change anything nor does changing ESSID from its real name "WLAN" to "auto". Since 'Connect to Hidden Wireless Network...' actually does allow to connect to a hidden access point, it should be possible to allow this to the system wide wireless connection as defined in ifcfg-wlan0, too. Naturally, s-c-n would exhibit the corresponding option or activate it by default when configuring wlan0.
(In reply to comment #3) To be more precise, the hidden access point's BSSID is shown correctly.
I have had the same problem in F-10. The solution is to change NM_CONTROLLED to no, at which point it all works ok. With NM_CONTROLLED as yes, I get messages pretty much identical to those reported above.
(In reply to comment #5) > (In reply to comment #3) > To be more precise, the hidden access point's BSSID is shown correctly. Can someone please show the complete output of 'iwlist wlan0 scan' with the hidden network's BSSID and the other details that should be there? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 338875 [details] Output of 'iwlist wlan0 scan' for AP with hidden ESSID
From my iwlist scan: wlan0 Scan completed : Cell 01 - Address: XX:XX:XX:XX:XX:XX (removed for security) ESSID:"Seed Box" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=94/100 Signal level:-35 dBm Noise level=-127 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s Extra:tsf=000005f3c8480121 Extra: Last beacon: 120ms ago
(In reply to comment #9) The ESSID entry should equal "" when it's hidden, shouldn't it?
Well I'm not at all sure that the issue is whether the ESSID is hidden or not, but maybe something else? Either way, it seems that manually controlling the device works, but using NetworkManger does not and results in messages like those at the end of comment #2 appearing in the logs. So maybe what I'm seeing is slightly different, or maybe its not related to having a hidden ESSID, but to some other factor?
(In reply to comment #11) > Well I'm not at all sure that the issue is whether the ESSID is hidden or not, > but maybe something else? The title of the bug report is pretty clear on this point. - When the ESSID of my AP is set to visible, NM connects to it automatically without any problem. - Setting up the wireless connection through igcfg-wlan0, i.e. specifying the hidden AP's name exlicitly is not sufficient for NM to connect to it. - After adding the connection locally through "Connect to Hidden Wireless Network...", NM is able to connect to the hidden AP. Moreover, it does so automatically after starting a GNOME session, although it may take up to 30 secs until it actually happens. The downside is that network is not available during the boot process.
Well if the original issue can be solved and it turns out that my issue has a different cause, then we can open another bug I guess. But I thought it was similar enough to warrant reporting here, rather than open yet another bz.
Joachim; have you successfully connected to this AP before using NetworkManager, but now NM doesn't automatically connect to it any more? Can you check in GConf whether the 'seen-bssids' property for the your wifi connection is present? You can run gconf-editor and drill down to /system/networking/connections/<your wifi connection>/802-11-wireless/ and check the 'seen-bssids' property in that GConf directory. There should be a list of MAC addresses there, one of which should be the AP you've scanned in comment #8.
(In reply to comment #14) > Joachim; have you successfully connected to this AP before using > NetworkManager, but now NM doesn't automatically connect to it any more? No. I have said that NM succeeds to connect to an AP with hidden ESSID when and only when this connection is added through "Connect to Hidden Wireless Network..." on a per user basis. Note that herefore, only (1) the network name (ESSID), (2) the wireless key, and (3) the GNOME keyring password need to be entered. My complaint is that after setting up a global system connection ifcfg-wlan0 with the same information (1) and (2), NM actually fails to establish a connection although the info entered is the same as above. > Can you check in GConf whether the 'seen-bssids' property for the your wifi > connection is present? Yes, it is, and at each new GNOME session, NM connects successfully to the AP with hidden ESSID using the information stored in $HOME/.gconf/.. . However, let me repeat that this means that an active wireless connection is available only -after- logging in to GNOME whereas a system connection defined in ifcfg-wlan0 with ONBOOT=yes would in principle allow to bring up the network much earlier. It is the latter that doesn't work even when the ESSID is specified in ifcfg-wlan0 and the wireless key in keys-wlan0.
I should also note that "Connect to Hidden Wireless Network..." is not functional for current "rawhide" featuring NetworkManager-0.7.0.100-2.git20090408.fc11.x86_64 whereas comment #15 was based on observations from an updated F10 system. In the "rawhide" case, no request for the GNOME keyring password is issued which is probably the cause of the subsequent failure.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
No improvement for NetworkManager-0.7.1-8.git20090708.fc12. Any clue in which direction to investigate? The information provided by ifcfg-wlan0 including the ESSID of the AP is identical with the one provided inside a GNOME session via "Connect to Hidden Wireless Network...". Being able to connect to a hidden AP via ifcfg-wlan0 is by far the better choice since it allows all users to benefit from the system WLAN connection and because network is then already available early in the boot process.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
According to comment #18, this issue is still present for current "rawhide". Please, somebody reopen this bug and set "Version" to "rawhide". Thanks!
(In reply to comment #20) > According to comment #18, this issue is still present for current "rawhide". > Please, somebody reopen this bug and set "Version" to "rawhide". Thanks! Anyone can reopen a bug. I'm doing so for you adding my 2c: # iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: XXXXXXXXXXXXXX Channel:6 Frequency:2.437 GHz (Channel 6) Quality=70/70 Signal level=-39 dBm Encryption key:on ESSID:"" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s Bit Rates:9 Mb/s; 18 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=000000043d587181 Extra: Last beacon: 244ms ago IE: Unknown: 000700000000000000 IE: Unknown: 010882848B960C183048 IE: Unknown: 030106 IE: Unknown: 050400010000 IE: Unknown: 2A0100 IE: Unknown: 32041224606C IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: Unknown: DD0900037F0101001FFF7F IE: Unknown: DD1A00037F030100000000095B971CCE02095B971CCE64002C011F08 Cell 02 - Address: XXXXXXXXXXXXXXXX (same as above) Channel:6 Frequency:2.437 GHz (Channel 6) Quality=70/70 Signal level=-39 dBm Encryption key:on ESSID:"xanthos" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s Bit Rates:9 Mb/s; 18 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=000000043d5c13aa Extra: Last beacon: 6ms ago IE: Unknown: 000778616E74686F73 IE: Unknown: 010882848B960C183048 IE: Unknown: 030106 IE: Unknown: 2A0100 IE: Unknown: 32041224606C IE: Unknown: DD0900037F0101001FFF7F IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: Unknown: DD1A00037F030100000000095B971CCE02095B971CCE64002C011F08 If the network is visible all works well, if it is hidden I need to trigger with the "Connect to Hidden Network ..." option in nm-applet.
Changing the version. F9 was EOL'ed long ago (2009-07-10). The latest version mentioned is 12 from Comment 18, so I'm going with that for now. Please update the version to the most recent version experiencing this problem.
Issue is still reproducible for a fully updated F14 Beta RC3 including NetworkManager-0.8.1-6.git20100831.fc14. Connection "System <this_ap> (wlan0)" had been created by anaconda during a wireless network install after providing name and WEP key of the access point which was not hidden yet at that point. After hiding the SSID, NM does not connect to the AP anymore even though all relevant data is already present in files ifcfg-wlan0 and keys-wlan0. However, "Connect to Hidden Wireless Network..." allows to select "System <this_ap> (wlan0)" from the AP list and a working wireless connection is established without entering any further information like WEP key, etc. The obvious criticism is obviously why one needs to go through the extra setup dialog "Connect to Hidden Wireless Network...", when no additional information is necessary nor gathered from the user. NM should be able to use an AP with hidden SSID without further action provided it has already been defined in files ifcfg-wlanX and keys-wlanX.
In addition to comment 23, I have to add that the connection created through "Connect to Hidden Wireless Network..." importing "System <this_ap> (wlan0)" is volatile: it will have disappeared upon the next reboot ..
Created attachment 449843 [details] Hidden Wireless Network (System <this_ap> (wlan0)) After choosing access point "System <this_ap> (wlan0)" and entering the root password, the attached window appears which is almost entirely greyed out. After hitting "Connect", NM actually provides a working network connection. However, it has to be recreated upon every reboot or resume which make it disappear from section "Wireless Networks" of nm-applet.
Removing my email from the Cc list as I'm not concerned anymore.
Confirmed on F14 RC with iwlagn driver, NetworkManager-0.8.1-9.git20100831.fc14.x86_64, WiFi WPA2-Personal network with hidden SSID.
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
Please someone bump the Fedora version again, see comments #27 and #23.
Set version to 14 per comment 27 & comment 23 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm not sure if this helps but I'll report it anyway. I was using ndiswrapper to get a WPN111 wireless USB to work on Fedora. This did manage to auto-connect on both Fedora 12 and Fedora 14 on start up despite me having a hidden ESSID. I recently purchased a WPN311 PCI card which I installed so that I would have native support. It works OK (using the ath5k driver) but I now have the problem reported in this bug. Everytime I start up I have to "Connect to Hidden Wireless Network" to get it to connect. So ndiswrapper (plus windoze driver) can auto-connect on start up but ath5k can not.
Created attachment 473928 [details] lwlist wlan0 scan data Hidden Wireless 1 - iwlist wlan0 scan data Before connection in F14 Hidden Wireless 2 - iwlist wlan0 scan data After connection in F14 WAP {Linksys WRT300N - DD-wrt firmware} setup screenshots
I'm working from a Dell B130 with Broadcom wireless and F14. The Hidden Wireless doesn't auto connect is still an issue. Bug 516788 seems to be a duplicate or near cousin of this problem.
How long does it take to get a bug fixed around here? This issue has been around since F9, is reproducible and a PITA for those of us reliant upon wireless networking and networks with hidden SSIDs. This issue is currently preventing me from rolling a F14 machine out to other users since I'm unwilling to divulge the root password just so that they can connect to the wireless network. Can we raise the priority? Low priority isn't how I would describe this issue! I've yet to find any mention of a workaround for this issue so I guess I'm stuck until someone dains to fix it. Sorry for the rant - I'm normally more than willing to debug and help resolve an issue. When a bug has been around for this long with so much data on how it may be reproduced, I lose my cool somewhat.
> "I've yet to find any mention of a workaround for this issue so I guess I'm stuck until someone dains to fix it." Potentially untrue - I've just revisited my notes on how I overcame this (or a very similar issue) in F12. It seems that the following resolves the issue (somewhat counter-intuitively!): 1) Edit Connections (right click on NM panel icon) -> Wireless tab -> <Select wireless network> -> Edit 2) uncheck the "Available to all users" checkbox -> Apply After a reboot, I see NM make the connection to my wireless netowrk (hidden SSID) without user intervention. Can anyone confirm this? Mike
I've just tried Mike's "workaround" on my F14 build and it does appear to work. I'm not sure how a multi-user installation would cope, but for single user boxes it works fine.
Thanks Ian. From my limited testing lastnight, it *seems* to work OK on a multi-user installation. Once the "Available to all users" check box is cleared, both my wife and I are able to login, NM connecting to the wireless network without user intervention. This whole issue couldn't boil down to something as simple as an unintentional inversion of the checkbox value, could it? I'm not 100% sure what behaviour I'd expect to see if the wireless network was not "available to all users", but it certainly seems that the desired behaviour is obtained with the checkbox cleared.
Additional info. Fresh install of RH14 KDE spin, Fedora-14-i686-Live-KDE.iso, via USB key. NM was unable to connect to a hidden SSID no matter what I did on F14 side. The BSSID was specified, all data was ultimately proven to be correct and sufficient. Was only able to connect when I changed to router to broadcast the SSID. After connection was made, I stopped broadcasting the SSID, and NM was still able to reconnect, without making any changes on the F14 side. Rebooted F14, and still able to connect. There's clearly some initialization BTW there is no ability to indicate in the UI that the SSID is hidden or is available to all users, capabilities that do exist on Ubuntu--is that a Gnome thing?
FYI, issue appears to be resolved in FC15 with NetworkManager-0.8.9997-4.git20110620 Prior to this NM release, FC15 suffered the same issue as described above for FC14, with the exception that the workaround described in Comment 35 didn't work.
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