[PATCH] P2P:Remove scheduling of p2p scan without handling the STA scan results

Jouni Malinen j at w1.fi
Tue Dec 25 05:55:56 EST 2012


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


More information about the HostAP mailing list