Re: NetworkManager and rf_kill

[Dan Williams <dcbw redhat com>]

On Mon, 2008-05-12 at 18:20 -0400, Tony Espy wrote:
> Dan Williams wrote:
> > On Mon, 2008-05-12 at 17:46 +0200, Khashayar Naderehvandi wrote:
> >> I really might be misunderstanding something here, but deactivating
> >> wireless through nm-applet should in fact (as things are currently
> >> with NM from svn), do a ifconfig wlan0 down? Is this correct? Because
> >> doing that manually, my wifi doesn't suck battery power anymore.
> >> However, nm-applet seems to take down the wireless device _only_ when
> >> I deactivate network completely, that is, when I deactivate wireless,
> >> wired and GSM capabilities. Only deactivating wireless leaves the
> >> device up, and hence reduces uptime on battery.
> > 
> > We do need to mark the device down when it's disabled; that somehow went
> > away when rewriting the device state handling.  Should be a pretty easy
> > fix in nm-device-802-11-wireless.c::nm_device_802_11_wireless_set_enabled().
> > 
> > I was going to change that code to set the TX power of the card off
> > instead of taking it down, because some hardware (iwl3945) needs
> > firmware loaded to notice rfkill changes, and setting the device down
> > unloads the firmware.  So at least on some devices you need to always
> > keep the card up.  But HAL isn't smart enough yet to distinguish between
> > soft rfkill and hard rfkill, so setting TX power off, to HAL, looks just
> > like a hard rfkill and you can't turn the rf back on in software :(
> > That's a fairly easy patch to HAL though.
> 
> I've been following this thread with interest because I've recently 
> implemented this feature on top of network-manager-0.6.6~rc2 ( the 
> version in Ubuntu 8.04 ) as part of some custom Ubuntu Mobile work.
> 
> I added logic to invoke the Hal KillSwitch::SetPower method from within 
> the wireless_set_enabled() function.  I also added a sw_rf_enabled flag 
> to handle allowing the user to re-enable wireless ( otherwise as Dan 
> pointed out, the hw_rf_enabled flag would prevent this ).

Ideally that's what NM would be doing; unfortunately many machines still
don't actually use rfkill, and there's no way to map the rfkill button
to a specific hardware device by design.  So NM will still have to touch
the device directly.

> One caveat...it appeared to me as if the NM code in 0.6.6 was 
> interpreting the GetPower return values incorrectly( ie. it looked like 
> interpreted TRUE as killswitch ON, as opposed to power ON ).  I had to 
> reverse the value returned by my KillSwitch::GetPower method, otherwise 
> NM disabled wireless on startup.

NM calls GetPower(), which should return 0 if power is off, and 1 if
power is on.  NM sets it's internal "hw_rf_enabled" state directly from
that value.  So if GetPower() returns 1, NM should be setting it's
"hw_rf_enabled" value to 1.  I'd be curious to see exactly what your
killswitch method is returning for GetPower() in
nm_killswitch_getpower_reply_cb() and then the overall
"tmp_hw_rf_enabled" state in handle_killswitch_pcall_done().

> I additionally implemented a power-saving feature using some of the same 
> logic.  I modified the scanning code so that when the scan_interval gets 
> bumped to  INACTIVE ( ~2min ), I disable the interface at the beginning 
> of the interval and then wake it up right before the next scheduled scan.

That's neat; and something we should definitely do in upstream NM.

> Note - the one caveat is that my Hal KillSwitch method utilizes a 
> private DeepSleep ioctl, so the card isn't totally powered off, but is 
> close enough to show some substantial power-savings.

We probably should call SetPower() as well, but we should really do:

set TX power off
SetPower(0)
...
SetPower(1)
set TX power on

to cover both rfkill-incapable cards and rfkill cards.

> I plan on publishing my work via my launchpad PPA ( personal package 
> archive ), and will drop a note to the list when the code's available ( 
> hopefully tomorrow ).

Patch submissions gratefully accepted :)

Dan