| Message ID | 1330949387-9489-1-git-send-email-eliad@wizery.com |
|---|---|
| State | Deferred |
| Headers | show |
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?
hi Jouni, On Mon, Mar 5, 2012 at 8:04 PM, Jouni Malinen <j@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 well. e.g.: 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. Eliad.
diff --git a/src/p2p/p2p_go_neg.c b/src/p2p/p2p_go_neg.c index 5216212..d3f6a49 100644 --- a/src/p2p/p2p_go_neg.c +++ b/src/p2p/p2p_go_neg.c @@ -496,6 +496,14 @@ void p2p_process_go_neg_req(struct p2p_data *p2p, const u8 *sa, return; } + if (dev->dialog_token == msg.dialog_token) { + wpa_msg(p2p->cfg->msg_ctx, MSG_DEBUG, + "P2P: Do not reply since dialog token %d " + "was already used", msg.dialog_token); + p2p_parse_free(&msg); + return; + } + go = p2p_go_det(p2p->go_intent, *msg.go_intent); if (go < 0) { wpa_msg(p2p->cfg->msg_ctx, MSG_DEBUG,