Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Password dialog prevent auto-reconnection|
|Product:||[Fedora] Fedora||Reporter:||Saikat Guha <sg266>|
|Component:||NetworkManager||Assignee:||Lubomir Rintel <lkundrak>|
|Status:||ASSIGNED ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||clancy.kieran+redhat, dcbw, ggillies, kelvin, mrunge, rth, tore, wtogami|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Saikat Guha 2008-09-21 17:17:30 EDT
Description of problem: If a wi-fi connection is lost, and NM is unable to reconnect immediately (say because of ephemeral interference), it tosses up a password dialog (even though the wi-fi password has not changed). While the password dialog is up, NM does not attempt to reconnect. It requires human intervention to cancel the password dialog and reconnect to wi-fi. This is clearly suboptimal if one wishes to use NM to connect to wi-fi from an unattended laptop. Every so often the laptop in my apartment loses signal due to the neighbors nuking some hot dogs, and then has to wait until I return from work to reconnect. How reproducible: Always Steps to Reproduce: 1. Use NM 2. Nuke hot dogs for two minutes or until signal is lost. 3. Keep nuking until NM fails to reconnect on its first attempt and tosses up a passwd dialog. 4. Stop nuking hot dog Actual results: NM stays offline long after hot dogs have cooled, the sun has set, and a new dawn rises. Expected results: NM reconnects by the time you bring warm hotdogs to the laptop. Additional info:
Comment 1 Tore Anderson 2009-08-26 11:32:14 EDT
Confirmed - this is a rather annoying bug. An even easier way to reproduce it that does not require hot dogs is to simply power down the access point for a while, by the way. :-) What seems to happen is that NM immediately attempts to re-associate with the AP after it gets out of range - but at this point the wireless network is not available anymore, so I think NM should instead have stayed in offline mode until the wireless network showed up again. When it does, NM should be able to associate again with no problems. Tore
Comment 2 Matthias Runge 2009-11-24 04:56:11 EST
Since rawhide is f12 now and NM seems to work as expected, this bug can be closed, right?
Comment 3 Tore Anderson 2009-11-24 08:13:30 EST
I'm 99.99% certain this issue is still present in F12. At least I rebooted my wireless router the other day and I got the PSK dialogue immediately after NM failed to reconnect (to the then-unavailable network). After the wireless router had finished rebooting, NM was just sitting there waiting for the PSK to be entered even though the WLAN was available again. Unless my memory timeline is really screwed up this happened long after I upgraded my laptop to F12. Tore
Comment 4 Dan Williams 2010-03-23 21:45:14 EDT
NM gives the suppliant time to reconnect when the connection drops (due to microwave, etc) and if it doesn't reconnect within that amount of time, it assumes the passphrase is wrong. This is partially because we don't enough info from the stack about *why* we couldn't reconnect. That's just a limitation of how the wireless stack is right now, but we're working to change that.
Comment 5 Dan Williams 2010-04-08 19:01:15 EDT
If people with this problem can follow the directions here: http://live.gnome.org/NetworkManager/Debugging under "Debugging WiFi Connections" and then attach the wpa_supplciant log, that would help to figure out why the reconnection isn't working.
Comment 6 Tore Anderson 2010-04-12 13:16:57 EDT
Hi Dan, I've reproduced the problem with the extra wpa_supplicant debug settings, and the requested info from the page you linked to is as follows: Distribution name and version: Fedora 12 Kernel version: 126.96.36.199-99.fc12.x86_64 Network device's brand and model: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) I will shortly attach the output from "lspci -vn", output from "dmesg", messages and wpa_supplicant.log log files. I (manually, so +/- a few secs) noted the timestamps of different stages of reproducing the problem (system timezone is CEST, or UTC+2): 1) 18:49:52 NetworkManager started, WLAN connection is established within a few seconds with no interaction from me. 2) 18:50:38 Switched of the radio on my AP (physical rfkill button) 3) 18:51:01 NM systray icon changes from the normal blue signal level bars to the two dots with a rotating blue thing 4) 18:51:28 WLAN passphrase dialogue box appears (with passphrase field pre-filled). NM systray icon is still the dots+rotating thing (lower dot is green, upper one gray). 5) 18:53:06 Switched radio on the AP back on again 6) 19:00:09 No change since #4, so I pressed the "accept" (or something like that) button on the passphrase dialog. The WLAN connection re-established OK within a few seconds. Let me know if you need more information - this issue is 100% reproducible for me so I'll be happy to help out. Tore
Comment 7 Tore Anderson 2010-04-12 13:19:16 EDT
Created attachment 406022 [details] Output from "lspci -vn"
Comment 8 Tore Anderson 2010-04-12 13:19:44 EDT
Created attachment 406023 [details] Output from "dmesg"
Comment 9 Tore Anderson 2010-04-12 13:20:51 EDT
Created attachment 406025 [details] /var/log/messages (from when reproducing the problem)
Comment 10 Tore Anderson 2010-04-12 13:21:16 EDT
Created attachment 406026 [details] /var/log/wpa_supplicant.log (from when reproducing the problem)
Comment 11 Dan Williams 2010-05-25 17:15:31 EDT
(In reply to comment #6) > Hi Dan, > > I've reproduced the problem with the extra wpa_supplicant debug settings, and > the requested info from the page you linked to is as follows: > > Distribution name and version: Fedora 12 > Kernel version: 188.8.131.52-99.fc12.x86_64 > Network device's brand and model: Intel Corporation PRO/Wireless 3945ABG > [Golan] Network Connection (rev 02) > > I will shortly attach the output from "lspci -vn", output from "dmesg", > messages and wpa_supplicant.log log files. > > I (manually, so +/- a few secs) noted the timestamps of different stages of > reproducing the problem (system timezone is CEST, or UTC+2): > > 1) 18:49:52 NetworkManager started, WLAN connection is established within a few > seconds with no interaction from me. > 2) 18:50:38 Switched of the radio on my AP (physical rfkill button) So this is the key. From the logs, it looks like NetworkManager was never notified by the kernel that the rfkill switch was now blocking wifi. When you do this, can you: cat /sys/class/rfkill/*/type cat /sys/class/rfkill/*/state rfkill list and we can see what state the rfkill switches are in after you flip the switch to "off"? It's also very odd that your 'dmesg' output doesn't talk about rfkill, as usually you'll see: iwlagn 0000:02:00.0: RF_KILL bit toggled to disable radio. if you don't see something like that in 'dmesg', then it's pretty clear that we have kernel problems here that are unrelated to NM. What laptop model and vendor do you have? > 3) 18:51:01 NM systray icon changes from the normal blue signal level bars to > the two dots with a rotating blue thing Right, because NM didn't get notified of the killswitch being flipped to off, and neither did the kernel or apparently the wifi driver and the 80211 stack. This is probably the reason for the "No probe response from AP 00:22:07:01:8f:6a after 500ms, disconnecting." message in the dmesg output. > 4) 18:51:28 WLAN passphrase dialogue box appears (with passphrase field > pre-filled). NM systray icon is still the dots+rotating thing (lower dot is > green, upper one gray). Right, becasue a reconnection to the AP failed and NM currently assumes that your password is wrong when that happens (which in some cases is actually true, but this is more of a bug in NM). > 5) 18:53:06 Switched radio on the AP back on again > 6) 19:00:09 No change since #4, so I pressed the "accept" (or something like > that) button on the passphrase dialog. The WLAN connection re-established OK > within a few seconds. Right, since NM didn't get notified of the killswitch, it can't auto-reconnect you since it still thinks the wifi device is up and working (and apparently the driver thinks this too). So in summary, this appears to be a core kernel problem with rfkill. When you flip the switch, if you do *not* see wifi being blocked when you run the command 'rfkill list' then we need to file a new bug against the kernel for this rfkill issue and assign it to Matthew Garrett for further diagnosis.
Comment 12 Tore Anderson 2010-05-26 01:30:55 EDT
(In reply to comment #11) > (In reply to comment #6) > > 2) 18:50:38 Switched of the radio on my AP (physical rfkill button) > > So this is the key. From the logs, it looks like NetworkManager was never > notified by the kernel that the rfkill switch was now blocking wifi. I think you misunderstood me - the rfkill button in question is on the wireless access point, not on my laptop. The intended effect is to simulate the WLAN going out of range (and later reappearing). I could just as well have disconnected the power cord on the AP instead. Tore
Comment 13 Dan Williams 2010-05-26 05:42:56 EDT
Yep, most certainly did misunderstand.
Comment 14 Kelvin J. Hill 2011-06-19 18:06:09 EDT
And the solution is?
Comment 15 Richard Henderson 2012-01-02 22:00:07 EST
Still present in Fedora 16. With the additional hilarity of *two* password dialogs. The first has the swanky black-ish gnome3 look, and the second the more traditional grey. I have no idea where the second dialog is coming from, or how to find out. But it's Definitely Annoying.
Comment 16 Kieran Clancy 2012-02-02 19:23:06 EST
This is madness - sometimes I come back to my laptop (F16) and there'll be 3 or 4 dialogs (the old grey ones). Then sometimes there'll be a black gnome3 one too. This didn't happen once for me with Fedora 14. I'm only 2 metres away from the router, so I doubt it's a problem with interference.
Comment 17 Fedora Admin XMLRPC Client 2015-08-18 10:56:25 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.