[PATCH] Remove cached scan results earlier in Android

Jouni Malinen j
Fri Mar 27 10:40:09 PDT 2015

On Sat, Mar 21, 2015 at 12:47:56PM +0100, Ola Olsson wrote:
> Android has a feature where wifi seems to be off
> but the kernel module is still loaded (scanning always enabled).
> This enables applications to scan for new SSID:s even when
> the wifi components itself does not trigger any scan. Hence,
> it might take a while between scan requests.
> If a second scan is not made within 180 seconds, no matter how far
> you have traveled, the scan result will be the union of
> the new scan result and the last scan result. I might actually be able
> to travel more than 3km (~2 miles) in this period of time and still
> get the same SSID:s as I got in the last result. This is an extreme case
> but enough to simplify the problematic situation. There are other real
> world scenarios that will happen when RTT is enabled though.

Could you please clarify why wpa_supplicant maintaining a BSS entry in
its internal cache for a longer time than the BSS is in radio range is
an issue? If any component needs to know whether the BSS is still
present, it would need to look at the age of the entry and potentially
request a new scan to be performed.

> The rationale behind the new value (25) is that I have noticed that a scan
> can be made every 10 second by being in the wifi settings menu and
> I want to be able to miss an AP one time without having it removed
> from the cache. The reason why I did not choose 20 seconds sharp
> is because the eloop_register_timeout that triggers
> wpa_bss_flush_by_age method is not synced or restarted when the
> scan result arrives.

If you are trying to modify UI behavior, the correct place to do that is
in the UI implementation..

> diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h
> @@ -22,7 +22,11 @@
> +#ifdef ANDROID
> +#else
> +#endif

This does not sound desirable. Why would Android behave any differently
here? I would suggest looking at modifications in the UI to look at the
BSS entry age and not show old entries to the user if that is the use
case you are thinking of. Or if this is for some other reason, that
other code using this information should likely consider the age of the
entry and ignore too old values for its particular needs.
Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list