User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100723 SUSE/3.6.8-1.3 Firefox/3.6.8 Sometimes, when I switch on my laptop (Aspire 4520) the wireless activity indicator would blink (showing that the wireless adapter is on and that there is some sort of activity going on). At this point, running: iwlist wlan0 scan returns no scan results, the problem is that the networks are there. If I then press the wireless button, and run the same command again it will return the actual list of available networks (at this point the blinking indicator, while still blinking, looks somewhat as if the light was stronger. Does this make any sense?). Some other times, pressing the button does not make a difference and I'm forced to run the command: rfkill unblock all As it would show that soft block was on. ----------------------------- Linux zeus.olympus 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux ----------------------------- The same error happens on both x86 and x86_64. I'll post more details if I can get some. Please let me know if you need more details about any particular package version. Thanks Reproducible: Sometimes For more details see the following link as I filed the bug under OpenSUSE https://bugzilla.novell.com/show_bug.cgi?id=637717
Some laptops have both a dedicated switch for rfkill and a key combination. Perhaps you sometimes accidentally hit the key combination, causing the soft block? As for the other part, it sounds like the key (i.e. the hard block) is working as expected, but perhaps the LED isn't being handled as desired?
John, I don't think I've touched anything by accident, I noticed the problem after I upgraded to OpenSUSE 11.3. As I started up the laptop and I ran iwlist wlan0 scan it reported no scan results while the led indicator would still blink. While it could be a problem with the LED not working as desired, why would then iwlist report no scan results when it should be indicating that the device is down? If you can advice on how to further troubleshoot the issue I'll be delighted to do that. Thank you
Been a while...is this still an issue with kernel 2.6.37 or later?
John, I don't recall seeing it again but I haven't tried much to be honest. Why don't you close this one as resolved and if I find it again I'll open a new one against the new kernel?
I believe I can reproduce something similar with kernel 4.1.15. The ath5k wireless connection is managed through wpa_supplicant, and when I stop the wireless service, the card gets "soft blocked" (as shown by rfkill) and additional action is required before starting wireless again. Looking at the code for ath5k rkfill (drivers/net/wireless/ath/ath5k/rfkill.c), I can see, in ath5k_rfkill_hw_stop(): /* enable RFKILL when stopping HW so Wifi LED is turned off */ ath5k_rfkill_enable(ah); According to the git log, it seems that this code has been around since the first incarnation of the file, dating from 2009, and perhaps that would also explain the original bug reported here.