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

[Jithu Jance]

Hi Jouni,

> the
>operation does continue after having transmitted the GO Negotiation
>Response (status=1).

I think this is what I wanted to achieve via the earlier patch. Thanks a
lot for the update.


- Jithu Jance



On Sun, Mar 1, 2015 at 8:05 PM, Jouni Malinen <j at w1.fi> wrote:

> 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
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150302/3e35b0c1/attachment.htm>