network-manager doesn't reconnect to wireless networks after rfkill soft blocks removed

[Jeff Lane ]

Testing Oneiric Alpha 3 on cert machines. On this machine, if I use the wireless hotkey combo to turn wireless off once, I am able to turn wireless back on again. However, on the second and subsequent attempts to turn wireless off and on using the hot key combo, the wireless remains disabled. The only recovery is to reboot the machine.

This machine does NOT have a physical slider, only the hotkey.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: linux-image-3.0.0-8-generic 3.0.0-8.10
ProcVersionSignature: Ubuntu 3.0.0-8.10-generic 3.0.1
Uname: Linux 3.0.0-8-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 1428 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf7cf8000 irq 46'
   Mixer name : 'Realtek ALC269VB'
   Components : 'HDA:10ec0269,10438437,00100100'
   Controls : 11
   Simple ctrls : 7
Date: Tue Aug 9 19:02:42 2011
HibernationDevice: RESUME=UUID=35f0f71a-9303-4eeb-a6d7-41c1cf4f8824
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha i386 (20110803.1)
MachineType: ASUSTeK Computer INC. 1001PXD
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-8-generic root=UUID=bbe0cd86-364f-4ba4-9c7d-7f9b165d66c1 ro quiet splash initcall_debug vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.0.0-8-generic N/A
 linux-backports-modules-3.0.0-8-generic N/A
 linux-firmware 1.56
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/12/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0105
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1001PXD
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0105:bd08/12/2010:svnASUSTeKComputerINC.:pn1001PXD:pvrx.x:rvnASUSTeKComputerINC.:rn1001PXD:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x:
dmi.product.name: 1001PXD
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Seth Forshee (sforshee)]

It looks like wireless was working fine when you reported the bug. Is this correct?

Here's what I'd like you to try. Get your machine into this state, and check the output of 'rfkill list'. Then press the wlan hotkey and check the output of the same command again. Is the state of any of the devices changing?

Next, use lsinput to identify the input device named "Eee PC WMI hotkeys" or something similar, which will be associated with some input/event<n> device. Then run 'sudo input-events <n>' and press the wlan hotkey. Does input-events output KEY_WLAN events when you press the hotkey?

Please also attach /var/log/syslog and the output of dmesg after wireless has stopped working. Thanks!

[Jeff Lane  (bladernr)]

> It looks like wireless was working fine when you reported the bug. Is this correct?
Yes, I had to reboot the system to get to the point where i could actually file the bug.

Here's what I'd like you to try. Get your machine into this state, and check the output of 'rfkill list'. Then press the wlan hotkey and check the output of the same command again. Is the state of any of the devices changing?

Yep... rfkill shows a soft block going on and off as I hit Fn-F2 (the wireless hotkey). However, while the network indicator menu reflects this by showing Wireless Enabled with or without a checkmark, the wireless device never re-connects to the AP and no available APs appear in the Network indicator menu.

[Jeff Lane  (bladernr)]

> Next, use lsinput to identify the input device named "Eee PC WMI hotkeys" or something similar, which will be associated with
> some input/event<n> device. Then run 'sudo input-events <n>' and press the wlan hotkey. Does input-events output KEY_WLAN
> events when you press the hotkey?

No... the hotkeys appear as event7, but when I press Fn+F2 repeatedly, input-events shows nothing and eventually exits after timing out.

> Please also attach /var/log/syslog and the output of dmesg after wireless has stopped working. Thanks!

I've attached a tarball that contains syslog, dmesg after the wifi stops working, and the output of rfkill showing the block on and off.
As I mentioned before, even when rfkill shows the softblock off and Enable Wireless is checked in the Networking indicator menu, the wi-fi device on this EeePC won't come back on until I've done a full reboot.

[Seth Forshee (sforshee)]

Also check the AT keyboard device with input-events to see if the wlan event appears. It doesn't look like there's any WMI hotkey event for your wlan hotkey. I assume your other hotkeys are working and generating events on the hotkey input device? It may just be that your machine doesn't generate a key event for the wlan key, as odd as that would be.

I can generate something that looks the same just by running 'rfkill block all' then 'rfkill unblock all'. My device isn't dead though -- I can get it back by deselecting and reselecting "Enable Wireless" from the applet, for instance. Give that a try, and if your experience matches mine then I think this is a network manager bug.

[Jeff Lane  (bladernr)]

You are correct, sir! so watching events for the AT keyboard still showed nothing when I hit Fn+F2 to turn wireless off and on, and as before, wireless never actually came back on. However, after clicking Enable Wireless to disable and re-enable it on the menu (after the hotkey borked it), wireless did indeed start working correctly again.

Granted, this is done on a different EeePC model. The one I filed this against originally is running stress tests at the moment and won't be available again until later this evening or tomorrow. I'll re-verify on that one too once it frees up.

[Jeff Lane  (bladernr)]

removing the blocks-hwcert tag because this does appear to be workaround-able using Seth's advice above

