Description of problem: When trying to make a wireless connection NM offers 4 WEP-related options and 2 WPA-related options. If the connection fails the dialogue returns, but this time only the WEP-related options populate the list. There is no way of re-trying the WPA pass-phrase. Version-Release number of selected component (if applicable): 0.7.0-0.11.svn4229.fc10.i386 and versions prior to this during the last week. How reproducible: Consistent Steps to Reproduce: 1. Try to make a wifi connection with WPA. 2. When it fails, try to give the passphrase again. 3. Actual results: It is impossible to re-try the connection, so you have to cancel. Expected results: The drop-down list should contain both WEP and WPA options, as on the first attempt. Additional info:
Can you paste in the 'iwlist wlan0 scan' output for your AP so I can see what the AP actually supports? Also, what wireless hardware do you have in your machine, and what kernel version are you running?
iwlist wlan0 scan wlan0 No scan results Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter 2.6.27.5-113.fc10.i686 Bug #469120 gives a lot of related information
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I occasionally see this on my system, using iwl4965: kernel-2.6.27.7-134.fc10.x86_64 NetworkManager-0.7.0-0.12.svn4326.fc10.x86_64 wpa_supplicant-0.6.4-2.fc10.x86_64 I am joining a hidden wireless network (ESSID "wpa", using WPA Enterprise), and it occasionally just works and I can login to it. For a while, then at seemingly random intervals I will get kicked out and cannot rejoin. Sometimes it kicks me out at the initial attempt and I see the symptoms in this bug. I've collected -ddddd -t logs from wpa_supplicant, and it seems like it thinks the AP does not support WPA: 1229635332.714980: Selecting BSS from priority group 0 1229635332.715012: Try to find WPA-enabled AP 1229635332.715038: 0: 00:11:20:28:19:b0 ssid='visitor' wpa_ie_len=0 rsn_ie_len=0 caps=0x1 1229635332.715070: skip - no WPA/RSN IE 1229635332.715094: Try to find non-WPA AP 1229635332.715119: 0: 00:11:20:28:19:b0 ssid='visitor' wpa_ie_len=0 rsn_ie_len=0 caps=0x1 1229635332.715150: skip - SSID mismatch 1229635332.715174: No APs found - clear blacklist and try again 1229635332.715198: Removed BSSID 00:00:00:00:00:00 from blacklist (clear) 1229635332.715227: Selecting BSS from priority group 0 1229635332.715252: Try to find WPA-enabled AP 1229635332.715379: 0: 00:11:20:28:19:b0 ssid='visitor' wpa_ie_len=0 rsn_ie_len=0 caps=0x1 1229635332.715411: skip - no WPA/RSN IE 1229635332.715435: Try to find non-WPA AP 1229635332.715460: 0: 00:11:20:28:19:b0 ssid='visitor' wpa_ie_len=0 rsn_ie_len=0 caps=0x1 1229635332.715490: skip - SSID mismatch 1229635332.715515: No suitable AP found. However, that is the AP I've been able to associate with in the past -- the net admins assure me that all of the APs in our support WPA. I think my issue with getting kicked off the network is related -- odds are good that I eventually get re-associated with an AP that wpa_supplicant doesn't believe has WPA. What further debugging information can I collect? I can get wpa_supplicant debug logs, but I'm having trouble getting NetworkManager to spit out debugging info for me -- it seems like it should be syslog'ing to user.debug, but it doesn't seem to be. I've collected some debug logs from iwlagn, but I'm not anxious to go through another ~600 MB log file. Results from 'iwlist scan wlan0' from a failure instance just now: wlan0 Scan completed : Cell 01 - Address: 00:11:20:28:19:B0 ESSID:"visitor" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=76/100 Signal level:-58 dBm Noise level=-127 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=00000292b4778192 Extra: Last beacon: 67ms ago And from a few minutes ago (don't know if it would have worked then or not, did not try): wlan0 Scan completed : Cell 01 - Address: 00:11:20:28:19:B0 ESSID:"visitor" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=90/100 Signal level:-57 dBm Noise level=-93 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=00000292acff0195 Extra: Last beacon: 9ms ago Cell 02 - Address: 00:18:74:4B:18:A0 ESSID:"visitor" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=38/100 Signal level:-86 dBm Noise level=-127 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=00000a0ad98306aa Extra: Last beacon: 2540ms ago Cell 03 - Address: 00:0B:5F:81:0E:92 ESSID:"visitor" Mode:Master Channel:11 Frequency:2.462 GHz (Channel 11) Quality=48/100 Signal level:-80 dBm Noise level=-127 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=0000091b5d29a1a1 Extra: Last beacon: 2336ms ago Please let me know what I can do to help solve this -- it is very frustrating when this works some of the time, especially when it seems to be rock-solid using my WPA Enterprise setup at home.
It is probably obvious, but I feel I should mention that the 'visitor' network is completely open. Could this be related to the problem?
Mine is a WPA-PSK network. Although it may be a completely separate problem, other network managers usually show me at least one wifi network in the vicinity, but with NM in F10 I don't see any.
Created attachment 327469 [details] Don't prematurely stop parsing when looking an WPA/RSN IE This patch seems to fix the issue I've been having; it's been stable for over an hour now, but it also hasn't had to re-associate with the AP, so the acid test has not been done. The problem was that wpa_supplicant would stop scanning the list of IEs sent/returned for WPA info when it hit an IE with the number 0 -- the SSID IE. Of course, this was always the first IE in the request, so we'd never see that we requested WPA in the first place. I'm not sure why it did not hit 100% of the time -- I can only guess that timing played a role.
Argh, that's a crap patch. It's checking for p==NULL...
More info: when I first tried testing this, dbus wouldn't start up wpa_supplicant, which I thought to be related to it running out of my home directory. It was segfaulting, I'm sure, now that I see the bug in my patch. But it worked when ran by hand, so it never hit wpa_supplicant_event_associnfo(). I had started looking at that function based on the debug logs where I saw that it was missing the IE WLAN_EID_VENDOR_SPECIFIC element, though on closer inspection, the request had a different value there and so it would clear the WPA IE using wpa_sm_set_assoc_wpa_ie(). 229635322.636156: req_ies - hexdump(len=29): 00 0c 6f 72 6e 6c 2d 76 69 73 69 74 6f 72 01 04 02 04 0b 16 dd 07 00 50 f2 02 00 01 00 1229635322.636196: resp_ies - hexdump(len=32): 01 04 82 84 8b 96 dd 18 00 50 f2 02 01 01 02 00 03 a5 00 00 27 a5 00 00 42 54 5e 00 62 43 2f 00 1229635322.636238: WPA: clearing own WPA/RSN IE I missed that the request had 0x0050f2020001 vs 0x0050f2010100.
First question to ask is if the AP is masquerading as two different SSIDs using the same BSSID, which some Cisco APs can do. It's called "Guest SSID" mode. One SSID is unsecured and broadcasts its SSID, and the other is secured and does not broadcast the SSID. If that's the case (ask your admins perhaps) then there's not too much that NM or the supplicant can do; even Cisco does not recommend hiding the SSID: ------------------------------------ http://supportwiki.cisco.com/ViewWiki/index.php/FAQ_on_Cisco_Aironet_Wireless_Security Q. If I disable SSID broadcast, can I achieve enhanced security on a WLAN network? A. When you disable SSID broadcast, SSID is not sent in Beacon messages. However, other frames such as, Probe Requests and Probe Responses still have the SSID in clear text. So you do not achieve enhanced Wireless security if you disable the SSID. The SSID is not designed, nor intended for use, as a security mechanism. In addition, if you disable SSID broadcasts, you can encounter problems with Wi-Fi interoperability for mixed-client deployments. Therefore, Cisco does not recommend that you use the SSID as a mode of security. ------------------------------------ If the AP isn't broadcasting it's IE, then the supplicant cannot figure out what the encryption settings are and it's a lot harder to connect. We may be able to make the driver/supplicant/nm probe-scan the AP to detect the SSID & WPA IEs. As your iwlist output shows, the WPA Enterprise AP is nowhere to be found. If the driver can't see it, it's quite unlikely that you will be able to connect. Have you tried doing the "Connect to hidden network..." option and selecting the connection you've created from the dropdown list? Does that work every time even if it's a manual process? That would give some clue as to where to start diagnosing the issue, whether it's a driver issue or an NM/supplicant issue.
My router is a Netgear, and I do not believe it has the capability of masquerading SSID's as you describe. It is set to broadcast, and my main laptop can pick up the signal immediately. Connect to Hidden Network fails in exactly the same way as the automatic connect, and when it fails it does not give the opportunity to re-enter the WPA key, as described above.
Anne: when your connection fails, do you see looping association attempts when you run 'dmesg'? I'm seeing one per second here. Dan: I'll ask tomorrow, but Comment #10 pretty well describes the setup locally -- we have two SSIDs setup on the same set of access points. We broadcast the unsecured network's SSID to make life easier for visitors, and use the hidden WPA secured one for employees. I read the text you quoted more as a note that hiding the SSID doesn't give any security benefits -- and I believe the interoperability issues may very well mean Linux. :) My Windows and Mac colleagues have no problems with the wireless config, and constantly give me a hard time about trying to get it work with Linux instead of switching. I only use the "Connect to hidden network..." option to connect to this network, and have disabled auto-connection. It is hit or miss -- it will work great quite a bit, but occasionally it decides to not connect, and nothing will persuade it. When it decides not to work, it will loop associating with an AP, then disassociating, once per second, usually until I shutdown the network stack and bring it back up. One time, while I was capturing debug information, it managed to break out of this loop and actually connect to the network. Also of note, the looping starts about 3 seconds after wpa_supplicant is started by NetworkManager, before anyone is logged into the machine. I have kernel logs, wpa_supplicant.log (-ddddd), and /var/log/messages for a working boot, a boot that starts broken but recovers, and a boot that stays broken. I'll attach them to this bug, but do you think I should log a separate bug, given the likelyhood of "Guest SSID" mode being used?
Created attachment 327604 [details] Logs for working and broken attempts to connect to hidden network Here are the logs from three attempts, named according to attempt: working-* Debug logs of everything going smoothly recovered-* Fails, looping 1 assoc/sec, then recovers and succeeds never-recovered-* Fails, looping 1 assoc/sec, never recovers I obsoleted the bogus patch I attached, as no one should even consider applying it.
I ran tail /var/log/dmesg -F then attempted a connection to a Hidden Network (no network is listed on the first screen). I was offered myLAN and System myLAN (wlan0). This seemed the most likely, so I tried that. No activity whatsoever showed up in dmesg. I then tried myLAN, saw the connection attempt as cpu activity, but again, no output to dmesg. This resulted in the return to the password dialogue which does not offer WPA password entry. OTOH, it did result in a popup saying that the network had been disconnected. I then discovered that output was to /var/log/messages, so I tried again. Activity was, of course, identical. The complete output is: Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) starting connection 'Lydgate2' Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): device state change: 3 -> 4 Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): device state change: 4 -> 5 Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0/wireless): access point 'Lydgate2' has security, but secrets are required. Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): device state change: 5 -> 6 Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): device state change: 6 -> 4 Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): device state change: 4 -> 5 Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0/wireless): connection 'Lydgate2' has security, and secrets exist. No new secrets needed. Dec 22 09:51:47 AAO NetworkManager: <info> Config: added 'ssid' value 'Lydgate2' Dec 22 09:51:47 AAO NetworkManager: <info> Config: added 'scan_ssid' value '1' Dec 22 09:51:47 AAO NetworkManager: <info> Config: added 'key_mgmt' value 'WPA-PSK' Dec 22 09:51:47 AAO NetworkManager: <info> Config: added 'psk' value '<omitted>' Dec 22 09:51:47 AAO NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Dec 22 09:51:47 AAO NetworkManager: <info> Config: set interface ap_scan to 1 Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected Dec 22 09:51:47 AAO NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning Dec 22 09:52:02 AAO NetworkManager: <info> wlan0: link timed out. Dec 22 09:52:12 AAO NetworkManager: <info> Activation (wlan0/wireless): association took too long. Dec 22 09:52:12 AAO NetworkManager: <info> (wlan0): device state change: 5 -> 6 Dec 22 09:52:12 AAO NetworkManager: <info> Activation (wlan0/wireless): asking for new secrets Dec 22 09:52:12 AAO NetworkManager: <info> (wlan0): supplicant connection state: scanning -> disconnected Dec 22 09:52:20 AAO NetworkManager: <WARN> get_secrets_cb(): Couldn't get connection secrets: applet-device-wifi.c.1542 (get_secrets_dialog_response_cb): canceled. Dec 22 09:52:20 AAO NetworkManager: <info> (wlan0): device state change: 6 -> 9 Dec 22 09:52:20 AAO NetworkManager: <info> Activation (wlan0) failed for access point (Lydgate2) Dec 22 09:52:20 AAO NetworkManager: <info> Marking connection 'Lydgate2' invalid. Dec 22 09:52:20 AAO NetworkManager: <info> Activation (wlan0) failed. Dec 22 09:52:20 AAO NetworkManager: <info> (wlan0): device state change: 9 -> 3 Dec 22 09:52:20 AAO NetworkManager: <info> (wlan0): deactivating device (reason: 0).
I have a working theory on the events that lead to the looping messages in my case. NetworkManager starts up, does its init, and since there are no auto-connections on the wlan0 device, deactivates it. The call chain: nm_device_deactivate() -> nm_device_deactivate_quickly() -> nm-device-wifi::real_deactivate_quickly() -> nm_device_wifi_set_ssid() -> ioctl(SIOCSIWESSID) with flags set to 1 (disable/any) In the kernel, the mac80211 stack takes this and auto-associates with the SSID 'visitor', as that is the only visible network. wpa_supplicant sees the incoming association information, determines that we should not be associated with that network and de-associates. wpa_driver_wext_disassociate() gets called, which ends up with an ioctl(SIOCSIWMLME, IW_MLME_DISASSOC) to the kernel. That ends up in net/mac80211/wext.c::ieee80211_ioctl_siwmlme() and calls ieee80211_sta_disassociate(). I do not see any callchain that leads to state being changed from IEEE80211_ASSOCIATED. We then receive a de-authenticate packet from the AP, which leads us eventually to net/mac80211/mlme.c::ieee80211_rx_mgmt_deauth(), which sets a timer to fire in IEEE80211_RETRY_AUTH_INTERVAL jiffies because state == IEEE80211_ASSOCIATED. I have partially confirmed my hypothesis by observing wlan0 in the looping state, noting that 'iwconfig wlan0' has an ESSID of 'visitor', and that the command 'iwconfig wlan0 essid nonesuch' causes the looping to stop. I can then successfully connect to my hidden 'wpa' network. I think the issue I am tracking may be significantly different than the one Anne is tracking. Mine appears to be with the wireless support in the kernel -- should I open a bug against the kernel, or is there a better component to attach it to?
Filed bug 477821 against the kernel to cover the looping association problem I've seen. I'm running with a patched kernel now, will see if this fixes my getting kicked off the protected network issue once I'm back from holidays.
Created attachment 329077 [details] Log - NM loses connection and cannot re-connect
After many attempts to rule out possible external interference I left the netbook running overnight with an active wifi connection. It dropped the link at a little after midnight and could not re-connect. After a time it removed the address for the interface.
Anne: does this still happen with latest F10 updates and latest kernel? If it's still a problem, what kernel are you running? Can you provide the output of "/sbin/iwlist wlan0 scan" so we can see what the AP is actually reporting?
At the moment it's hard to find what is happening, due to bug #485097. KNetworkManager was handling things fine, an update to NM broke that, and now I can only connect if both NM and KNetworkManager are running, so I don't know what is handling what. The only observations I can offer are Drop-outs were infrequent and immediately reconnected when KNetworkManager was handling it. When I tried to connect this morning using only NM, I was seeing WPA as an option for handling the key so that part is better. Unfortunately I still could not connect until I started KNetworkManager as well. They are both running at the moment. /sbin/iwlist wlan0 scan wlan0 No scan results The router definitely broadcasts, and my Mandriva laptop has no problem with it.
So are you using KNetworkManager or the GNOME nm-applet?
At this moment, both, as neither seems to be able to connect without the presence of the other. However, I definitely got the gnome nm-applet request for a passphrase this morning. Sorry I can't be more helpful. I'll try to experiment more today and let you know if I discover anything useful.
Ok; if the AP is WPA-enabled, I'd expect that WPA would be an option in the dropdown list when it asks for the passphrase again (becuase it couldn't reconnect). If that's not the case, let me know. The original report was about WPA not showing up in that list when the gnome applet was re-asking.
I think this is good news from my POV and bad news from yours. I have tried twice more today, and both times NM has managed to connect first time. Unless I get a drop-out (some days I never get one) I will not be able to test the re-connect situation. I'll report back next time I see one of those. AAnne
Ok; let me know. If you can, make a note of all of the items in the dropdown menu when NM asks for the password, and let me know what they are. Thanks!
I lost the connection last night. I can confirm that WPA is now offered for re-connection - unfortunately, however, it was not able to make the connection and after 3 retries I cancelled. Due to the anxiety of the moment I forgot to check what other options were offered - sorry. Dan, this failure to reconnect gives every appearance of a stale lock. Right from the start, it has been impossible to re-connect after a failure. Somewhere between 60 and 90 minutes the situation changes and connection can take place.
Having logged out this morning, I couldn't get back in, so I had plenty of time to study the dropdown menu - not that I needed much time. It offered WPA, and nothing else.
(In reply to comment #27) > Having logged out this morning, I couldn't get back in, so I had plenty of time > to study the dropdown menu - not that I needed much time. It offered WPA, and > nothing else. nm-applet will usually offer you the best security available, thus if the AP advertises WPA capability and your wifi card supports WPA, NM won't offer the ability to connect with WEP becuase you can certainly do WPA. So do you consider the issue fixed then?
Yes, I consider this fixed. The associated problem of not re-connecting remains, but is a separate issue. Thanks for sorting it
Ok, thanks for the confirmation.