First STA scan results are ignored if P2P_FIND is issued immediately after STA scan

[Sreenath]

Hello Jouni,

Thanks for the update and sorry for the delay in responding, as I was on 
vacation last week.

Our use case is like two parallel applications are running, one doing 
normal STA scan operation and the other one doing P2P_FIND. As these two 
are parallel processes, one can't wait till the logical completion of other.

So with the current implementation of wpa_supplicant, STA scan 
application is taking too much time to update and display initial scan 
results. However as subsequent STA scan requests will come during 
P2P_FIND, 'wpa_s->sta_scan_pending' will be set and because of that STA 
scan result will get preference over P2P. Moreover if 
association/authentication happen after these subsequent scans, pending 
P2P operation will be stalled further. So the omitting of first STA scan 
results will help only in the immediate starting of P2P_FIND, however 
subsequent P2P_FIND will be processed only after the processing of STA 
scan results. As doing a scan is the time consuming part and we already 
got the scan results, instead of dropping it I feel it is better to 
process it than starting the pending operation. Moreover we are going to 
provide preference for subsequent STA scan operations over P2P. So 
please give it a one more thought and update me.

Regards,
Sreenath


On 03/26/2013 02:19 PM, Jouni Malinen wrote:
> On Tue, Mar 26, 2013 at 12:51:36PM +0530, Sreenath wrote:
>> With the latest wpa_supplicant I have found an issue that the first STA
>> scan results are not processed if P2P_FIND is issued immediately in P2P
>> interface after issuing a STA scan in STA interface. However the
>> subsequent STA scan results are processed during ongoing P2P_FIND operation.
> That is by design, i.e., wpa_supplicant tries to do what it is asked to
> do. P2P_FIND issued during the station scan is interpreted as a request
> to start P2P device discovery. Since processing of the station scan
> results could start a longer operation (association with an AP), those
> results are dropped to allow the requested P2P_FIND to start.
>
>> So as a work around / fix, if the processing of pending P2P operation is
>> removed from function - '_wpa_supplicant_event_scan_results()'
>> everything works fine as STA results will be processed always and
>> pending P2P operation will be taken cared by the function -
>> "wpas_p2p_continue_after_scan()" called after
>> "wpa_supplicant_event_scan_results()" inside 'EVENT_SCAN_RESULTS' event
>> handling in "wpa_supplicant_event()".
>>
>> So kindly verify and update me, if the above modification is valid.
> Why would you issue the P2P_FIND command here in the first place? I
> think the real fix would be to not issue that if you want to get the
> station interface doing something more quickly. In concurrent operation
> case the interfaces will be competing for the same radio resource and if
> you try to start multiple operations at the same time, these will need
> to be ordered somehow and the current wpa_supplicant design is to try to
> follow the last control interface command first to match the behavior
> with single interface (last operation may stop earlier operations).
>