[prev in list] [next in list] [prev in thread] [next in thread] 

List:       hostap
Subject:    Re: [PATCH] P2P:Remove scheduling of p2p scan without handling the STA scan results
From:       Jouni Malinen <j () w1 ! fi>
Date:       2012-12-25 10:55:56
Message-ID: 20121225105556.GC5817 () w1 ! fi
[Download RAW message or body]

On Tue, Dec 11, 2012 at 07:21:01AM +0000, Neeraj Kumar Garg wrote:
> Any updates on this below email? My point is do we really need the code which I \
> removed in my patch? I am not able to generate a problematic log now (where I could \
> see that we were continuously scheduling the STA scan) but this segment of code is \
> little problematic. In my understanding, I am not very clear why we need this \
> segment of code. Same piece of code to schedule p2p_scan is already present after \
> handling the STA scan results.

That code to stop station scans sounds like a reasonable thing to do to
act on the last ctrl_iface command. I would like to see a debug log or
clear description of why this causes harm before removing it or at
least a pair of debug logs with the current implementation and then with
the section in _wpa_supplicant_event_scan_results() removed for cases
where you see benefit from removing the skip-scan-results-to-start-P2P
step here.

> [NG] last command issued is fine but STA scan was already successfully completed. \
> We could have easily handled the scan results and schedule the p2p search after \
> handling the STA scan results.

Earlier scan command could result in additional operations like
association and authentication to be started. Those can take quite some
time to complete and wpa_supplicant tries to avoid the extra latency by
skipping that here if a new P2P operation has been initiated.

> [NG] Order is fine. The commands are working fine in any order. SCAN followed by \
> p2p_find or p2p_find followed by SCAN. But in one race condition, once I had seen \
> that we were continuously scheduling the STA scan unnecessarily. My point is which \
> scenario, this particular code is taking care provided that we have the almost same \
> code to schedule p2p_search after handling the scan results.

If you can reproduce this and provide a debug log, I'm obviously fine
with a fix to address such a case. I've yet to see a clear description
on how this could be triggered.

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
HostAP mailing list
HostAP@lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap


[prev in list] [next in list] [prev in thread] [next in thread]