I just now reported this bug against Ubuntu's networkmanager, but I'm starting to think it's actually a hal bug, so I'm reporting it here. The following is a slightly modified report filed in launchpad #307411: This is on an Asus N20A, with the Intel wifi link 5100 chip. This laptop has a hardware switch that's supposed to disable the radio adaptors. Without NetworkManager running, it does this just fine. Switching to off, writes a 0 to /sys/class/net/wlan1/device/rfkill/rfkill0/state and 0 to /sys/devices/platform/asus-laptop/bluetooth. Turning the switch back on, writes 1 to both of those files, and we're back up and rolling again. However, when NetworkManager is running, the switch off will write 2 to /sys/class/net/wlan1/device/rfkill/rfkill0/state, also disabling the wifi. Turning the switch back on, however, won't change this. Only thing to do to get wifi back is to modprobe -r iwlagn && modprobe -r rfkill && modprobe iwlagn. Hal version is 0.5.12rc1 I'll attach the output of hald --verbose=yes --daemon=no. While hal was running I turned the hardware switch to off, and then back on.
Hm... I just realized the output of hald is a 7,6MB file. Should I really attach it?
There is nothing HAL can do about this problem if the sysfs tells the state is '2'. From the kernel documentation of the rfkill subsystem: RFKILL_STATE_HARD_BLOCKED is used by drivers to signal that the device is locked in the BLOCKED state by a hardwire rfkill line (typically an input pin that, when active, forces the transmitter to be disabled) which the driver CANNOT override.
So you mean it's a kernel bug, then? Because it doesn't happen with hal 0.5.11. And it only happens with 0.5.12 if, and only if, Networkmanager is running. And as far as I understand, NM talks to hal. So it seems like NM tells hal to do something that consequently messes the rfkill state up. Do you suggest I file a bug against the kernel instead? Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.