Faking powersave for fun and realtime channel muxing

Faking powersave for fun and realtime channel muxing

[Andy Green]

Hi folks -

If you could generate and manage powersave protocol frames to an AP from 
the mac80211 stack, without actually putting the radio to sleep, you 
could do some interesting things.

For example you could allow any logical network interface to have a 
different channel.  In this case, during the time that the channel you 
are associated on has been told you have gone into powersave mode, you 
can actually spend time on that other channel, before switching the 
channel back to check in with the AP.  So you could for example run 
monitor mode on channel 11 while being associated on channel 2, given 
the limitation that sometimes you aren't listening because you are 
taking care of business on channel 2.  This can surely lead to ripping 
out all the "scanning" stuff and ioctl(s) from kernel mode and doing it 
from a regular interface using the existing Monitor semantics.

Depending on the limitations of the time you can arrange to "sleep" with 
the AP, using this technique you could even associate multiple logical 
interfaces to APs on different channels despite they are sharing one 
physical radio.  That could be cool for dealing with realtime selection 
of the best channel/AP when the guy is mobile, for example.

Is there something like firmware constraints or the detail of the 
powersaving protocol that kill this dead or is it possible to consider?

-Andy

Re: Faking powersave for fun and realtime channel muxing

[Michael Buesch]

On Monday 19 March 2007 20:57, Andy Green wrote:
> Hi folks -
> 
> If you could generate and manage powersave protocol frames to an AP from 
> the mac80211 stack, without actually putting the radio to sleep, you 
> could do some interesting things.
> 
> For example you could allow any logical network interface to have a 
> different channel.  In this case, during the time that the channel you 
> are associated on has been told you have gone into powersave mode, you 
> can actually spend time on that other channel, before switching the 
> channel back to check in with the AP.  So you could for example run 
> monitor mode on channel 11 while being associated on channel 2, given 
> the limitation that sometimes you aren't listening because you are 

And what's it good for to have a monitor device that randomly misses
half of the packets? I mean... rather useless, no?

> Depending on the limitations of the time you can arrange to "sleep" with 
> the AP, using this technique you could even associate multiple logical 
> interfaces to APs on different channels despite they are sharing one 
> physical radio.  That could be cool for dealing with realtime selection 
> of the best channel/AP when the guy is mobile, for example.
> 
> Is there something like firmware constraints or the detail of the 
> powersaving protocol that kill this dead or is it possible to consider?

For software MAC devices this might work. But I think performance would suck.
But it sounds like it's worth an experiment. So if you want to.. :)

-- 
Greetings Michael.

Re: Faking powersave for fun and realtime channel muxing

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On Monday 19 March 2007 15:57, Andy Green wrote:
> Hi folks -
>
> If you could generate and manage powersave protocol frames to an AP from
> the mac80211 stack, without actually putting the radio to sleep, you
> could do some interesting things.
>
Like in my scanning patch series?

http://news.gmane.org/find-root.php?group=gmane.linux.kernel.wireless.general&article=770

This requires a bit of kernel side support to queue up frames on the client 
side to maintain the illusion that nothing happened. (except for a brief 
latency jump) However, it does seem to work for the wireless cards I've 
tested. Doing scanning like this in userspace will require some sort of 
interface to stop/restart the TX for the appropriate network interfaces, but 
will probably make your multichannel association idea possible.

As for how long the AP will hold your frames.. 802.11 defines a minimum time, 
but the maximum depends on the AP.

-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Faking powersave for fun and realtime channel muxing

[Andy Green]

Michael Buesch wrote:

>> For example you could allow any logical network interface to have a 
>> different channel.  In this case, during the time that the channel you 
>> are associated on has been told you have gone into powersave mode, you 
>> can actually spend time on that other channel, before switching the 
>> channel back to check in with the AP.  So you could for example run 
>> monitor mode on channel 11 while being associated on channel 2, given 
>> the limitation that sometimes you aren't listening because you are 
> 
> And what's it good for to have a monitor device that randomly misses
> half of the packets? I mean... rather useless, no?

Well it would hopefully be much less than half the time you are away. 
If nothing much is going on in the associated channel, which a lot of 
the time is true, then you would be spending most of the time monitoring 
on the other channel.  Depending on the reason though even a 10% capture 
of another channel that you can currently see 0% of could be great... 
and it would be happening using a standard Monitor interface.

The immediate use for it is a continuous awareness of the kind of stuff 
going on around you on other channels, as I mentioned it could replace 
the current beacon "scan" concept with more of an eye of Sauron operated 
using the existing Monitor semantics.

But I can also use it for the penumbra broadcast stuff.  If it enables 
autodetection of other channels with the traffic on and automatic usage 
of those channels without really affecting the association to the user's 
AP on another channel, that is a very cool feature.

>> Is there something like firmware constraints or the detail of the 
>> powersaving protocol that kill this dead or is it possible to consider?
> 
> For software MAC devices this might work. But I think performance would suck.
> But it sounds like it's worth an experiment. So if you want to.. :)

Well, about general performance, it can modulate the amount of 
powersaving time it is willing to use according to the amount of packets 
coming to and going from the associated interface.

-Andy

Re: Faking powersave for fun and realtime channel muxing

