@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Hikari
Irc2PGuest23894
Irc2PGuest67835
Leopold
Minogami
Onn4l7h
Onn4|7h
T3s|4_
anon
eyedeekay_bnc
idk
j6
not_bob_afk
profetikla
qend-irc2p
u5657
x74a6
zzz
orignal, new problem for today:
zzz
i2pd 0.9.56 Alice, I am Bob, handshake: Alice is changing dest conn id in header after I send a retry. Example:
zzz
12-13 13:49:44.196 WARN [ handler 1/1] er.transport.udp.PacketHandler: Bad Dest Conn id Handshake header destID 6542112049952772920 pkt num 0 type 0 version 2 netID 2 srcID -9012272345064721035 token 5093071576529124921 key i7QLXjzSF3hCOXac~bh7Pg~PhOIE8Sykis~72rG9fyo= on IES2 178.57.69.35:28497 lifetime: 2767ms Rcv ID: -4493487524682866584 Send ID: -9012272345064721035 IB_STATE_RETRY_SENT
zzz
note the recv conn id did not change
orignal
I will check
orignal
it is not in long header?
orignal
*one
orignal
it shoudn't
orignal
I generate destid and sourceid when create a connection
orignal
maybe it's new one?
orignal
how about token?
orignal
do you reply to token request or session request?
zzz
not sure, I'll have to check
zzz
looking...
orignal
because there are two possibilitues
orignal
basically I'm worndering what causes this retry
zzz
It's mostly session requests, but there are some token requests
orignal
which one mistmatches?
orignal
dest or source?
orignal
I'm thinking maybe it's decyption issue
orignal
that's why I'm asking about token
zzz
dest
zzz
here's another example, with both the original sess. request and the second one, same source id, different dest id
zzz
12-13 21:17:40.596 DEBUG [ handler 1/1] ort.udp.InboundEstablishState2: New IES2 51.83.230.80:61441 lifetime: 0ms Rcv ID: -4368186653325883384 Send ID: -6236681524773995585 Token: -2625002938517811656 IB_STATE_REQUEST_BAD_TOKEN_RECEIVED
zzz
12-13 21:17:40.628 WARN [ handler 1/1] er.transport.udp.PacketHandler: Bad Dest Conn id Handshake header destID 774070662612572595 pkt num 0 type 0 version 2 netID 2 srcID -6236681524773995585 token -2625002938517811656 key l7gdEil272ANRFuu6ld~BhD4G3j75voaFvVLyacCXV8= on IES2 51.83.230.80:61441 lifetime: 32ms Rcv ID: -4368186653325883384 Send ID: -6236681524773995585 Token: -2625002938517811656 IB_STATE_RETRY_SENT
orignal
but why do you think it's the same session if deifferent destid?
orignal
destid is first 8 bytes, right?
zzz
because my primary lookup is still by IP/port, until I get rid of SSU 1
zzz
right, first 8 bytes
orignal
then what let you think it's still the same session rather than new one?
orignal
if connid is different
orignal
plus couldn't it be the same 7 bytes payload issue
orignal
e.g. just wrong nonce for encryption
zzz
because it's from the right ip/port, 134 ms after I got the first session request, and it's the same source ID, and the right token
zzz
the only thing different is the dest conn ID
orignal
do you know the length?
orignal
connID ^= CreateHeaderMask (i2p::context.GetSSU2IntroKey (), buf + (len - 24));
orignal
it's that place that required 24 bytes payload
zzz
no, it's not the 7-byte payload issue. these are valid 88+ byte packets
orignal
I will inverstigate
zzz
I don't have the length logged, but if it was < 88 it wouldn't get this far
orignal
it's definitly encryption issue
orignal
because I don't change destid
zzz
ok. FYI the rest of the header looks right
zzz
thanks