<div dir="ltr">Hi Jouni,<div><br></div><div>> the<br>>operation does continue after having transmitted the GO Negotiation<br>>Response (status=1). <br><div class="gmail_extra"><br></div><div class="gmail_extra">I think this is what I wanted to achieve via the earlier patch. Thanks a lot for the update. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>- Jithu Jance</div><div><br></div><div><b><font face="'courier new', monospace"><br></font></b></div></div></div></div>
<br><div class="gmail_quote">On Sun, Mar 1, 2015 at 8:05 PM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tue, Aug 12, 2014 at 11:35:19PM +0530, Jithu Jance wrote:<br>
> > Hmm.. This sounds problematic. Wouldn't the change allow anyone to stop<br>
> > P2P discovery simply by sending a GO Neg Req frame to this device?<br>
><br>
> That's true. But I am assuming that since there is a connection<br>
> attempt from the peer, there<br>
> would be a user input from the current device side (whether to accept<br>
> the connection or deny<br>
> incoming connection). In the denial context, the discovery state can<br>
> be restarted by a fresh p2p_find.<br>
> But yes, this will block other incoming connect request till upper<br>
> layer/user finishes the action for the previous request. This is just<br>
> a thought. I am not sure whether this is the right approach. Please<br>
> advise.<br>
<br>
</span>I don't think this correct behavior. When the operation is initiated by<br>
a peer (e.g., GO Neg Req from unknown peer in this specific case)<br>
instead of some user action on the local device, I'd continue to<br>
previously requested local operation (p2p_listen/p2p_find in this case).<br>
<span class=""><br>
> Actually the p2p_continue_find was not getting invoked in this<br>
> scenario and p2p_state was stuck in<br>
> P2P_SEARCH. so either we need to do p2p_continue_find or come out of<br>
> discovery till we get a user input.<br>
> If you think that we need to continue the discovery state, (P2P_SEARCH<br>
> or LISTEN_ONLY state), I will send<br>
> a patch accordingly.<br>
<br>
</span>I'm not sure what the case was in August, but at least now that I added<br>
a new hwsim test case for this both for p2p_listen and p2p_find, the<br>
operation does continue after having transmitted the GO Negotiation<br>
Response (status=1). As such, I'm not sure what else would need to be<br>
changed. Anyway, if you can still see a case where the P2P listen/search<br>
gets stopped unexpectedly, I'd like to see a debug log showing the<br>
sequence that can hit that case.<br>
<br>
As far as this patch to clear state on GO Neg Resp failure callback is<br>
concerned, I'm dropping it now since I don't think it is correct thing<br>
to do in that case.<br>
<div class=""><div class="h5"><br>
--<br>
Jouni Malinen PGP id EFC895FA<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</div></div></blockquote></div><br></div></div></div>