It is possible for the driver to indicate multiple Probe Request frames
that would be processed in a single loop. If those frames happen to be
from a peer which with we are trying to start GO Negotiation, multiple
timeouts to start GO Negotiation (p2p_go_neg_start) could end up being
scheduled. This would result in confusing burst of multiple GO
Negotiation Request frames being sent once the RX loop finally
concludes. Avoid this by scheduling only a single eloop timeout to
trigger GO Negotiation regardless of how many Probe Request frames from
the peer is received. In addition, make sure this timeout gets canceled
in p2p_deinit().
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
8cee87ab13