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 considering 
wpa_supplicant supports concurrent operation. 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 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).
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20130401/3b7c47bd/attachment.html>