Further improvements to the software scan implementation

Further improvements to the software scan implementation

[Helmut Schaa]

Hi,

as already discussed with Johannes we can further optimize the scan
implementation by allowing (on an active channel) to send probes as
soon as any other frame is received (and updated the NAV) instead of
ever waiting 30ms.

Another optimization I thought of while reading [1] would be to take the
same approach as Intel in their ucode. If a frame is received while
scanning a passive channel switch to active scan mode and send out probes.
That should allow us to shorten the time needed to stay on that channel.
Luis, do you think this is ok in regard to regulatory restrictions?

Thanks,
Helmut

[1] http://sourceforge.net/mailarchive/forum.php?thread_name=200907061428.55840.jung%40ecos.de&forum_name=ipw3945-devel

Re: Further improvements to the software scan implementation

[Johannes Berg]

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

On Thu, 2009-07-16 at 11:38 +0200, Helmut Schaa wrote:
> Hi,
> 
> as already discussed with Johannes we can further optimize the scan
> implementation by allowing (on an active channel) to send probes as
> soon as any other frame is received (and updated the NAV) instead of
> ever waiting 30ms.

There's even two ways of implementing this:
 1) the easy way -- just check for received frames in mac80211
 2) the good way -- ask the driver to notify us of _any_ received frames
                    or poll the driver or something like that

1) is clearly very easy, but if it's seeing e.g. a control frame or a
frame for a different BSS then the device might not pass it up.

But to be honest, I wouldn't worry about 2) and let Jouni implement it
if he cares :) And if we want to make this improvement, 1) is good for
all hardware anyway.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Further improvements to the software scan implementation

[Johannes Berg]

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

On Thu, 2009-07-16 at 11:38 +0200, Helmut Schaa wrote:

> Another optimization I thought of while reading [1] would be to take the
> same approach as Intel in their ucode. If a frame is received while
> scanning a passive channel switch to active scan mode and send out probes.
> That should allow us to shorten the time needed to stay on that channel.
> Luis, do you think this is ok in regard to regulatory restrictions?

One problem I could see with that is the TX power to use.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Further improvements to the software scan implementation

[Luis R. Rodriguez]

Adding David Quan and Michael Green, my reply in-line below.

On Thu, Jul 16, 2009 at 2:38 AM, Helmut
Schaa<helmut.schaa@googlemail.com> wrote:
> Hi,
>
> as already discussed with Johannes we can further optimize the scan
> implementation by allowing (on an active channel) to send probes as
> soon as any other frame is received (and updated the NAV) instead of
> ever waiting 30ms.
>
> Another optimization I thought of while reading [1] would be to take the
> same approach as Intel in their ucode. If a frame is received while
> scanning a passive channel switch to active scan mode and send out probes.
> That should allow us to shorten the time needed to stay on that channel.
> Luis, do you think this is ok in regard to regulatory restrictions?

Good question. We already enable active scanning if a beacon is
received from an AP and are world roaming. We do this in mac80211
through a beacon regulatory hint to the wireless core --
regulatory_hint_found_beacon(). The assumption of the beacon
regulatory hint is that APs *must* be compliant, and some cards world
roam therefore only allowing passive scan on some channels, when you
receive a beacon from an AP on a non-DFS channel or channel 12-14 it
is safe to assume you can actively scan and beacon on that same
channel. Reason for the passive scan flag to exist is for a way to
enable some cards to world roam on some channels. Because all APs must
beacon and since we will lift this passive scan flag during an initial
scan I am inclined to believe we shouldn't bother with processing
other 802.11 frames. So in summary I'd suggest to not do this because:

1) We already have the beacons during an initial scan
2) We'd have to figure out a way to ensure the frame was indeed from an AP

  Luis

> Thanks,
> Helmut
>
> [1] http://sourceforge.net/mailarchive/forum.php?thread_name=200907061428.55840.jung%40ecos.de&forum_name=ipw3945-devel
>