[PATCH] P2P: Add missing stop_listen call in p2p_state_timeout

[Jouni Malinen]

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
difference..

> > 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