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

diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
index 8bb84dbaebece47d6952e19ce081091a370bf979..2b084e7840916aee12f2d1af4766d7298a78fdd7 100644 (file)
--- 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;
        }