Opened 4 years ago

Closed 4 years ago

#1478 closed defect (not a bug)

SAMv3 throws I2P_ERROR instead of DUPLICATED_ID

Reported by: Leon Mergen Owned by: mkvore
Priority: minor Milestone: undecided
Component: apps/SAM Version: 0.9.17
Keywords: protocol error Cc:
Parent Tickets: Sensitive: no

Description

While implementing test cases for an API i'm writing for SAMv3, I was attempting to trigger the 'DUPLICATED_ID' error. As I understand it, this error is thrown when you use the same nickname twice.

However, instead of a DUPLICATED_ID error, a I2P_ERROR with a (debug) message is thrown. The protocol session that illustrates the issue is as follows:

-> SESSION CREATE STYLE=STREAM ID=1be24c9c-c27d-4efd-84bb-ec88fb08beb1 DESTINATION=TRANSIENT SIGNATURE_TYPE=EDDSA_SHA512_ED25519
<- SESSION STATUS RESULT=OK DESTINATION=uSj5TT68wVgjwxYlAkyiQPa~zlbePa3jJu-y2f1RmfpYPyNVUdHpn47QyvE0RVX3-RyZPzWSsuzqHEw0vR-uPpzpePGYatcyGSNKzdhjiyEnvTUd4ujh0IR1571ZHrdiMbB7KclTDLYbcZbRbdVJ3K4sfs0MsEXj6abb6cGzDJXPzaoS~~QuODQCM3J3hag4nsW2QwzktbCYK~O3IzIr5it9tijLBw2czKhi~FOj5R2X8TvYYej7MckuNBM2qDAiuPQAASO81fS6p92nsnv85L2AI7Jl~kVFSMZezQEQjouqMYt1elINDX6ehEGPc-ehMe98YrAC5Lb65rWlHVW9jVkQ2RFY9xoBd9PCOGtJfhxF2gMIc0CqtBJoiZSJ2GdlF5wf8464mNTuUsW-vy6q3H1unm~wXEhuUQfBQNfdU6Vb7rQ4K9a0tpw4ffwyhtuyjerCb2hDQsY~HaJAPGhxvksLApAzaWtbh3hf786zGojzRVG6Q7A8hQ3HopXPj6xNBQAEAAcAAM10opJr7Ql-chbkjfL4IKIoLPxdazEJRZ8cuhK4~ZuVB81mj9JTrTiLItBYtndTgzOuHZgOCvjDPiYOSQ17uEJncQ3xP6WBpRSpFx3mU20Bdyup8ZQ7MeSgGdvjm9aJ-iyqlOz1q7ACbbDVzFqhO~v4jbVUkUiaMLkOyym9MHZhqYQ8z5mK4-W4MZZfdLl1Uqhz20HmafQNMwqz~EejbTnNq6bU79mD8mKC26MsjxYZzm4s4uvX5nHdEReBfLt4kUkm~IQdq5hBGVjQDH9NypPjezWEEGoGBL40icEx6-kBCCwXKtJuU41WUmSzY7ylHm76RxpEt829lZLB8KS5TC8gcEqWQg~dBrcWhh75rV3Fv097heurGcgq8zSMMOa~9g==

(so far so good, now we will re-use the same id)

-> SESSION CREATE STYLE=STREAM ID=1be24c9c-c27d-4efd-84bb-ec88fb08beb1 DESTINATION=TRANSIENT SIGNATURE_TYPE=EDDSA_SHA512_ED25519
<- SESSION STATUS RESULT=I2P_ERROR MESSAGE="Session already exists"

As you can see, the last result is an I2P_ERROR. Per SAMv3 spec, I would expect the following reply:

<- SESSION STATUS RESULT=DUPLICATED_ID

Subtickets

Change History (3)

comment:1 Changed 4 years ago by Leon Mergen

First step is to confirm that my interpretation of the spec is correct. If it is not, what situation would trigger the DUPLICATED_ID response instead?

If it is, I think the patch should be relatively trivial, but we should take into account that this might break implementations that rely on this behavior.

comment:2 Changed 4 years ago by Leon Mergen

Ah, I think I got this wrong. The protocol error raised here is that a session was already created regardless of the nickname id provided?

In that case, it seems like I can provide the same session nickname id twice when I use multiple connections.

comment:3 Changed 4 years ago by Leon Mergen

Resolution: not a bug
Status: newclosed

Problem existed between keyboard and chair. If you reuse the same session id with both connections remaining active, the proper error is thrown.

Note: See TracTickets for help on using tickets.