Description of problem: If i activate "airplane mode" in the network manager, my wireless card goes off (OK) but once the airplane mode is activated, i cannot deactivate it and my card remains permanently switched off. I have to use Windows and my wireless utility to switch my wireless card on again. For this reason i consider this bug to be very serious. Version-Release number of selected component (if applicable): Fedora 15 (not installed, using the live CD) How reproducible: Always reproductible Steps to Reproduce: 1.Open network manager 2.Activate airplane mode -> wireless card is switched off 3.Try to deactivate airplane mode -> wireless card cannot be switched on again Expected results: Wireless card should be switched back on when leaving airplane mode. Even if i reboot the computer or play with the hard switch, the card remains powered off. When booting i get something like "Radio disabled by HW RF Kill switch" in my dmesg Additional info: My bluetooth card behaves correctly. Only the wireless card is affected. Wireless card model : Intel Corporation PRO/Wireless 2200BG Laptop : HP Compaq nx8220 The rfkill state is 2 (RFKILL_STATE_HARD_BLOCKED). It cannot be written (forced) to 0
Created attachment 504554 [details] Airplane activation screenshot To be more precise it seems to be a bug from the control center, not the network manager
What do you get of $ rfkill list Try # rfkill unblock all Maybe, platform driver (hp-wmi) could block wireless. Check if it is loaded: $ lsmod | grep hp And try removing the driver: # rmmod -f hp-wmi # rfkill unblock all $ rfkill list
I had this problem on a Toshiba Satellite pro 64bit FC15. Wireless reported in airplane mode and the control was greyed out. I could turn the wireless off with a switch on the front of the laptop. I turned off wireless using this switch, rebooted, turned switch on. All now OK.
Hi, "rfkill unblock all" successfully re-activate my wireless card ! Anyway the bug remains in the control center gui. Here is the output of rfkill list after activating airplane in control center gui. The output remains the always the same even if I try to deactivate airplane within control center gui... [root@localhost liveuser]# rfkill list 0: hp-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes 2: hp-bluetooth: Bluetooth Soft blocked: yes Hard blocked: no Thanks a lot for your help ! Now i won't have to re-setup M$ windows to reactivate my card :-)
That's not a control center bug, rather a kernel one. Please, make sure you have enabled WiFi by a hardware switch. And, try to activate a WiFi with a key combination for your laptop. If that doesn't help, hp-wmi platform driver is misbehaving for your laptop and you should file a bug against kernel. If removing hp-wmi driver (described in comment #2) helps, you can blacklist the driver permanently: # echo "blacklist hp-wmi" >> /etc/modprobe.d/blacklist.conf
Do you have hp-wmi loaded? Or not? If so, does blacklisting resolve the problem?
Hi guys, by default hp-wmi is loaded on my system. I tried unloading it and then activate / deactivate airplane mode. My wireless network connection got well deactivated / activated so there is nothing annoying here, but... in that case, airplane seems to be "just" a software play with the status of the card. Indeed, there is a blue led showing the status of the wireless card (on/off). When hp-wmi is not loaded, activating/deactivating airplane mode has no effect on it (the led remains on) Therefore I think that without hp-wmi, airplane mode doesn't really switch off my wireless card. (with hp-wmi, activating airplane switch off the led, but -- here is the bug -- it never switches it on when leaving airplane mode) Anyway, while "rfkill unblock all" sucessfully re-activate my card, i'm not sure it is a kernel bug... If it was, "rfkill unblock all" wouldn't work, would it ?? Let me know if you want more testing...
If rfkill unblock all works, this sounds like a userspace issue.
I think I might found the problem, From latest git pull, On line 3305-3307 in src/nm-manager.c : old_enabled = radio_enabled_for_rstate (rstate, TRUE); rstate->user_enabled = enabled; new_enabled = radio_enabled_for_rstate (rstate, FALSE); When disabling a wifi, old_enabled != new_enabled and new_enabled == 0; Which in turn will run the following lines: if (new_enabled != old_enabled) { manager_update_radio_enabled (self, rstate, new_enabled); /* For WiFi only (for now) set the actual kernel rfkill state */ if (rstate->rtype == RFKILL_TYPE_WLAN) rfkill_change_wifi (rstate->desc, new_enabled); } But when re-enabling wifi, the case will be: old_enabled == new_enabled and new_enabled == 0; which in that case the enabling code will never get ran. Hope it helps.
I am not technically capable of fixing this issue following Arief's comment. Fedora 15 didn't have this issue for me, until a recent update to network manager - et al. I'm not 100% sure it was that particular update that did it, but it seems likely. The symptoms I have is this: Airplane mode is on in the Network Settings screen. When I turn it off, I am unable to turn the WiFi on. I close the screen, and immediately return to the Network Settings and to my great surprise, Airplane Mode is back on. rfkill unblock all does not change anything. Something is overriding any changes to the Airplane mode.
Here's what rfkill does for me: $rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: yes 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes $ su - #rfkill unblock all <-- no error message, or any other message appears; just prompt. #rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: yes 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes
(In reply to comment #4) > > "rfkill unblock all" successfully re-activate my wireless card ! > > [root@localhost liveuser]# rfkill list > 0: hp-wifi: Wireless LAN > Soft blocked: yes > Hard blocked: no > 1: phy0: Wireless LAN > Soft blocked: yes > Hard blocked: yes Do you want to say that 'rfkill unblock all' enables even 'Hard blocked' WiFi? It should not, because it indicates that WiFi is switched off via hardware switch. (In reply to comment #11) > 1: phy0: Wireless LAN > Soft blocked: no > Hard blocked: yes Ben, did you enable WiFi via a hardware switch? Could anyone seeing the issue attach /var/log/messages? Are there any errors regarding killswitch handling?
The hp-wmi soft block will, if unblocked, remove the phy0 hard block. That's expected behaviour.
(In reply to comment #12) > (In reply to comment #11) > > 1: phy0: Wireless LAN > > Soft blocked: no > > Hard blocked: yes > Ben, did you enable WiFi via a hardware switch? Yes, several times - and nothing happen(s/ed). > Could anyone seeing the issue attach /var/log/messages? Are there any errors > regarding killswitch handling? I would, had I kept them. However, I need my machine for work, and it works fine WITHOUT updating! I reinstalled, and am not planning to run any updates till F16 comes along. I hope you understand. If I get the same issue with F16, I will give you all you ask for.
Hi, i made some extra tests : A. After boot, radio hardware switch off [root@localhost liveuser]# rfkill list 1: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: yes 2: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: yes 3: phy0: Wireless LAN Soft blocked: no Hard blocked: yes B. After boot, radio hardware switch on [root@localhost liveuser]# rfkill list 1: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: no 2: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no C. After activating airplane mode [root@localhost liveuser]# rfkill list 1: hp-wifi: Wireless LAN Soft blocked: yes Hard blocked: no 2: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: yes Hard blocked: yes 4: hci0: Bluetooth Soft blocked: no Hard blocked: no D. Trying to deactivate airplane mode doesn't change the output (same output as when airplane mode is activated) E. [root@localhost liveuser]# rfkill unblock all [root@localhost liveuser]# rfkill list 1: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: no 2: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: no 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no 4: hci0: Bluetooth Soft blocked: no Hard blocked: no No specific error in /var/log/message : --> At step C. : Sep 14 23:09:51 localhost NetworkManager[841]: <info> WiFi hardware radio set disabled Sep 14 23:09:51 localhost NetworkManager[841]: <info> WiFi now disabled by radio killswitch --> No further output during step D. --> rfkill unblock all Sep 14 23:10:22 localhost NetworkManager[841]: <info> WiFi now enabled by radio killswitch Sep 14 23:10:22 localhost NetworkManager[841]: <info> (eth1): bringing up device.
having the same issue here. solved following this http://karim-ouda.blogspot.com/2011/11/wifi-now-disabled-by-radio-killswitch.html hope this helps.
Thanks, Leonardo, it didn't help me. In my bios, my Wifi is enabled. I'm commenting here, but I'm suffering from this bug too in Fedora 16 - if I need to file a new bug-report, please let me know. I will. Symptom: New install works fine, until in the standard installed network gui the wifi-switch is turned off. Airplane mode comes on, and refuses to go off. I am ready to do a lot of research on this machine, but need step by step guidance; I don't have the skill. Come January 4th I will have to go for a re-install as I need this machine for work. Till then, feel free to ask. Test results so far: $ rfkill list 0: dell-wifi: Wireless LAN Soft blocked: yes Hard blocked: yes 1: phy0: Wireless LAN Soft blocked: no Hard blocked: yes # rfkill unblock all No comment; but rfkill list gives the same output. $ lsmod | grep wifi rtlwifi 78539 1 rtl8192ce mac80211 215764 3 rtl8192ce,rtl8192c_common,rtlwifi cfg80211 129063 2 rtlwifi,mac80211 Note: lshw lists this Wireless interface; in the guo it gives these details (pay special attention to the last line of this): Wireless interface /0/100/1c.1/0 product: RTL8188CE 802.11b/g/n WiFi Adapter [10EC:8176] vendor: Realtek Semiconductor Co., Ltd. [10EC] bus info: pci@0000:07:00.0 logical name: wlan0 version: 01 serial: 70:f1:a1:f3:5b:c4 width: 64 bits clock: 33MHz capabilities: Power Management, Message Signalled Interrupts, PCI Express, bus mastering, PCI capabilities listing, ethernet, Physical interface, Wireless-LAN configuration: broadcast: yes driver: rtl8192ce driverversion: 3.1.4-1.fc16.i686 firmware: N/A latency: 0 link: no multicast: yes wireless: IEEE 802.11bgn resources: irq: 17 ioport: 3000(size=256) memory: f0100000-f0103fff this device has been disabled As for a "hardware killswitch", the only thing pre-programmed in my netbook is the F2 key; I can hit that till I'm blue in the face, it changes nothing. I don't know how to attach something, and gedit won't open /var/log/messages for me... What will?
NetworkManager-1:0.9.4.0-9.git20120521.fc17.x86_64 seems to enable/disable airplane mode ok for me. though i noticed once recently (maybe different networkmanager version) that wasnt able to disable airplane mode. however for me think was related to another wifi issue: https://bugzilla.redhat.com/show_bug.cgi?id=638943 do you see anytthing like: 'ath5k phy0: gain calibration timeout (2472MHz)' frequency sweeps in /var/log/messages ?
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping