wpa-supplicant and scan sharing

[Otcheretianski, Andrei]

> -----Original Message-----
> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of Ben
> Greear
> Sent: Wednesday, May 31, 2017 00:45
> To: hostap at lists.infradead.org
> Subject: wpa-supplicant and scan sharing
> 
> [Sorry for previous email with bogus subject.]
> 
> Hello,
> 
> In wpa_supplicant/events.c, there is code similar to this below.
> 
> Is there any reason 'ret = 1' other than some drivers may have issues with
> multiple association attempts?  I am pretty sure that I used to bring up many
> ath9k and ath10k station vdevs at once, so maybe this is just for Intel NICs
> (based on the comitter that changed that code last)?

This is the same behavior as it was there before this patch. Previously if scan results triggered an operation, other interfaces wouldn't be updated at all.
The patch you mention changed it to update scan results on other interfaces, but still prevents starting any operation.
Anyway, in the "if" you mention wpa_s->scan_res_handler != NULL - so it's not an association flow - the association is happening in wpas_select_network_from_last_scan()
I'm not sure what do you mean by "multiple association attempts" - concurrent connections on the same radio are serialized using radio_works anyway, and on different radios there is no scan results update from sibling.
So, here is the flow when you connect multiple interfaces: the first one will trigger scan and connect + update the siblings. Other sibling interfaces will connect directly without scant through wpa_supplicant_fast_associate().

Andrei
> 
> 
> Thanks,
> Ben
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap