iwlwifi 3945 works only with disable_hw_scan=1

I recently bought an acer aspire 5720G, and wireless didn't work with standard ubuntu 2.6.24 kernel.

I found that specifying the above option 'fixes' the driver but I also noticed that list of available access points shrinks to just one (the connected) point.

Moreover there is a trouble in changing a access point, it just hangs. the button that toggles wireless does work, but doesn't blink.

I then installed latest -git kernel (~ 2.6.26-rc4) and got this:

* I still have to use disable_hw_scan=1
* Wireless led works thanks to acer-wmi
* If I disable wireless with the button, I _can't_ re-enable it unless I reload the module.

* List of access points doesn't shrink, and I can switch between those points.

When I omit disable_hw_scan=1, I get errors about REPLY_SCAN_CMD I will send detailed debug info later.

Best regards,
Maxim Levitsky

I found why I can't reenable wireless with wireless button.

It turns out that iwlwifi doesn't enable the wireless function after a R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e in linus tree.

Quoted 3 lines · Maxim Levitsky

I found why I can't reenable wireless with wireless button.

Quoted 5 lines

It turns out that iwlwifi doesn't enable the wireless function after a R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e in linus tree.

The card will receive an interrupt when you disable the rf kill switch anyway [...]

Quoted 1 line

The card will receive an interrupt when you disable the rf kill

switch

Quoted 1 line

anyway [...]

It does? I thought thats only true for 4965 ... 3945 uses an ucode event for that thats why it does not detect the rfkill state when the interface is down.

Quoted 7 lines · Maxim Levitsky

I found why I can't reenable wireless with wireless button.

It turns out that iwlwifi doesn't enable the wireless function after a R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e in linus tree.

The card will receive an interrupt when you disable the rf kill switch anyway whatever the wireless function is enabled or not. So the driver will enable the wireless function again. Please check if the interface (wlan0) is up when you disable the rf kill switch later. If it is not, you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the wireless function. Otherwise please provide the dmesg with debug=0x20000.

Thanks,
-yi

Quoted 17 lines · Zhu Yi

Quoted 7 lines · Maxim Levitsky

I found why I can't reenable wireless with wireless button.

It turns out that iwlwifi doesn't enable the wireless function after a R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e in linus tree.

The card will receive an interrupt when you disable the rf kill switch anyway whatever the wireless function is enabled or not. So the driver will enable the wireless function again. Please check if the interface (wlan0) is up when you disable the rf kill switch later. If it is not, you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the wireless function. Otherwise please provide the dmesg with debug=0x20000.

Quoted 3 lines

Thanks,
-yi

Why didn't I thought about this before... This is exactly what happens, so this isn't a bug.

What happens is the Network manager brings wlan0 down is it detects that there is no link, but this now removes the firmware.

I guess that the right solution is to listen to the wireless button (via input layer), and turn card on manually.

If I remember correctly there is something like that in kernel, I try to enable this.

Otherwise this can be implemented in userspace.

Best regards,
Maxim Levitsky

Quoted 17 lines · Zhu Yi

Quoted 7 lines · Maxim Levitsky

I found why I can't reenable wireless with wireless button.

It turns out that iwlwifi doesn't enable the wireless function after a R/F kill switch was enabled ether by the button or explicitly.

I bisected this to commit 5a66926aa9230810704fd5a127966215fd58881e in linus tree.

The card will receive an interrupt when you disable the rf kill switch anyway whatever the wireless function is enabled or not. So the driver will enable the wireless function again. Please check if the interface (wlan0) is up when you disable the rf kill switch later. If it is not, you have to bring it up manually (i.e. ifconfig wlan0 up) to enable the wireless function. Otherwise please provide the dmesg with debug=0x20000.

Quoted 3 lines

Thanks,
-yi

Why didn't I thought about this before... This is exactly what happens, so this isn't a bug.

What happens is the Network manager brings wlan0 down is it detects that there is no link, but this now removes the firmware.

I guess that the right solution is to listen to the wireless button (via input layer), and turn card on manually.

If I remember correctly there is something like that in kernel, I try to enable this.

Otherwise this can be implemented in userspace.

Nope 3945 doesn't support rfkill via new rfkill subsystem.

Quoted 1 line

I guess that the right solution is to listen to the wireless button

(via

Quoted 3 lines

input layer), and turn card on manually.

If I remember correctly there is something like that in kernel, I

try to

Quoted 3 lines

enable this.

Otherwise this can be implemented in userspace.

The right solution is for NM to not take the device down (essentially doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off. However,
that's not possible right now, because HAL doesn't provide enough information about the killswitches to distinguish between a software rfkill (which means we can turn the power back on) and a hardware rfkill
(which means the user has to flip something). On ipw2100, 2200, and 2915, setting the TX power off looks exactly like a hardware kill to HAL, so if you chose unchecked "Enable Wireless" in the nm applet, you'd never be able to turn wireless back on, because HAL and NM think there's a hardware kill active.

Quoted 10 lines · Dan Williams

Quoted 1 line

I guess that the right solution is to listen to the wireless button

(via

Quoted 3 lines

input layer), and turn card on manually.

If I remember correctly there is something like that in kernel, I

try to

Quoted 3 lines

enable this.

Otherwise this can be implemented in userspace.

Quoted 12 lines

The right solution is for NM to not take the device down (essentially doing SIOCSIFFLAGS with !IFF_UP), but to set the TX power off. However,
that's not possible right now, because HAL doesn't provide enough information about the killswitches to distinguish between a software rfkill (which means we can turn the power back on) and a hardware rfkill
(which means the user has to flip something). On ipw2100, 2200, and 2915, setting the TX power off looks exactly like a hardware kill to HAL, so if you chose unchecked "Enable Wireless" in the nm applet, you'd never be able to turn wireless back on, because HAL and NM think there's a hardware kill active.

I think who takes the interface down is responsible to bring it up. Even if the driver receives a rf_kill switch disabled interrupt, it should keep the current IFF_UP status. It should never bring it up or down itself. (Think about the carrier on/off in ethernet).

I wonder why NM need to ifdown or "txpower off" when rf_kill switch (both for SW and HW) is enabled. The driver already handles it. Could it save more power?

SW rfkill doesn't necessarily kill the device. Input-only switches (like Fn+F5 on thinkpads for exampel) aren't handled by the kernel rfkill system and thus something in userspace needs to handle them instead. It's probably worth checking the radio state when the event comes in and only if the radio isn't already disabled, then set tx power off.