P2P: Remove pending p2p-listen radio work on stopping listen

Some kind of race condition seemed to be hit at least in test sequence
"p2p_ext_vendor_elem_invitation pasn_comeback_after_0_sae" where the P2P
invitation response could have been received just after having scheduled
a new p2p-listen radio work, but before that work had been started. In
the case of accepted invitation, this could result in unnecessary extra
delay when that p2p-listen work ended up getting started at the exact
time that the local device was starting GO.

Avoid this race condition by removing the pending p2p-listen radio work
when P2P listen is stopped.

Signed-off-by: Jouni Malinen <j@w1.fi>

diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
index e60beda72ba027e267a49364ed7f718b9e9ed262..de597cbb0531be871cdacf3b8f6e38309329cc18 100644 (file)
--- a/wpa_supplicant/p2p_supplicant.c
+++ b/wpa_supplicant/p2p_supplicant.c
@@ -2796,6 +2796,12 @@ static void wpas_stop_listen(void *ctx)
                wpa_drv_probe_req_report(wpa_s, 0);
 
        wpas_p2p_listen_work_done(wpa_s);
+
+       if (radio_work_pending(wpa_s, "p2p-listen")) {
+               wpa_printf(MSG_DEBUG,
+                          "P2P: p2p-listen is still pending - remove it");
+               radio_remove_works(wpa_s, "p2p-listen", 0);
+       }
 }