[PATCH] P2P: clear pending_listen_freq when listening is done

[Jouni Malinen]

On Thu, Mar 23, 2023 at 09:18:52AM +0100, Michael Olbrich wrote:
> Usually pending_listen_freq is cleared in p2p_listen_cb() which is called
> the REMAIN_ON_CHANNEL event. So when p2p_listen_end() is called for the
> following CANCEL_REMAIN_ON_CHANNEL event then pending_listen_freq is
> already zero.
> However, with some errors only a CANCEL_REMAIN_ON_CHANNEL is generated and
> pending_listen_freq is never cleared. As a result, listening is never
> started again.

Would you be able to share a debug log showing such a case?
p2p->pending_listen_Freq is reset back to 0 in numerous places and I'd
like to understand what that "some errors" is referring to since it was
not clear what kind of a sequence would be broken without the proposed
change.

> Clear pending_listen_freq in p2p_listen_end() to avoid this.

That feels problematic:

> diff --git a/src/p2p/p2p.c b/src/p2p/p2p.c
>  int p2p_listen_end(struct p2p_data *p2p, unsigned int freq)
>  {
>  	p2p_dbg(p2p, "Driver ended Listen state (freq=%u)", freq);
> +	p2p->pending_listen_freq = 0;
>  	p2p->drv_in_listen = 0;
>  	if (p2p->in_listen)
>  		return 0; /* Internal timeout will trigger the next step */

This is followed by:

        if (p2p->state == P2P_WAIT_PEER_CONNECT && p2p->go_neg_peer &&
            p2p->pending_listen_freq) {
                /*
                 * Better wait a bit if the driver is unable to start
                 * offchannel operation for some reason to continue with
                 * P2P_WAIT_PEER_(IDLE/CONNECT) state transitions.
                 */

Which would become dead code if that proposed change were applied. There
is another use of p2p->pending_listen_freq below in this same function,
so that would be broken as well.
 
-- 
Jouni Malinen                                            PGP id EFC895FA