linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Green <andy@warmcat.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Faking powersave for fun and realtime channel muxing
Date: Mon, 19 Mar 2007 20:52:27 +0000	[thread overview]
Message-ID: <45FEF80B.9020107@warmcat.com> (raw)
In-Reply-To: <200703192108.43892.mb@bu3sch.de>

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

  reply	other threads:[~2007-03-19 20:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-19 19:57 Faking powersave for fun and realtime channel muxing Andy Green
2007-03-19 20:08 ` Michael Buesch
2007-03-19 20:52   ` Andy Green [this message]
2007-03-20 17:48     ` James Ketrenos
2007-03-19 20:38 ` Michael Wu
2007-03-19 21:16   ` Andy Green
2007-03-21 15:24 ` Jiri Benc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45FEF80B.9020107@warmcat.com \
    --to=andy@warmcat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).