Distribution: - Ubuntu Intrepid Hardware Environment: - Asus N20A, using the iwlagn driver on an Intel 5100 Software Environment: - Ubuntu Intrepid. I've tried this with their stock 2.6.28 kernel, as well as build of my own of 2.6.28rc8. - hal 0.5.12 - NetworkManager 0.7 Problem Description: I filed this bug against HAL first, but it was resolved as NOTOURBUG there, so I'm trying to file it here instead. 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, disabling the wifi. Turning the switch back on, won't change this: the rfkill state will be stuck at 2, no matter what. Only thing to do to get wifi back is to modprobe -r iwlagn && modprobe -r rfkill && modprobe iwlagn. The reason I first filed this against hal is that NetworkManager talks to hal, hal does the heavy lifting. Second, the problem wasn't there with hal 0.5.11 which, as far as I know, doesn't have a way to interfere directly with the rfkill interface. This feature is added in 0.5.12. Steps to reproduce: With hal 0.5.12, and NetworkManager running, first turn the hardware switch to off. Then turn it back on. Observe that /sys/class/net/wlan1/device/rfkill/rfkill0/state is stuck at 2. --- http://dl.getdropbox.com/u/175461/lspci-nnvv.output http://dl.getdropbox.com/u/175461/dmidecode.output --- link to bug report against hal: https://bugs.freedesktop.org/show_bug.cgi?id=19040
Does ifconfig show the wlan0 device as "up"?
After switching off, and then back on, and confirming that /sys/class/net/wlan1/device/rfkill/rfkill0/state reads 2, ifconfig wlan1 gives: wlan1 IEEE 802.11abgn ESSID:"B2_private_BF" Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated Tx-Power=15 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Hi I get the same problem with an ASUS M51VR laptop. But this time with wicd which may confirm that the problem is not related to networkmanager itself. Distribution: - Debian lenny / SID Hardware Environment: - Asus M51VR, using the iwlagn driver on an Intel 5100 Software Environment: - Debian - kernel : tested with 2.6.27.9 and 2.6.27.10 - hal 0.5.11.6 - wicd 1.5.6 Steps to reproduce: With hal 0.5.11.6, and wicd running, first turn the hardware switch to off. Then turn it back on. Observe that /sys/class/net/wlan0/device/rfkill:rfkill0/state is stuck at 2. I will try the modprobe trick till this issue is solved. Please let me know if you need any additional information. Regards, Jonathan Dray
Hello, I found the cause of the rfkill switch issue in my case. The acpi driver loaded at boot time was not the right one. The deprecated asus_acpi module that was loaded did not handle the wifi activation switch properly. I had to blacklist it for the asus_laptop driver to be loaded instead. (added the line "blacklist asus_acpi" in /etc/modprobe.d/blacklist) After I rebooted the laptop the wifi card was up and running. Now I have an issue with the iwlagn driver and wpa but that's another story. I hope this information will help you in your invistigation. good luck. Regards, Jonathan Dray
(In reply to comment #4) Thank you for your comment. Just in case it's not clear, I've been using the asus-laptop module from the start, and still having this issue.
It seems like this could still be a problem with the asus-laptop driver?
(In reply to comment #6) > It seems like this could still be a problem with the asus-laptop driver? > With "still", do you mean 2.6.29-rc1? I haven't had a chance to try that kernel yet, but I haven't seen anything in the commit logs that looks related to this particular problem.
By "still" I mean "Despite the fact that you've been using the asus-laptop module from the start, the fact that Jonathan fixed a similar problem by switching from asus_acpi to asus-laptop still suggests that the problem Khashayar is experiencing could be related to asus-laptop rather than being a generic problem in the iwlagn driver."
I don't think the asus-laptop module (which is what I've been using all along), touches the rfkill interface. The only thing related to wlan under /sys/devices/platform/asus-laptop/ is the file 'wlan'. And the only thing that file controls is the wlan LED on the laptop. The old asus_acpi module probably tried to control the rfkill state, though. I could test things without the asus-laptop module loaded to remove all doubts, if that's desirable.
please do
If you're feeling adventurous, you could try my new rfkill code -- apply patches with rfkill in their name from http://johannes.sipsolutions.net/patches/kernel/all/LATEST/
No response from reporter. Is this bug still open?
I'm sorry for the lack of response. Non-computer related things have been taking up all of my time as of late. I haven't been able to follow up. All I can say at this point is that the problem isn't around on my Ubuntu 9.04 install. I don't know what kind of workaround the Ubuntu folks have applied, but I haven't noticed this particular issue. So perhaps we could close this bug, and I'll re-open in case I realize I'm wrong?