From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC ] wireless: Support can-scan-one logic.
Date: Thu, 12 May 2011 09:43:42 -0700 [thread overview]
Message-ID: <4DCC0E3E.1080709@candelatech.com> (raw)
In-Reply-To: <1305188791.3461.6.camel@jlt3.sipsolutions.net>
On 05/12/2011 01:26 AM, Johannes Berg wrote:
> On Tue, 2011-05-10 at 12:56 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> Enable this by passing a -1 for a scan frequency.
>>
>> When enabled, the system will only scan the current active
>> channel if at least one VIF is actively using it. If no
>> VIFS are active or this flag is disabled, then default
>> behaviour is used.
>>
>> This helps when using multiple STA interfaces that otherwise might
>> constantly be trying to scan all channels.
>
> I still don't see what stops you from doing this in userspace, I don't
> remember a compelling reason for implementing this in the kernel.
The reasons are relatively small, but enough to make the patch useful to me.
First, it works with non-userspace scan logic (sme).
Second, if user is running more than one supplicant, it might be difficult
to know how many interfaces are associated. Or, if a single supplicant process
isn't managing all wireless interfaces (maybe a few VAPs plus some STA interfaces
using in-kernel scanning (sme))?
> Clearly, you need to modify userspace anyhow. Also, what if, in the
> future, we have multiplel STA interfaces on different channels? Which
I'm not sure that having STA on different channels would ever actually work. The attempt to
support that kind of thing in ath9k certainly didn't work too well.
If it ever was implemented, then the -1 could mean choose all channels
upon which something is associated.
I do have a patch to wpa_supplicant that lets the user enable this
feature if they want. I currently probe the support for this feature
by attempting a scan on channel -1 and detecting failure. This way, I
can have my code work on un-patched kernels as well as kernels with this
patch installed.
> one(s) should it pick then? The -1 trick will also break all
> non-mac80211 drivers, or maybe simply not work?
If passing a bogus value from user-space breaks the driver, then
the driver is busted. I would assume it would simply not work.
My patch to wpa_supplicant disables the feature by default, so
someone has to actively turn it on to pass in -1.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
prev parent reply other threads:[~2011-05-12 16:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-10 19:56 [RFC ] wireless: Support can-scan-one logic greearb
2011-05-10 19:58 ` Ben Greear
2011-05-10 19:59 ` Daniel Halperin
2011-05-10 20:06 ` Ben Greear
2011-05-12 8:26 ` Johannes Berg
2011-05-12 16:43 ` Ben Greear [this message]
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=4DCC0E3E.1080709@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.