[PATCH] P2P: ignore neg_req with the last used dialog_token
Mon Mar 5 10:36:00 PST 2012
On Mon, Mar 5, 2012 at 8:04 PM, Jouni Malinen <j at w1.fi> wrote:
> On Mon, Mar 05, 2012 at 02:09:47PM +0200, Eliad Peller wrote:
>> If for some reason we get duplicate negotiation request,
>> the supplicant will generate 2 different responses
>> (with different SSIDs) with the same dialog token.
>> The remote peer will confirm one of them, but it will
>> probably be the wrong one (the first it received,
>> whlie we keep track of the last one).
>> Workaround it but ignoring negotiation requests with
>> the last used dialog_token.
> How do you know that the peer does not use the same dialog token again
> for the next GO Negotiation? Please keep in mind that the peer may be
> using different implementation.. In addition, there could be cases where
> our GO Negotiation Response is lost and peer tries to send GO
> Negotiation Request again. As such, I'm not sure this is really a
> suitable way of working around this.
> Furthermore, I'm not completely sure what exactly you are trying to work
> around. The changing SSID? Didn't commit
> 4458d91554cce6c8a78916701c2701162cbbfad1 already take care of that?
thanks for your detailed reply.
i didn't consider this patch (i tested some older version, and
forward-ported my patch). however, i think that the changing ssid is
just one consequence of this scenario. there could be other issues as
A->B : neg request (dialog_token=1)
A->B neg request (dialog_token=1) (duplicate)
B->A: neg response, A is going to be GO (dialog_token=1)
B->A: neg response, B is going to be GO (dialog_token=1)
i also encountered a (different) case in which the negotiation
confirmation was sent while the dialog_token was already incremented
(in the remote peer). in this case, the sending peer will start the
group, while the receiving peer will reject the neg response (because
the dialog_token is invalid).
how can we avoid such scenario?
i suspect the p2p negotiation spec is a bit broken wrt such issues.
More information about the Hostap