[PATCH] P2P: Add missing stop_listen call in p2p_state_timeout

Jouni Malinen j
Sat Oct 25 11:43:57 PDT 2014

On Fri, Oct 10, 2014 at 07:20:11AM +0000, Musca, Constantin wrote:
> Please look at the following sequence:

> 2738:10-10 02:57:02.480 D/wpa_supplicant( 2570): P2P: Wait for the peer to become ready for GO Negotiation

> 2746:10-10 02:57:02.480 D/wpa_supplicant( 2570): P2P: Go to Listen state while waiting for the peer to become ready for GO Negotiation
> 2764:10-10 02:57:02.494 D/wpa_supplicant( 2570): nl80211: Remain-on-channel cookie 0xffffffffa010a180 for freq=2462 MHz duration=307
> 2767:10-10 02:57:02.495 D/wpa_supplicant( 2570): nl80211: Remain-on-channel event (cancel=0 freq=2462 channel_type=0 duration=921 cookie=0xffffffffa010a180 (match))

Why does the driver increase the ROC duration from the requested 307 ms
to 921 ms (triple it!)? While wpa_supplicant has some buffers to avoid
small differences in the timeout processing between the driver and
internal timers, it is not exactly prepared for such a large

> > diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
> > @@ -3451,6 +3451,7 @@ static void p2p_state_timeout(void *eloop_ctx, void *timeout_ctx)
> >       p2p_dbg(p2p, "Timeout (state=%s)", p2p_state_txt(p2p->state));
> >
> >       p2p->in_listen = 0;
> > +     p2p->cfg->stop_listen(p2p->cfg->cb_ctx);

At least I now understand why this is needed here.. I think I'll apply
this with if (p2p->drv_in_listen) condition and a debug print to make it
clearer what is happening. That said, I would not be surprised if there
are other sequences where driver doing something like this may result in
undesired results.. I added test functionality to allow mac80211_hwsim
test cases to be implemented for this (extra_roc_dur parameter) and one
example test case for this specific case of that happening while waiting
for the peer to become ready for GO Negotiation.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list