Re: rfkill: how murderous can it be ?

[Michael Buesch <mb@bu3sch.de>]

On Monday 12 January 2009 20:34:44 Dan Williams wrote:
> On Mon, 2009-01-12 at 17:15 -0200, Werner Almesberger wrote:
> > I'd like to restart a discussion from last year, namely how aggressive
> > an rfkill implementation is allowed to be when it comes to destroying
> > MAC state.
> > 
> > The design suggested in rfkill.txt and also implemented in the existing
> > drivers basically assumes a simple on/off switch that cuts power to the
> > transmitter but doesn't change anything else. The question is if this 
> > is already the full extent to which rfkill is allowed to affect MAC
> > state or if it could go further.
> > 
> > In the AR6k, we don't have such a simple switch for the transmitter. We
> > can control what the transmitter does very indirectly by temporarily
> > reconfiguring the MAC, but this creates a fair amount of complexity,
> > which also seems to be at odds with the design of rfkill.
> > 
> > Alternatively, we could just power down the whole WLAN module. That is
> > easily done and very reliable. However, MAC state (ESSID, keys, and a
> > host of other settings) is obliterated if we do this. A watchful user 
> > space (e.g., wpa_supplicant) could then restore the status quo ante.
> > 
> > Now the question is whether this is still in the spirit of the design 
> > of rfkill of if it would take things too far.
> > 
> > It seems that there is no consensus on this issue yet. I started the 
> > implementation with the assumption that rfkill should always behave as 
> > if it only cut transmitter power, so no other state of the MAC is
> > allowed to be lost. This is also what Henrique suggested I should do.
> > 
> > However, Andy and recently Michael suggested that, given that an
> > interface that has no connectivity for an extended period of time is
> > likely to get reconfigured anyway, it may be sufficient if rfkill 
> > leaves things in a state that allows user space to restore 
> > connectivity, without having to worry about details beyond that.
> 
> Yes.  You have no guarantees about how long the RF is down when the
> switch is flipped or the checkbox ticked.  Instead of putting a bunch of
> complexity in the kernel and drivers that *already* has to be in
> userspace, just punt it out to userspace where it's already done and
> works well.
> 
> If there are any latency issues with this, then we need to fix those
> latency issues in wpa_supplicant, not put complex state handling into

Just a simple nl80211 notification message, probably.
This could be shared with resume-notification.

> the stack drivers for this.  Treat rfkill the same as suspend/resume
> from a state perspective, because they really have the same
> consequences: you have no idea where you are when you wake up, what has
> happened since RF was turned off, and whether your AP is still around.
> Better to make scanning and associate fast and foolproof, which has to
> happen in userspace anyway.

I fully agree with this.

(Note that currently with mac80211 drivers, we leave the MAC state dangling.
That's really the same type of "bug" like the mac80211 suspend issue.
A fix would require integration of rfkill into mac80211)

-- 
Greetings, Michael.