[PATCH] Avoid unnecessary triggering of rescans

Jouni Malinen j
Wed Mar 12 00:22:35 PDT 2008


On Mon, Mar 10, 2008 at 10:45:58AM -0400, Dan Williams wrote:

> True.  Jouni, would you accept patches that cache scan results in the
> supplicant for a while similar to what currently happens in some
> drivers?  Proposed policy:

Yes, that sounds like a reasonable thing to do since we won't ever get
consistent behavior from all possible drivers/OSes..

> 1) Keep a per-device scan cache to hold wpa_s objects

OK.

> 2) Keep the BSS that the supplicant is associated with in the scan list
> until disassociation

OK.

> 3) Keep scan results around for ~ 15 seconds before culling them;
> perhaps this threshold value could be a config option

OK. This value should be large enough to handle full cycle of broadcast
scan and specific SSID scans so that hidden SSIDs won't be constantly
removed and added to the cache if driver clears the scan result data for
each scan and only reports matches from the last one.

> Thoughts?  This would include changes to
> wpa_supplicant_get_scan_results() and
> wpa_supplicant_get_scan_results_old() to not simply free the old scan
> list, but to merge scan results, removing ones older than the threshold,
> adding new ones, and updating the timestamp of ones found again.

I would prefer to handle _old() as a minimal wrapper to just convert the
old structure to a new one and the new merging/expiration code should
just process results in the new format. This could probably be merged
with the wpa_scan_sort_results() functionality so that both the sorting
and merging are handled as a step after collecting the scan results from
the driver.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list