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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html