[PATCH] supplicant: schedule recovery timeout when P2P listen fails
Junyu Lai
junyulai at google.com
Tue Aug 4 00:43:18 PDT 2026
When P2P remain-on-channel (listen) request fails with EBUSY due
to concurrent wlan0 startup scans, the supplicant state machine
clears the pending frequency but fails to schedule a recovery
timeout. As a result, it hangs permanently in the SEARCH state.
Fix this by scheduling a 100 ms recovery timeout when the listen
request fails in p2p_listen_failed, allowing wpa_supplicant to
automatically retry p2p_search() once the driver collision settles.
This issue is reproducible on devices where simultaneous scans on
concurrent interfaces (e.g. station and P2P) are disabled or
restricted in the wireless driver configuration, leading to EBUSY
failures when concurrent active scans are attempted.
The scheduled 100 ms recovery timeout is a state timeout
(p2p_state_timeout) and does not affect the global find timeout
(p2p_find_timeout) registered when p2p_find was initiated. The
global timeout remains active and will still fire to stop the
search when the overall discovery duration expires, ensuring the
supplicant still follows the discovery time constraint.
Signed-off-by: Junyu Lai <junyulai at google.com>
---
src/p2p/p2p.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
index d04802f1..00465fab 100644
--- a/src/p2p/p2p.c
+++ b/src/p2p/p2p.c
@@ -4191,6 +4191,17 @@ void p2p_listen_failed(struct p2p_data *p2p,
unsigned int freq)
p2p_dbg(p2p, "Listen failed on freq=%u", freq);
p2p->pending_listen_freq = 0;
+ p2p->pending_listen_wait_drv = false;
+
+ if (p2p->state == P2P_SEARCH ||
+ p2p->state == P2P_CONNECT_LISTEN ||
+ p2p->state == P2P_WAIT_PEER_CONNECT ||
+ p2p->state == P2P_WAIT_PEER_IDLE ||
+ p2p->state == P2P_INVITE_LISTEN) {
+ p2p_dbg(p2p,
+ "Schedule timeout after listen failure to
continue state machine");
+ p2p_set_timeout(p2p, 0, 100000);
+ }
}
--
2.55.0.571.g244d577d93-goog
More information about the Hostap
mailing list