This patch aims to decrease channel switching when there is at least one
interface associated. This should help multiple station interfaces co-exist
on the same hardware, especially in WPA mode.
This patch is on top of the other 3 I posted recently, and even though I think
this patch is going in the right direction, I still cannot get two WPA interfaces
to complete authentication.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Wed, 2010-09-15 at 07:21 -0700, Ben Greear wrote:
> Right, but as soon as one finished, the next would start, and at least in .31,
> that caused the first to un-associate, giving never-ending loop of interfaces
> scanning and trying to associate.
There should be a grace period maybe?
> Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
> use.
Just make it give the channel instead of adding new API.
johannes
On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.
> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)
"Standard wpa_supplicant" needs to become more aware of multiple users
of the same radio, so it is certainly fine to add changes there. For
example, a mechanism for noticing that interfaces are sharing a radio
would be useful. With that, it should also be possible to share the BSS
table and scan results (and requests!) within wpa_supplicant.
Sure, mac80211 could potentially do some of merging and reusing, too,
but as far as wpa_supplicant use cases (including hostapd and AP mode in
Wi-Fi P2P like use cases here) are concerned, mac80211 changes may not
be needed for handling the scanning part.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2010-09-15 at 00:46 -0500, Dan Williams wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
> > On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> > > On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> > >> This patch aims to decrease channel switching when there is at least one
> > >> interface associated. This should help multiple station interfaces co-exist
> > >> on the same hardware, especially in WPA mode.
> > >
> > > If I understood the change correctly, it would prevent running full
> > > scans when in associated state. That does not sound reasonable behavior
> > > and scanning should not cause an association to be lost. Did I miss
> > > something or what exactly is this trying to do?
> >
> > That's pretty much what I'm trying to do. We had similar code in
> > our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> > started with WPA and all of them trying to scan all channels at once!
> > Most got timeouts, and one scanning would disrupt traffic on the others.
> > And, the hardware can only associate on a single channel anyway, so getting
> > scan results for other channels doesn't do a great deal of good.
> >
> > With current ath9k, I see DMA timeouts and other nasty things (without
> > that patch applied) when trying to bring up two VIFs with WPA.
> >
> > I think for the multi-VIF scenario, it should scan the single associated
> > channel by default, but it would be nice to allow full scans on demand.
> > (I would very much like to work with standard wpa_supplicant, but if hacking it
> > is the only way, then I can attempt that.)
>
> Allowing full scans on demand (ie when userspace requests it) is a must.
> Even in multi-VIF mode.
Obviously I mean "when associated"...
> Dan
>
> > > If you want to limit scans a single channel in some special use cases,
> > > you should be able to do that in user space, too, at least for the
> > > initial scan before connection. As a future optimization, we should
> > > somehow be able to merge scan requests from multiple VIFs into a single
> > > one, i.e., share the results from a single scan to multiple VIFs..
> >
> > Merging would be nice. Maybe store the results in the global hardware/phy
> > structs and just return that to user-space so long as it's relatively fresh?
> >
> > > It would be easier to comment on the changes if you were to inline them
> > > instead of attaching the file..
> >
> > Sorry about that..I'll inline it next time. It will probably be white-space
> > damaged, but I can re-send any official patches using git.
> >
> > Thanks,
> > Ben
> >
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/15/2010 02:04 PM, Luis R. Rodriguez wrote:
> On Wed, Sep 15, 2010 at 1:31 PM, Jouni Malinen<[email protected]> wrote:
>> On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
>>> I think for the multi-VIF scenario, it should scan the single associated
>>> channel by default, but it would be nice to allow full scans on demand.
>>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>>> is the only way, then I can attempt that.)
>>
>> "Standard wpa_supplicant" needs to become more aware of multiple users
>> of the same radio, so it is certainly fine to add changes there. For
>> example, a mechanism for noticing that interfaces are sharing a radio
>> would be useful. With that, it should also be possible to share the BSS
>> table and scan results (and requests!) within wpa_supplicant.
>
> Depending on how this is implementing, sharing of the physical radio
> may require some kernel synchronization between the different
> interfaces using the same radio. It may also be possible to share the
> same radio between an 802.11 device and a wimax device, for example.
> Long ago we thought up of a frequency broker [1] but never really
> wrote it as we have had no usage case for it yet. If we implement the
> frequency broker we could also technically add a scheduler to sharing
> the same radio between separate interfaces / technologies, this could
> just be done in userspace as well, although I am not sure if the
> timing considerations for doing it in userspace would suffice.
At least for my use, I hope to be able to fully utilize the bandwidth for
a particular channel, and emulate as close as possible a bunch of wireless
devices sharing an AP or set of APs. So, I don't want to be switching off the main
channel for any significant amount of time. I think as long as you stick
to the main channel, there are no significant scheduling issues with
the hardware, but I could be wrong about that.
Also, I want to be able to run one supplicant per interface, so while
wpa_supplicant could become clever if it manages multiple devices, I
want them to be able to run independently as well.
As for figuring out what hardware a VIF belongs to, you can deduce this
by following links in sysfs to find it's phyX device. It is a pain
when the phyX changes name due to module reload or something, but it can still
be dealt with.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Wed, Sep 15, 2010 at 1:31 PM, Jouni Malinen <[email protected]> wrote:
> On Tue, Sep 14, 2010 at 10:30:04PM -0700, Ben Greear wrote:
>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> "Standard wpa_supplicant" needs to become more aware of multiple users
> of the same radio, so it is certainly fine to add changes there. For
> example, a mechanism for noticing that interfaces are sharing a radio
> would be useful. With that, it should also be possible to share the BSS
> table and scan results (and requests!) within wpa_supplicant.
Depending on how this is implementing, sharing of the physical radio
may require some kernel synchronization between the different
interfaces using the same radio. It may also be possible to share the
same radio between an 802.11 device and a wimax device, for example.
Long ago we thought up of a frequency broker [1] but never really
wrote it as we have had no usage case for it yet. If we implement the
frequency broker we could also technically add a scheduler to sharing
the same radio between separate interfaces / technologies, this could
just be done in userspace as well, although I am not sure if the
timing considerations for doing it in userspace would suffice.
[1] http://wireless.kernel.org/en/developers/FrequencyBroker
Luis
> Sure, mac80211 could potentially do some of merging and reusing, too,
> but as far as wpa_supplicant use cases (including hostapd and AP mode in
> Wi-Fi P2P like use cases here) are concerned, mac80211 changes may not
> be needed for handling the scanning part.
>
> --
> Jouni Malinen PGP id EFC895FA
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, 2010-09-15 at 08:32 -0700, Ben Greear wrote:
> >> Right, but as soon as one finished, the next would start, and at least in .31,
> >> that caused the first to un-associate, giving never-ending loop of interfaces
> >> scanning and trying to associate.
> >
> > There should be a grace period maybe?
>
> I don't think that really fixes anything, except make the race between
> full scan and attempting for the first interface to associate harder to
> hit (and that is only useful if the scan-one logic is enabled anyway).
I think you just need to update ... newer kernels shouldn't be allowing
a scan while trying to associate, I think.
johannes
On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
> > If I understood the change correctly, it would prevent running full
> > scans when in associated state. That does not sound reasonable behavior
> > and scanning should not cause an association to be lost. Did I miss
> > something or what exactly is this trying to do?
>
> That's pretty much what I'm trying to do. We had similar code in
> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> started with WPA and all of them trying to scan all channels at once!
They can't ... cfg80211 limits it to one scan at a time per hardware ...
> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.
Go change your userspace then to request only the single channel scan.
> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)
Yes, I don't see how we can reasonably work around this in the kernel.
> > If you want to limit scans a single channel in some special use cases,
> > you should be able to do that in user space, too, at least for the
> > initial scan before connection. As a future optimization, we should
> > somehow be able to merge scan requests from multiple VIFs into a single
> > one, i.e., share the results from a single scan to multiple VIFs..
>
> Merging would be nice. Maybe store the results in the global hardware/phy
> structs and just return that to user-space so long as it's relatively fresh?
That's what we do, unless userspace requests a new scan.
johannes
On 09/15/2010 03:16 AM, Johannes Berg wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
>
>>> If I understood the change correctly, it would prevent running full
>>> scans when in associated state. That does not sound reasonable behavior
>>> and scanning should not cause an association to be lost. Did I miss
>>> something or what exactly is this trying to do?
>>
>> That's pretty much what I'm trying to do. We had similar code in
>> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
>> started with WPA and all of them trying to scan all channels at once!
>
> They can't ... cfg80211 limits it to one scan at a time per hardware ...
Right, but as soon as one finished, the next would start, and at least in .31,
that caused the first to un-associate, giving never-ending loop of interfaces
scanning and trying to associate.
>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>
> Go change your userspace then to request only the single channel scan.
>
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> Yes, I don't see how we can reasonably work around this in the kernel.
Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
use.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> This patch aims to decrease channel switching when there is at least one
> interface associated. This should help multiple station interfaces co-exist
> on the same hardware, especially in WPA mode.
If I understood the change correctly, it would prevent running full
scans when in associated state. That does not sound reasonable behavior
and scanning should not cause an association to be lost. Did I miss
something or what exactly is this trying to do?
If you want to limit scans a single channel in some special use cases,
you should be able to do that in user space, too, at least for the
initial scan before connection. As a future optimization, we should
somehow be able to merge scan requests from multiple VIFs into a single
one, i.e., share the results from a single scan to multiple VIFs..
PS.
It would be easier to comment on the changes if you were to inline them
instead of attaching the file..
--
Jouni Malinen PGP id EFC895FA
On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
> On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> > On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
> >> This patch aims to decrease channel switching when there is at least one
> >> interface associated. This should help multiple station interfaces co-exist
> >> on the same hardware, especially in WPA mode.
> >
> > If I understood the change correctly, it would prevent running full
> > scans when in associated state. That does not sound reasonable behavior
> > and scanning should not cause an association to be lost. Did I miss
> > something or what exactly is this trying to do?
>
> That's pretty much what I'm trying to do. We had similar code in
> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
> started with WPA and all of them trying to scan all channels at once!
> Most got timeouts, and one scanning would disrupt traffic on the others.
> And, the hardware can only associate on a single channel anyway, so getting
> scan results for other channels doesn't do a great deal of good.
>
> With current ath9k, I see DMA timeouts and other nasty things (without
> that patch applied) when trying to bring up two VIFs with WPA.
>
> I think for the multi-VIF scenario, it should scan the single associated
> channel by default, but it would be nice to allow full scans on demand.
> (I would very much like to work with standard wpa_supplicant, but if hacking it
> is the only way, then I can attempt that.)
Allowing full scans on demand (ie when userspace requests it) is a must.
Even in multi-VIF mode.
Dan
> > If you want to limit scans a single channel in some special use cases,
> > you should be able to do that in user space, too, at least for the
> > initial scan before connection. As a future optimization, we should
> > somehow be able to merge scan requests from multiple VIFs into a single
> > one, i.e., share the results from a single scan to multiple VIFs..
>
> Merging would be nice. Maybe store the results in the global hardware/phy
> structs and just return that to user-space so long as it's relatively fresh?
>
> > It would be easier to comment on the changes if you were to inline them
> > instead of attaching the file..
>
> Sorry about that..I'll inline it next time. It will probably be white-space
> damaged, but I can re-send any official patches using git.
>
> Thanks,
> Ben
>
>
On 09/14/2010 08:03 PM, Jouni Malinen wrote:
> On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
>> This patch aims to decrease channel switching when there is at least one
>> interface associated. This should help multiple station interfaces co-exist
>> on the same hardware, especially in WPA mode.
>
> If I understood the change correctly, it would prevent running full
> scans when in associated state. That does not sound reasonable behavior
> and scanning should not cause an association to be lost. Did I miss
> something or what exactly is this trying to do?
That's pretty much what I'm trying to do. We had similar code in
our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
started with WPA and all of them trying to scan all channels at once!
Most got timeouts, and one scanning would disrupt traffic on the others.
And, the hardware can only associate on a single channel anyway, so getting
scan results for other channels doesn't do a great deal of good.
With current ath9k, I see DMA timeouts and other nasty things (without
that patch applied) when trying to bring up two VIFs with WPA.
I think for the multi-VIF scenario, it should scan the single associated
channel by default, but it would be nice to allow full scans on demand.
(I would very much like to work with standard wpa_supplicant, but if hacking it
is the only way, then I can attempt that.)
> If you want to limit scans a single channel in some special use cases,
> you should be able to do that in user space, too, at least for the
> initial scan before connection. As a future optimization, we should
> somehow be able to merge scan requests from multiple VIFs into a single
> one, i.e., share the results from a single scan to multiple VIFs..
Merging would be nice. Maybe store the results in the global hardware/phy
structs and just return that to user-space so long as it's relatively fresh?
> It would be easier to comment on the changes if you were to inline them
> instead of attaching the file..
Sorry about that..I'll inline it next time. It will probably be white-space
damaged, but I can re-send any official patches using git.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 09/14/2010 10:46 PM, Dan Williams wrote:
> On Tue, 2010-09-14 at 22:30 -0700, Ben Greear wrote:
>> On 09/14/2010 08:03 PM, Jouni Malinen wrote:
>>> On Mon, Sep 13, 2010 at 04:14:05PM -0700, Ben Greear wrote:
>>>> This patch aims to decrease channel switching when there is at least one
>>>> interface associated. This should help multiple station interfaces co-exist
>>>> on the same hardware, especially in WPA mode.
>>>
>>> If I understood the change correctly, it would prevent running full
>>> scans when in associated state. That does not sound reasonable behavior
>>> and scanning should not cause an association to be lost. Did I miss
>>> something or what exactly is this trying to do?
>>
>> That's pretty much what I'm trying to do. We had similar code in
>> our 2.6.31 kernel with ath5k. Imagine getting 50 virtual stations
>> started with WPA and all of them trying to scan all channels at once!
>> Most got timeouts, and one scanning would disrupt traffic on the others.
>> And, the hardware can only associate on a single channel anyway, so getting
>> scan results for other channels doesn't do a great deal of good.
>>
>> With current ath9k, I see DMA timeouts and other nasty things (without
>> that patch applied) when trying to bring up two VIFs with WPA.
>>
>> I think for the multi-VIF scenario, it should scan the single associated
>> channel by default, but it would be nice to allow full scans on demand.
>> (I would very much like to work with standard wpa_supplicant, but if hacking it
>> is the only way, then I can attempt that.)
>
> Allowing full scans on demand (ie when userspace requests it) is a must.
> Even in multi-VIF mode.
So, something like 'iw sta1 scan all' to force scanning all,
with 'iw sta1 scan' just returning results for associated channel
in multi-vif scenario?
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 09/15/2010 08:37 AM, Johannes Berg wrote:
> On Wed, 2010-09-15 at 08:32 -0700, Ben Greear wrote:
>
>>>> Right, but as soon as one finished, the next would start, and at least in .31,
>>>> that caused the first to un-associate, giving never-ending loop of interfaces
>>>> scanning and trying to associate.
>>>
>>> There should be a grace period maybe?
>>
>> I don't think that really fixes anything, except make the race between
>> full scan and attempting for the first interface to associate harder to
>> hit (and that is only useful if the scan-one logic is enabled anyway).
>
> I think you just need to update ... newer kernels shouldn't be allowing
> a scan while trying to associate, I think.
Grab top-of-tree wireless-testing and apply my rxfilt patch to ath9k, and you can create two VIFS
and attempt to run wpa_supplicant against them (I use one supplicant per
interface.)
Unless it was fixed last night, I doubt you will have any luck.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On 09/15/2010 07:24 AM, Johannes Berg wrote:
> On Wed, 2010-09-15 at 07:21 -0700, Ben Greear wrote:
>
>> Right, but as soon as one finished, the next would start, and at least in .31,
>> that caused the first to un-associate, giving never-ending loop of interfaces
>> scanning and trying to associate.
>
> There should be a grace period maybe?
I don't think that really fixes anything, except make the race between
full scan and attempting for the first interface to associate harder to
hit (and that is only useful if the scan-one logic is enabled anyway).
>> Ok, I'll see if I can add a 'scan-one-if-associated' flag for wpa-supplicant to
>> use.
>
> Just make it give the channel instead of adding new API.
I think you still need an 'any', because whoever wrote the wpa_supplicant config file doesn't
necessarily know what channel the AP is on. The first interface to do a full scan
can figure that out and associate....
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com