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.
rfkill.txt only specifies the minimum actions an RF kill is required
to perform, but it's silent on how far it is allowed to go. Let's fix
this :-)
Thanks,
- Werner
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.
On Mon, Jan 12, 2009 at 11:15 AM, Werner Almesberger
<[email protected]> 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.
>
> rfkill.txt only specifies the minimum actions an RF kill is required
> to perform, but it's silent on how far it is allowed to go. Let's fix
> this :-)
>
> Thanks,
> - Werner
> --
As an interested User/lurker, it seems that allowing rfkill to power
down as much of the device as possible in the "killed" state would be
desirable. This would help extend battery life when wifi is not
needed. It seems reasonable to assume that the interface would need
reconfiguring once the rfkill switch is turned back on.
Just my $0.02 of course
--
Henry von Tresckow (hvontres)
Steve Martin - "I like a woman with a head on her shoulders. I hate necks."
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
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.
Dan
On Tue, 13 Jan 2009, Johannes Berg wrote:
> On Tue, 2009-01-13 at 11:21 -0200, Henrique de Moraes Holschuh wrote:
> > But I DO heavily suggest that we inform userspace differently when state was
> > lost (i.e. when it absolutely HAS to reconfigure the device or there are no
> > chances of data passing through).
> >
> > Right now, it HAS that information in a roundabout way: if the device
> > disappears (hotunplug), state was lost (duh! :-p) If it stays around, no
> > state was lost...
> >
> > And, as an user, I'd be rather annoyed if suddenly I couldn't easily and
> > cheaply just hit the rfkill hotkey (softswitch) to kill and unkill my WLAN
> > while browsing, and stopping a few minutes to read the screen... because
> > every time I unkilled, the system would churn, deassociate and reassociate
> > and be otherwise annoying doing a reconfiguration it didn't absolutely have
> > to do.
> >
> > In other words: make it possible to be configurable! From the kernel POV
> > that just means we need to have to publish to userspace the fact that it has
> > to reconfigure when there is not a full hotunplug/hotplug being done.
>
> Way overkill. Anything more than a few seconds of rfkill will require
> the "churn" anyway.
Then don't corrupt the interface running state in the first place.
If you are going to detach the device, fine. If you are going to NOT detach
the device but it also won't lose any state, fine. These two situations
happen to describe the behaviour of *ALL* the current rfkill-enabled
drivers, AFAIK.
And since the driver that spawned this thread will detach the device instead
of doing something "new" (partially lose state), that hasn't changed yet...
But IMO, corrupting running state on rfkill is a rotten thing to do to the
user. And telling userspace authors to EXPECT that every rfkill could have
that effect no matter the hardware, is not nice either.
Why the should I, as an user, have to tolerate userspace needing to reset
the entire interface for no good reason at all if my hardware and its
drivers do NOT require it?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> If you kick it out of the bus (cause a full hotunplug on rfkill block,
> and a hotplug when rfkill unblocks), it is userspace.
>
> But what if you do it halfway? That's what is being asked here...
If kicking it out of the bus is okay, then that's just what I'll
do. This gives us clear and familiar semantics and avoids complex
and fragile state preservation in the kernel.
My concern about this was whether this wouldn't take things too
far. E.g., if I can safely assume that user space will be there
to take care of it.
>From what I gather, it does indeed seem to be acceptable, even if
it may not be ideal under all circumstances.
Thanks,
- Werner
Dan Williams wrote:
> 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.
That's the way I like things :-) Can the information user space may
have to recover include DHCP leases and routes ? I.e., can an rfkill
implementation choose to just restart the network interface ?
Next: what happens while the device is rfkill'ed ? E.g., is it okay to
just remove the interface, so any attempt to configure the interface
while it's rfkill'ed would yield an ENODEV ?
Basically, could rfkill block/unblock semantics just be equivalent to
removal and reloading of the module containing the respective WLAN
device driver ? (Ignoring any response time issues for now.)
- Werner
On Tue, 13 Jan 2009, Matthew Garrett wrote:
> On Mon, Jan 12, 2009 at 05:15:14PM -0200, Werner Almesberger wrote:
> > 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.
>
> Some platform rfkill methods will perform a logical PCI hotplug of the
> device, without any means of notifying the driver beforehand. Since this
> will destroy the driver structure, I think we really need to leave state
> restoration up to userspace.
Sounds acceptable, certaily...
But I DO heavily suggest that we inform userspace differently when state was
lost (i.e. when it absolutely HAS to reconfigure the device or there are no
chances of data passing through).
Right now, it HAS that information in a roundabout way: if the device
disappears (hotunplug), state was lost (duh! :-p) If it stays around, no
state was lost...
And, as an user, I'd be rather annoyed if suddenly I couldn't easily and
cheaply just hit the rfkill hotkey (softswitch) to kill and unkill my WLAN
while browsing, and stopping a few minutes to read the screen... because
every time I unkilled, the system would churn, deassociate and reassociate
and be otherwise annoying doing a reconfiguration it didn't absolutely have
to do.
In other words: make it possible to be configurable! From the kernel POV
that just means we need to have to publish to userspace the fact that it has
to reconfigure when there is not a full hotunplug/hotplug being done.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Monday 12 January 2009 22:13:13 Werner Almesberger wrote:
> Dan Williams wrote:
> > 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.
>
> That's the way I like things :-) Can the information user space may
> have to recover include DHCP leases and routes ? I.e., can an rfkill
> implementation choose to just restart the network interface ?
>
> Next: what happens while the device is rfkill'ed ? E.g., is it okay to
> just remove the interface, so any attempt to configure the interface
> while it's rfkill'ed would yield an ENODEV ?
>
> Basically, could rfkill block/unblock semantics just be equivalent to
> removal and reloading of the module containing the respective WLAN
> device driver ? (Ignoring any response time issues for now.)
No. If you are in an rfkill situation, you're not required to kill the receiver.
(However, currently most (all?) devices kill both TX and RX).
So I think completely killing the interface is the wrong way to go.
And I don't think we should care about stuff above the MAC layer, too.
If the user hits rfkill, he should _expect_ all upper layer connections
to break (DHCP, TCP or whatever). That's a basic assumption about rfkill.
The default timeouts will handle that just fine.
In any way, this is nothing the kernel has to care about. It's userspace business, if any.
--
Greetings, Michael.
On Mon, Jan 12, 2009 at 05:15:14PM -0200, Werner Almesberger wrote:
> 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.
Some platform rfkill methods will perform a logical PCI hotplug of the
device, without any means of notifying the driver beforehand. Since this
will destroy the driver structure, I think we really need to leave state
restoration up to userspace.
--
Matthew Garrett | [email protected]
On Tue, 13 Jan 2009, Werner Almesberger wrote:
> Henrique de Moraes Holschuh wrote:
> > If you kick it out of the bus (cause a full hotunplug on rfkill block,
> > and a hotplug when rfkill unblocks), it is userspace.
> >
> > But what if you do it halfway? That's what is being asked here...
>
> If kicking it out of the bus is okay, then that's just what I'll
> do. This gives us clear and familiar semantics and avoids complex
> and fragile state preservation in the kernel.
Yes, it is okay. It has to be, many devices absolutely require it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Mon, 12 Jan 2009, Hans Henry von Tresckow wrote:
> As an interested User/lurker, it seems that allowing rfkill to power
> down as much of the device as possible in the "killed" state would be
> desirable. This would help extend battery life when wifi is not
> needed. It seems reasonable to assume that the interface would need
> reconfiguring once the rfkill switch is turned back on.
Agreed, but the real question is not that.
It is "who is responsible for restoring the interface state, and to
what extent"?
If you kick it out of the bus (cause a full hotunplug on rfkill block,
and a hotplug when rfkill unblocks), it is userspace.
But what if you do it halfway? That's what is being asked here...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Tue, 2009-01-13 at 11:21 -0200, Henrique de Moraes Holschuh wrote:
> But I DO heavily suggest that we inform userspace differently when state was
> lost (i.e. when it absolutely HAS to reconfigure the device or there are no
> chances of data passing through).
>
> Right now, it HAS that information in a roundabout way: if the device
> disappears (hotunplug), state was lost (duh! :-p) If it stays around, no
> state was lost...
>
> And, as an user, I'd be rather annoyed if suddenly I couldn't easily and
> cheaply just hit the rfkill hotkey (softswitch) to kill and unkill my WLAN
> while browsing, and stopping a few minutes to read the screen... because
> every time I unkilled, the system would churn, deassociate and reassociate
> and be otherwise annoying doing a reconfiguration it didn't absolutely have
> to do.
>
> In other words: make it possible to be configurable! From the kernel POV
> that just means we need to have to publish to userspace the fact that it has
> to reconfigure when there is not a full hotunplug/hotplug being done.
Way overkill. Anything more than a few seconds of rfkill will require
the "churn" anyway.
johannes