Red Hat Bugzilla – Bug 463110
Password dialog prevent auto-reconnection
Last modified: 2015-08-18 10:56:25 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.
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
NM stays offline long after hot dogs have cooled, the sun has set, and a new dawn rises.
NM reconnects by the time you bring warm hotdogs to the laptop.
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.
Since rawhide is f12 now and NM seems to work as expected, this bug can be closed, right?
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.
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.
If people with this problem can follow the directions here:
under "Debugging WiFi Connections" and then attach the wpa_supplciant log, that would help to figure out why the reconnection isn't working.
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.
Created attachment 406022 [details]
Output from "lspci -vn"
Created attachment 406023 [details]
Output from "dmesg"
Created attachment 406025 [details]
/var/log/messages (from when reproducing the problem)
Created attachment 406026 [details]
/var/log/wpa_supplicant.log (from when reproducing the problem)
(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:
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.
(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.
Yep, most certainly did misunderstand.
And the solution is?
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.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.