[PATCH 1/1] P2P: Clear the discovery state incase of deffered GO Neg response

Jouni Malinen j
Sun Mar 1 06:35:13 PST 2015


On Tue, Aug 12, 2014 at 11:35:19PM +0530, Jithu Jance wrote:
> > Hmm.. This sounds problematic. Wouldn't the change allow anyone to stop
> > P2P discovery simply by sending a GO Neg Req frame to this device?
> 
> That's true. But I am assuming that since there is a connection
> attempt from the peer, there
> would be a user input from the current device side (whether to accept
> the connection or deny
> incoming connection). In the denial context, the discovery state can
> be restarted by a fresh p2p_find.
> But yes, this will block other incoming connect request till upper
> layer/user finishes the action for the previous request. This is just
> a thought. I am not sure whether this is the right approach. Please
> advise.

I don't think this correct behavior. When the operation is initiated by
a peer (e.g., GO Neg Req from unknown peer in this specific case)
instead of some user action on the local device, I'd continue to
previously requested local operation (p2p_listen/p2p_find in this case).

> Actually the p2p_continue_find was not getting invoked in this
> scenario and p2p_state was stuck in
> P2P_SEARCH. so either we need to do p2p_continue_find or come out of
> discovery till we get a user input.
> If you think that we need to continue the discovery state, (P2P_SEARCH
> or LISTEN_ONLY state), I will send
> a patch accordingly.

I'm not sure what the case was in August, but at least now that I added
a new hwsim test case for this both for p2p_listen and p2p_find, the
operation does continue after having transmitted the GO Negotiation
Response (status=1). As such, I'm not sure what else would need to be
changed. Anyway, if you can still see a case where the P2P listen/search
gets stopped unexpectedly, I'd like to see a debug log showing the
sequence that can hit that case.

As far as this patch to clear state on GO Neg Resp failure callback is
concerned, I'm dropping it now since I don't think it is correct thing
to do in that case.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list