<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000099" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hello Jouni,<br>
      <br>
      Thanks for the update and sorry for the delay in responding, as I
      was on vacation last week.<br>
      <br>
      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.<br>
      <br>
      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-&gt;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.<br>
      <br>
      Regards,<br>
      Sreenath<br>
      <br>
      On 03/26/2013 02:19 PM, Jouni Malinen wrote:<br>
    </div>
    <blockquote cite="mid:20130326084955.GA3818@w1.fi" type="cite">
      <pre wrap="">On Tue, Mar 26, 2013 at 12:51:36PM +0530, Sreenath wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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).

</pre>
    </blockquote>
    <br>
  </body>
</html>