Red Hat Bugzilla – Bug 540038
NetworkManager mis-detects RF kill switch (doesn't allow wireless connections)
Last modified: 2013-01-10 02:18:01 EST
+++ This bug was initially created as a clone of Bug #510662 +++
Description of problem:
NetworkManager doesn't allow wireless connections even though the hardware is detected by the Linux kernel. The hardware in question is "Intel Corporation Wireless WiFi Link 5100", inside a "Dell Vostro 1320" laptop. Wireless is enabled via a switch (i.e. no RF kill).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enable wireless via switch (i.e. no RF kill)
2. Boot Fedora 10
3. Login to Gnome desktop
4. Click (left mouse) on the NetworkManager icon in the top panel
Says that "wireless is disabled"
Allow wireless connections
Fresh Fedora 10 install (default options), with updates as of 10 July 2009.
Linux kernel 188.8.131.52-170.2.72.fc10.i686 #1 SMP
See also the attached output of dmesg, lspci and ifconfig.
Interesting section in dmesg, even though the RF kill switch is off (ie. wireless enabled):
iwlagn: Radio Frequency Kill Switch is On:
Kill switch must be turned off for wireless networking to work.
--- Additional comment from email@example.com on 2009-07-10 01:39:56 EDT ---
Created an attachment (id=351215)
output of dmesg, lspci and ifconfig
--- Additional comment from firstname.lastname@example.org on 2009-07-10 02:21:04 EDT ---
/var/log/messages also shows up a few interesting tidbits:
Found radio killswitch /org/freedesktop/Hal/devices/pci_8086_4232_rfkill_5100AGN_wlan
(wlan0): driver supports SSID scans (scan_capa 0x01).
(wlan0): new 802.11 WiFi device (driver: 'iwlagn')
(wlan0): exported as /org/freedesktop/Hal/devices/net_00_22_fb_54_7c_fe
<WARN> killswitch_getpower_reply(): Error getting killswitch power: Method "GetPower" with signature "" on interface "org.freedesktop.Hal.Device.KillSwitch" doesn't exist#012.
<info> Wireless now disabled by radio killswitch
--- Additional comment from email@example.com on 2009-07-10 02:24:46 EDT ---
Created an attachment (id=351219)
messages from NetworkManager in /var/log/messages
created using: grep -i NetworkManager /var/log/messages
--- Additional comment from firstname.lastname@example.org on 2009-09-16 04:27:50 EDT ---
What's the output of "rfkill list" on your machine?
Bug report on the kernel butracker:
--- Additional comment from email@example.com on 2009-09-16 04:44:11 EDT ---
The machine is my mum's laptop, on which I have since installed an old-ish Ubuntu (8.04). I have only intermittent access to the laptop.
If "rfkill list" from Ubuntu 8.04 would help solve the problem, I'll report the output. Otherwise the laptop isn't likely to have another OS (e.g. Fedora) installed on it in the near future.
I'd venture the problem with the wireless connection lies in the bug shown in Comment #2
--- Additional comment from firstname.lastname@example.org on 2009-10-16 16:54:38 EDT ---
Ok, I'd need the laptop with fedora to debug further, but I believe this issue is either fixed upstream or in F11, or is a HAL problem deeper down with rfkill. Thanks!
--- Additional comment from email@example.com on 2009-10-16 17:00:19 EDT ---
You might want to have a look at the changes in Ubuntu to fix this bug:
I would like to provide more info on this bug since it still exists in F12. Please tell me what info you need.
I would like to provide more info on this bug since it still exists in F12.
Please tell me what info you need.
I am experiencing this bug on my Dell D830 running F12 64 bit.
What's the output of:
and also of:
# cat /sys/class/rfkill/*/state
# cat /sys/class/rfkill/*/type
Ok, can you also attach /var/log/messages to this bug report? I'd like to see what killswitches NetworkManager finds and what state it detects them in. It looks like the kernel thinks your killswitch is set to allow wireless, so we need to figure out why NM doesn't think so.
Created attachment 385575 [details]
FWIW, blacklisting dell-laptop seems to fix the issue.
Is that /var/log/messages *after* you blacklisted dell-laptop? THe line here:
Jan 19 21:31:47 tag3001-fedora NetworkManager: <info> Wireless now enabled by radio killswitch
says that NM thinks your killswitch is set to allow wifi, which would contradict the original issue in this bug...
Comment on attachment 385575 [details]
this log is with the blacklisted dell-laptop module
Created attachment 386002 [details]
this log is without the blacklisted dell-laptop module
Jan 21 06:12:38 tag3001-fedora NetworkManager: <info> Found radio killswitch rfkill0 (at /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/ieee80211/phy0/rfkill0) (driver <unknown>)
Jan 21 06:12:38 tag3001-fedora NetworkManager: <info> Found radio killswitch rfkill1 (at /sys/devices/virtual/rfkill/rfkill1) (driver <unknown>)
Jan 21 06:12:38 tag3001-fedora NetworkManager: <info> Wireless disabled by radio killswitch; enabled by state file
Over to kernel for why dell-laptop misdetects your machine and thinks it's rfkilled.
Could you please install the smbios-utils package and attach the output of the
comand, run as root?
# dellWirelessCtl --info (I assume this is what you meant)
Libsmbios version : 2.2.16
smbios-wireless-ctl version : 2.2.16
Hardware switch supported
Hardware switch is Off
WiFi Locator supported
Wireless Keyboard not supported
NVRAM Size: 256 bytes
NVRAM format version: 1
Radio Status for WLAN:
WLAN enabled at boot
WLAN not controlled by wireless switch at boot
WLAN runtime switch control currently disabled
Status Code: 0
Radio Status for Bluetooth:
Bluetooth enabled at boot
Bluetooth controlled by wireless switch at boot
Bluetooth runtime switch control currently enabled
Status Code: 1
Radio Status for WWAN:
WWAN disabled at boot
WWAN not installed
WWAN not controlled by wireless switch at boot
WWAN runtime switch control currently disabled
Status Code: 2
Wireless Switch Configuration
WLAN switch control: off
Bluetooth switch control: on
WWAN switch control: off
switch config: not locked
WiFi locator: disabled
WiFi Locator config: not locked
Ok, I see the issue and have a patch for it. I'll test now.
This also applies in F13.
(In reply to comment #14)
> This also applies in F13.
I managed to get the original laptop for a little while (see comment #1).
This bug doesn't seem to occur in RHEL 6 beta 1. Did RHEL get the fix while Fedora didn't ?
(In reply to comment #15)
> I managed to get the original laptop for a little while (see comment #1).
Apologies, the description of the laptop is in the first post (Description), rather than the first comment.
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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:
This seems to work fine in F14 32bit.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.