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

[Jouni Malinen]

On Wed, Oct 24, 2012 at 10:10:23AM +0000, Neeraj Kumar Garg wrote:
> If STA scan is issued by UI/application (even after STA connection is made) and then immediately, if we issue p2p_find, p2p_search will get delayed. Upon completion of STA scan, we will check for p2p_search if pending. Since p2p_search is pending, p2p_search will be issued. Upon return of p2p_search successful, supplicant will then unnecessarily schedules a STA scan again. At this time, supplicant will also ignore the received scan results. Now once p2p_search will be over, it will check if STA scan is pending. And then it will issue a STA scan. Upon getting STA scan results, we will again check if p2p_search is pending. And after scheduling the p2p_search successfully, again we will issue a STA scan.

The design here tries to follow the last command issued and if the upper
layers in the system request something like that more or less
concurrently, they should be prepared to see not exactly optimal use of
scans..

> I am not sure, what is the intent of checking for p2p_search possibility after receiving the scan_results. We can let the supplicant, process the STA scan_results. And then after that, we already have a check for scheduling the p2p_search after wpa_supplicant_event_scan_results() is completed.

I'm not completely sure I understood. Would you be able to send a
wpa_supplicant debug logs showing the behavior before and after your
patch?

> If the code (removed in the below patch) is to take care of STA connection scenario, then once the STA connection is successful, we will schedule the p2p_search from that context.

There were number of changes in the area of how to handle concurrent P2P
and non-P2P station operations. I'm somewhat hesitant to remove this
part without first fully understanding the effects this have for all the
different concurrent sequences since it would partially revert number of
commits that addressed issues with managing the concurrent requests for
scanning.

The design goal here is to have main focus on cases that happen without
conflicting ctrl_iface commands (e.g., P2P_FIND immediately after SCAN)
and to make sure that those conflicting cases go through eventually,
even if not in ideal order.

-- 
Jouni Malinen                                            PGP id EFC895FA