[PATCH 0/5 - v2] Automatic scanning support

[Tomasz Bursztyka]

Hi Alexander,

> -	It should provide a mean to implement customized periodic unassociated scan policy.
> 	All decisions related to this kind of scan should be encapsulated inside the autoscan plugin.
> 	The same concept as bgscan.
I do not agree with that, bgscan encapsulated its own scan triggers 
since it could not reuse existing ones: there is nothing triggering a 
scan when connected. And due to that, it's doomed to need a lot of 
implementation about that on each bgscan module, managing the triggers, 
the timeouts etc...
Instead I preferred reusing sched_scan/scan_interval. Less intrusive in 
wpa_s code and it triggers the scan for you.
And actually, you can customize the periods (like the proposed 
"exponential" module does, if you want something else you can improve 
autoscan with another module), from that I don't see any advantage doing 
like bgscan especially for the period.
>   In Android, for example, we need a specific periodic scan policy
> 	because many decisions on periodic scan are taken above supplicant, in the framework.
That is already possible: you can provide you own module to autoscan. 
The "exponential" one is a very basic one.  You can make a module that 
fits your specific needs.
> -	It should provide an ability to control scan parameters beside scan period. Autoscan plugin must be
> 	able to alter SSIDs list and scan frequencies in scan request on its own behalf.
That can be done already, again in a module you want. You can play there 
with wpa_s->ssid which is used then by 
wpa_supplicant_req_sched_scan()/wpa_supplicant_req_scan()
> -	Autoscan should be triggered by scan results event only when candidate not found. No need to trigger it
> 	otherwise.
I agree, we might stop autoscan (autoscan_deinit()) in the event loop 
when the state is authenticating. Good point.
> Also, no need to fire the very first scan since it is done when interface is created.
When it is created yes, not when it just got disconnected. But indeed it 
could be smarter here.
> -	It should expose interface for authentication start notification to cancel periodic scan when connection starts
See my previous comment above about authenticating state. I don't think 
there is a need of exposing more function here.
> -	It should expose interface for configuration update notification to adjust scan request parameters when they
> 	are changed in config file or through ctrl_iface
Again, no need to expose anything, let's play with 
autoscan_deinit()/autoscan_init() at the right places.
I forgot the ctrl_iface implementation, that's a lack, definitively.
> BTW, we have implementation similar to what you have suggested, addressing the above concerns.
>
Where is it?

Best regards,

Tomasz