[PATCH] supplicant: schedule recovery timeout when P2P listen fails

[Jouni Malinen]

On Tue, Aug 04, 2026 at 03:43:18PM +0800, Junyu Lai wrote:
> 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.

Thanks, applied.
 
-- 
Jouni Malinen                                            PGP id EFC895FA