Bug 463110

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

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.

Tore

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:

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.

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: 2.6.32.11-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

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: 2.6.32.11-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.

(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

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.