P2P: Wait 100 ms if driver fails to start listen operation

Some drivers may accept the remain-on-channel command, but instead of
indicating start event for remain-on-channel, just indicate that the
operation has been canceled immediately. This could result in continuous
loop of search/listen states with very limited time to do anything else
in wpa_supplicant if the scan command is also completed quickly (e.g.,
if the driver is unable to scan other channels than the current
operating channel).

As a workaround, do not start the next step (search) in P2P device
discovery if this type of rejection of listen operation is detected.
This gives some more time for wpa_supplicant to handle whatever else
may be needed at to be done at the same time and reduces the amount
of CPU used in a loop that does not really work correctly from the
view point of being discoverable.

Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
intended-for: hostap-1

1 files changed, 12 insertions, 0 deletions

diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
index 8bb84db..2b084e7 100644
--- a/src/p2p/p2p.c
+++ b/src/p2p/p2p.c
@@ -2922,6 +2922,18 @@ int p2p_listen_end(struct p2p_data *p2p, unsigned int freq)
 				"new one");
 			return 1;
 		}
+		if (p2p->pending_listen_freq) {
+			/*
+			 * Better wait a bit if the driver is unable to start
+			 * offchannel operation for some reason. p2p_search()
+			 * will be started from internal timeout.
+			 */
+			wpa_msg(p2p->cfg->msg_ctx, MSG_DEBUG, "P2P: Listen "
+				"operation did not seem to start - delay "
+				"search phase to avoid busy loop");
+			p2p_set_timeout(p2p, 0, 100000);
+			return 1;
+		}
 		p2p_search(p2p);
 		return 1;
 	}