linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stuffed Crust <pizza@shaftnet.org>
To: Sam Leffler <sam@errno.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: wireless: recap of current issues (configuration)
Date: Mon, 16 Jan 2006 14:40:13 -0500	[thread overview]
Message-ID: <20060116194013.GA12748@shaftnet.org> (raw)
In-Reply-To: <43CBDDC7.9060504@errno.com>

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

On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
> The way you implement bg scanning is to notify the ap you are going into 
> power save mode before you leave the channel (in sta mode).  Hence bg 
> scanning and power save operation interact.

That is not "powersave operation" -- that is telling the AP we are going
into powersave, but not actually going into powersave -- Actual
powersave operation would need to be disabled if we go into a scan, as
we need to have the rx path powered up and ready to hear anything out
there for the full channel dwell time.

> See above.  Doing bg scanning well is a balancing act and restoring 
> hardware state is the least of your worries (hopefully); e.g. what's the 
> right thing to do when you get a frame to transmit while off-channel 
> scanning, how often should you return to the bss channel?

Disallow all other transmits (either by failing them altogether, or by 
buffering them up, which I think is better) while performing the scan.

If we are (continually) scanning because we don't have an association, 
then we shouldn't be allowing any traffic through the stack anyway.

At the end of each scan pass, you return to the original channel, then 
return "scan complete" to the stack/userspace.  at this point any 
pending transmits can go out, and if another scan pass is desired, it 
will happen then.

> Er, you need to listen to at least beacons from other ap's if you're in 
> 11g so you can detect overlapping bss and enable protection.  There are 
> other ways to handle this but that's one.

If you can't hear the traffic, then it doesn't count for purposes of ER
protection -- but that said, this only matters for AP operation, so APs
shouldn't filter out anyone else's becacons.  STAs should respect the
"use ER Protection" bit in the AP's beacon, so can filter out traffic 
that doesn't match the configured BSSID.

> >Oh, I know.  I've burned out many brain cells trying to build 
> >supportable solutions for our customers.   
> 
> I don't recall seeing well-developed scanning code in either of the 
> proposed stacks.

I've only looked into the pre-2.6-merged HostAP stack, so I can't 
comment on what's publically available.  I'll have a look at the GPL'ed 
DeviceScape stack when I have more time.

Most of what I've going on about is derived from my experience from
commercial 802.11 work I've done over the past few years.

 - Solomon
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

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

  reply	other threads:[~2006-01-16 19:41 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060113195723.GB16166@tuxdriver.com>
2006-01-13 21:26 ` wireless: recap of current issues (intro) John W. Linville
     [not found]   ` <20060113213011.GE16166@tuxdriver.com>
2006-01-13 22:19     ` wireless: recap of current issues (configuration) John W. Linville
2006-01-13 22:32       ` Johannes Berg
2006-01-14  1:17         ` Stuffed Crust
2006-01-14  9:28           ` Johannes Berg
2006-01-14 13:47             ` Krzysztof Halasa
2006-01-14 22:07           ` Jeff Garzik
2006-01-15 15:20             ` Stuffed Crust
2006-01-15 19:05               ` Samuel Ortiz
2006-01-16 17:09                 ` Stuffed Crust
2006-01-16 18:51                   ` Samuel Ortiz
2006-01-16 19:06                     ` John W. Linville
2006-01-16 20:16                       ` Samuel Ortiz
2006-01-16 21:06                         ` Stuffed Crust
2006-01-16 22:24                       ` Alan Cox
2006-01-16 23:02                         ` John W. Linville
2006-01-17 18:41                         ` Stuffed Crust
2006-01-17 18:54                           ` Kyle Moffett
2006-01-15 19:53               ` Sam Leffler
2006-01-16 17:28                 ` Stuffed Crust
2006-01-16 17:54                   ` Sam Leffler
2006-01-16 19:40                     ` Stuffed Crust [this message]
2006-01-16 20:14                       ` Sam Leffler
2006-01-16 20:58                         ` Stuffed Crust
2006-01-16 18:39                   ` Dan Williams
2006-01-16 19:07                   ` Samuel Ortiz
2006-01-16 19:50                     ` Stuffed Crust
2006-01-16 20:10                       ` Samuel Ortiz
2006-01-15 12:40         ` Stefan Rompf
2006-01-15 15:51           ` Johannes Berg
2006-01-15 17:53             ` Stefan Rompf
2006-01-15 20:08               ` Sam Leffler
2006-01-15 20:11                 ` Johannes Berg
2006-01-17 22:20                   ` Stefan Rompf
2006-01-15 19:39           ` Sam Leffler
2006-01-16  0:06             ` Mike Kershaw
2006-01-16 14:23         ` Jiri Benc
2006-01-16 14:55           ` Johannes Berg
2006-01-16 17:33             ` Stuffed Crust
2006-01-16 18:00               ` Sam Leffler
2006-01-16 20:16                 ` Stuffed Crust
2006-01-14  0:05       ` Krzysztof Halasa
2006-01-14 23:41       ` Dan Williams
2006-01-15 16:18         ` Stuffed Crust
2006-01-15  9:35       ` feyd
     [not found]   ` <20060113213126.GF16166@tuxdriver.com>
2006-01-13 22:20     ` wireless: recap of current issues (compatibility) John W. Linville
2006-01-13 22:33       ` Johannes Berg
2006-01-14 13:44         ` Krzysztof Halasa
     [not found]   ` <20060113213237.GH16166@tuxdriver.com>
2006-01-13 22:24     ` wireless: recap of current issues (other issues) John W. Linville
2006-01-13 22:35       ` Johannes Berg
2006-01-13 23:02         ` Johannes Berg
2006-01-14 22:09       ` Jeff Garzik
2006-01-15  0:54         ` John W. Linville
2006-01-15  1:51         ` David S. Miller
2006-01-15 11:23           ` Arnaldo Carvalho de Melo
2006-01-15 15:39         ` Stuffed Crust
2006-01-17 23:36           ` wireless: recap of current issues (other issues / fake ethernet) Stefan Rompf
2006-01-18 16:32             ` Stuffed Crust
     [not found]   ` <20060113213311.GI16166@tuxdriver.com>
2006-01-13 22:25     ` wireless: recap of current issues (actions) John W. Linville
2006-01-13 22:36       ` Johannes Berg
2006-01-14 22:11       ` Jeff Garzik
2006-01-15  0:56         ` John W. Linville
2006-01-16 14:44           ` Johannes Berg
     [not found]   ` <20060113213200.GG16166@tuxdriver.com>
2006-01-13 22:22     ` wireless: recap of current issues (stack) John W. Linville
2006-01-13 22:34       ` Johannes Berg
2006-01-13 23:03     ` Chase Venters
2006-01-14 10:46       ` Simon Kelley
2006-01-14 23:29         ` Dan Williams
2006-01-14 13:51       ` Michael Buesch
2006-01-17 17:38         ` Jean Tourrilhes
2006-01-14 14:13     ` Ulrich Kunitz
2006-01-15  4:42       ` Pete Zaitcev
2006-01-15 10:04         ` Ulrich Kunitz
     [not found] ` <43C80F9A.8020203@candelatech.com>
2006-01-13 22:49   ` wireless: recap of current issues Ben Greear

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=20060116194013.GA12748@shaftnet.org \
    --to=pizza@shaftnet.org \
    --cc=jgarzik@pobox.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sam@errno.com \
    /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).