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