Re: Further improvements to the software scan implementation

["Luis R. Rodriguez" <mcgrof@gmail.com>]

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
>