[Seth Forshee (sforshee)]

It's funny that these machines don't generate hotkey events. I've worked with two Eee PCs, and both have generated events for the wlan hotkey.

It seems like the real problem here is that network-manager doesn't reconnect when the soft block is removed, so I'm changing the affected package accordingly.

[Jeff Lane  (bladernr)]

@Seth: update for you. I just tested this on a Thinkpad Edge 11 that has a standard wireless hotkey (e.g. the key's primary function is wireless on/off, rather than using the Fn+F2 combo on the EeePCs I discovered this on) and this does not happen.

So in my experience so far, this issue only occurs on systems that use the Fn+F* combo to trigger wireless on and off.

lsinput on the Edge11 shows them as "ThinkPad Extra Buttons" rather than just HotKeys
/dev/input/event7
   bustype : BUS_HOST
   vendor : 0x17aa
   product : 0x5054
   version : 16641
   name : "ThinkPad Extra Buttons"
   phys : "thinkpad_acpi/input0"
   bits ev : EV_SYN EV_KEY EV_MSC EV_SW

but when I try input-events on that event (and event3, the AT Keyboard), nothing is captured yet again.

[Seth Forshee (sforshee)]

My Thinkpad T410 sends EV_SW_RADIO events when I flip the switch. Odd
again -- seems the machines I have send events, and the ones you have
don't :)

What I also note about my Thinkpad is that it only has a single rfkill
device, whereas most ACPI/WMI drivers create an additional device (why
they do this puzzles me). But on my Eee PC I note that if I use rfkill
to only block/unblock the phy0 device, it takes a while to notice the
block but starts to connect immediately upon unblocking. So maybe the
problem relates to having multiple rfkill devices without any events?
Just taking a guess.

[Mathieu Trudel-Lapierre (cyphermox)]

Well, NM indeed doesn't seem to always come up when dealing with soft blocks, but Fn-F7 works fine here for stopping and restarting wireless (but thats a hard block on dell-wifi). I have multiple killswitches registered: phy0 and dell-wifi for wifi. A soft block for phy0 shows the device disconnected and not able to bring up interfaces. Soft block for dell-wireless puts the device in "not ready" state which turns it unusable until you enable/disable wifi using the applet.

As such, I think it's worth noting this as affecting linux anyway: the Eeepc's drivers don't properly handle the soft killswitch event: they really should be causing a hard block, not a soft one (and without checking, it might be a soft one as a workaround in userland somewhere). This would need a separate bug, Jeff or Seth, care to open one against linux for the eeepc drivers?

[Seth Forshee (sforshee)]

The kernel defines a hard block as a "read-only radio block that cannot be overriden by software." I suspect that this block can be cleared with rfkill unblock. Jeff, can you check this?

[Jeff Lane  (bladernr)]

Hi Seth, Unfortunately, I can not. I'm back in NC now, while the systems are all up in Lexington. I've re-assigned this to Marc Legris, who works out of the Lex office full time.

Marc, can you help Seth out with this bug. I saw this issue on all three EeePC netbooks.

[Marc Legris (maaarc-deactivatedaccount-deactivatedaccount-deactivatedaccount-deactivatedaccount-deactivatedaccount)]

rfkill unblock does not return the wireless connectivity to the system. rfkill list show nothing is soft or hard blocked.

[Seth Forshee (sforshee)]

Okay, if rfkill unblock removes the soft block then it doesn't seem to qualify as a hard block according to the kernel's definition. So I don't think a bug against linux is needed.

Thanks Marc!

[Mathieu Trudel-Lapierre (cyphermox)]

It's roughly clear what the issue is, so marking this Triaged, I'll try to push out a patch to test a fix for this. Since it can easily be worked around, the priority should be left at Medium.

[Seth Forshee (sforshee)]

Mathieu: A similar issue has been reported in bug 826932, except this time the kill switch sets both soft and hard blocks. But as with this one the blocks are removed and wirless still doesn't connect. Would you mind taking a quick look at that one to see whether or not is should be marked as a duplicate of this one? Thanks!

[Derek (bugs-m8y)]

Hm. This looks roughly like what I'm experiencing where if I uncheck wifi in gnome-shell or XFCE4 (haven't tried in Unity yet) it is permanently killed. XFCE4's network tool reports that the rf kill switch has been used (not so, I just used the network gui).

Oddly, if I actually toggle the real physical rf kill switch, while bluetooth goes on and off, wifi stays dead.

I have to reboot to recover.

Yes, I know not precisely the same machine/pattern, but still seems related so just gonna watch this one to see what happens.

Right now, I just avoid disabling wireless as much as possible.

Oh. And was fine in Natty.

[Alican Kaylan (alicankaylan)]

this affects me too. I am using ubuntu 11.10 on my dell studio 1558.

It keeps saying that device is not ready. The only workaround i can find is to uncheck the enable networking option from its menu and then re-enable it.