IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/12/13
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
FreeRider
Irc2PGuest12106
Irc2PGuest77585
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon3
eyedeekay_bnc
not_bob_afk
profetikla
shiver_
u5657_1
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 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