[Andy Green]

Michael Wu wrote:
> On Monday 19 March 2007 15:57, Andy Green wrote:
>> Hi folks -
>>
>> If you could generate and manage powersave protocol frames to an AP from
>> the mac80211 stack, without actually putting the radio to sleep, you
>> could do some interesting things.
>>
> Like in my scanning patch series?
> 
> http://news.gmane.org/find-root.php?group=gmane.linux.kernel.wireless.general&article=770

Yeah exactly like that, you're way ahead of me.  I will study these 
tomorrow.  Thanks for the pointer and the boost with these patches.

> This requires a bit of kernel side support to queue up frames on the client 
> side to maintain the illusion that nothing happened. (except for a brief 
> latency jump) However, it does seem to work for the wireless cards I've 

That's very encouraging!

> tested. Doing scanning like this in userspace will require some sort of 
> interface to stop/restart the TX for the appropriate network interfaces, but 
> will probably make your multichannel association idea possible.

I didn't catch what you meant in the last bit, "some sort of interface 
to stop/restart the TX"?  You mean for associated interfaces that are 
currently "sleeping" they need to use the netdev-level interface start 
and stop stuff?

> As for how long the AP will hold your frames.. 802.11 defines a minimum time, 
> but the maximum depends on the AP.

I guess an important thing is that in the degenerate case where there is 
only one logical interface up and associated, powersave mode doesn't get 
used at all, it goes on like it does now.

Then for associated interfaces when fake powersave mode is in use, it's 
important that any queued packets at the AP are taken to keep the count 
of packets held there low.  Packets queued in the driver for TX should 
be dealt with to try to keep the count of packets queued there low too, 
but it's less critical I guess.  So when associated interfaces are busy, 
they hog all the time between them.

Then last in the priority is Monitor interface time.  So when associated 
interfaces are relatively idle, you can spend large blocks of time 
monitoring on other channels.

-Andy

Re: Faking powersave for fun and realtime channel muxing

[James Ketrenos]

Andy Green wrote:
> Michael Buesch wrote:
...
>> And what's it good for to have a monitor device that randomly misses
>> half of the packets? I mean... rather useless, no?
...
> The immediate use for it is a continuous awareness of the kind of stuff 
> going on around you on other channels, as I mentioned it could replace 
> the current beacon "scan" concept with more of an eye of Sauron operated 
> using the existing Monitor semantics.

This is how the background scanning works in the ipw adapters.  You configure the 
sleep intervals and it then hops to other channels with the AP set to queue frames 
for you.  We removed the functionality from being the default in the driver when 
users complained about ping latency being erratic...

> But I can also use it for the penumbra broadcast stuff.  If it enables 
> autodetection of other channels with the traffic on and automatic usage 
> of those channels without really affecting the association to the user's 
> AP on another channel, that is a very cool feature.

Having spectrum usage knowledge (even with a low sampling rate) for user space to 
make intelligent decisions is *very* useful, and something that we completely lack 
today with Linux.  Anyone that has ever been at OLS knows wireless there sucks -- 
and the #1 reason is because of the AP selection heuristics currently in use... you 
may have an AP in the corner of the room completely unused at a weaker signal but 
with the full channel available for use.  Having this type of measurement kick in 
when congestion is detected (and latency would already suck) and then have user 
space make a decision to pro actively re-associate to a new AP -- and if it 
succeeds, disassociate with the current -- would be great.

> 
>>> Is there something like firmware constraints or the detail of the 
>>> powersaving protocol that kill this dead or is it possible to consider?
>>
>> For software MAC devices this might work. But I think performance 
>> would suck.
>> But it sounds like it's worth an experiment. So if you want to.. :)
> 
> Well, about general performance, it can modulate the amount of 
> powersaving time it is willing to use according to the amount of packets 
> coming to and going from the associated interface.

You can almost do it today with iwlwifi and the hardware/uCode assisted scanning.

Currently the driver has that code path inactive due to a bug that keeps it from 
working at all; but once hooked in you can configure the amount of time to leave 
the active channel and then the uCode will hop around to other channels in the 
background.

James

Re: Faking powersave for fun and realtime channel muxing

[Jiri Benc]

On Mon, 19 Mar 2007 19:57:40 +0000, Andy Green wrote:
> Depending on the limitations of the time you can arrange to "sleep" with 
> the AP, using this technique you could even associate multiple logical 
> interfaces to APs on different channels despite they are sharing one 
> physical radio.  That could be cool for dealing with realtime selection 
> of the best channel/AP when the guy is mobile, for example.

Nice idea, but it won't work. You are completely dependent on AP's
timing and if the beacon interval and DTIM period is the same at both
APs (that's quite likely) and DTIMs are sent at more or less the same
time (that could happen), bad luck. How would you explain to users that
it won't work in some random cases?

Using the time between two DTIMs to tune to other channels for other
purposes (like _active_ scanning - note that passive scanning won't
work) or getting rough idea of channels usage could work. But as was
already noted, it requires tx traffic to be buffered, thus degrading
performance. You need to balance these two things pretty well - not an
easy job, I would say.

Also, consider that an amount of time required to tune to another
channel is not zero.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs