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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
