Adding David Quan and Michael Green, my reply in-line below. On Thu, Jul 16, 2009 at 2:38 AM, Helmut Schaa<helmut.schaa@xxxxxxxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
