#i2p-dev (irc2p) | 2.8.0-2 | ACTION REQUIRED git.idk.i2p account deletion http://i2pforum.i2p/viewtopic.php?t=1312 | Upcoming reviews Tuesdays 8 PM UTC #ls2: prop. 163 Mar. 4; prop 169 Mar. 18; prop. 167 Apr 1

zzz <radakayot> from the ssu2 spec: "After sending or receiving a Termination block, the session should enter the closing phase for some maximum period of time TBD."

zzz <radakayot> is this timeout decided?

zzz <zzz> I have 2 minutes

zzz <zzz> see PeerStateDestroyed.java

radakayot thank you, i did not receive that.

radakayot what about the hole punches?

zzz I'm redacting it and will put it here since PM seems to lead to me dying for some reason

radakayot interesting, i'm using HexChat, no custom modifications. only DCC is disabled.

zzz here goes

zzz 02/18 13:52:11.712 WARN [ handler 1/1] sport.udp.EstablishmentManager: Hole punch source mismatch on OES2

zzz xxx xxxxxxx lifetime: 86ms Rcv ID: 8889754201701000687 Send ID: 4280349099750512666 Token: 0 OB_STATE_PENDING_INTRO

zzz Introducers: {[Hash: 4HQy1z7fDTaPYgFM-TyGGWgZ9rpDdvGECJ2QMu9zBVw=]=INTRO_STATE_SUCCESS, [Hash: z9Xx4lJZqiDOlQB3ziibOySoTYQETFepwyPSJluIffc=]=INTRO_STATE_INIT, [Hash: qC6wz-DhAcLuLizsM-xTpjeU7uf1JWtzXp1RAoU9K5U=]=INTRO_STATE_INIT}

zzz resp. block: xxx:17128 rcvd. from: xxx:12511

zzz EOT

zzz hopefully I'm still alive

radakayot ACK

zzz woot ))

radakayot :) is that my router?

zzz yes the xxx is your router and IP

radakayot is timestamp GMT?

zzz no its UTC+1

radakayot checking...

zzz I have a few more in last couple days, not a one-off

zzz you understand the complaint?

radakayot could you send me the most recent one if it's okay?

radakayot yes, source connection id does not match in hole punch.

radakayot right?

zzz no

zzz the port number

zzz doesn't match

radakayot oh i misunderstand then, please explain.

radakayot oh, now i see.

radakayot i know where i did wrong.

radakayot thank you zzz, stopped the router and i'll fix it asap.

zzz here's the last one

zzz 02/20 03:13:26.644 WARN Hole punch source mismatch resp. block: xxx:29479 rcvd. from: xxx:62596

radakayot thank you zzz. is there any other weird behaviours?

zzz one yesterday where I didn't get a response to retry

zzz 02/19 05:16:21.636 WARN [ Establisher] sport.udp.EstablishmentManager: Expired: IES2 xxx:1530 lifetime: 5s Rcv ID: -1079672187406695513 Send ID: -4961237517840536014 Token: -224035055833197581 IB_STATE_RETRY_SENT

zzz 02/19 05:25:46.672 WARN [ Establisher] sport.udp.EstablishmentManager: Expired: IES2 xxx:1530 lifetime: 5s Rcv ID: -5349479427665209496 Send ID: 6609359302848844679 Token: -1446695897060023743 IB_STATE_RETRY_SENT

zzz 02/19 05:29:48.605 WARN [ handler 1/1] sport.udp.EstablishmentManager: Send immediate termination 11 on type 10 to: xxx:1530

zzz one fromn a month ago, haven't seen since:

zzz 01/19 20:35:06.627 WARN [ handler 1/1] nsport.udp.IntroductionManager: Signer RI not found

radakayot it's probably aead verification fail because of intro key mismatch. i close the connection directly.

zzz seems like your port # is all over the place, I don't know if that's your firewall doing that, or you're pretending to be firewalled and it's you, or you're changing every restart, or what

radakayot yes, i restart when i do changes and port randomises.

radakayot i could make it static between restarts.

radakayot is my behaviour correct about immediately stop responding in this case?

zzz you might want to stick between 9000 and 32000 or so, I forget the exact range, to not stand out

zzz persisting your intro key across restarts would also help

zzz stop responding in what case?

radakayot AEAD verification fail in TokenRequest or SessionRequest.

zzz if it fails, it fails, of course you can't respond if you can't decrypt it

zzz but you can't stop responding to good packets, as we discussed, packet injection attacks

radakayot got it, zzz.

radakayot FIN

zzz chasing tunnel test failures

zzz 02/20 10:56:31.400 DEBUG [JobQueue 3/4] i2p.router.tunnel.pool.TestJob: Sending garlic test #991 msg ID: 1560326408 of OB client

zzz 02/20 10:56:32.016 WARN [ handler 1/1] .message.GarlicMessageReceiver: Failed to decrypt [GarlicMessage ID: 1560326408 Data: 54 bytes]

zzz am I on the wrong SKM or what...

zzz hot on the trail...

orignal huh? don't you encypt one for yourself?

zzz yeah but I botched it. researching now how long it's been broken

zzz 13 IB client

zzz 31 IB expl:

zzz 84 OB client

zzz 36 OB expl:

zzz broken for OB client tunnels

zzz ha. not me.

zzz commit bee407c6a184499b56cf656b5a7fbbfd225b1898

zzz Author: eyedeekay <idki2p@i2pmail.org>

zzz Date: Tue Mar 26 09:48:25 2024

zzz CI: Fix job names for maven build tests, Router: Refactor exploratory message filter, refactor tunnel tests

eyedeekay Oh jeez sorry, why was I touching that... I'll go back and look at it to see what I did

zzz took me about a week to chase it down

zzz haven't tested the fix yet but I'm pretty sure

eyedeekay I think I remember this, was this might have been when we were talking about garlic messages getting confused about subDbs and found that there were a couple messages that should have been denied by the spec that weren't?

eyedeekay \/was//

orignal so you fail good tunnels without reason and create new one?

zzz eyedeekay, this was checked in a week before the 2.5.1 release; it clearly didn't get enough testing

zzz as tests of OB client tunnels fail 100% of the time

zzz previously we tested client tunnels with a paired expl. tunnel

zzz your change was to always test client with paired client

zzz so for testing OB client, you now have to register the tag with the client SKM, not the router SKM

zzz so it can't ever be decrypted

orignal is this a reason for abnnomal number of transit tunnels?

zzz probably not too much

zzz we require several failed tests in a row

zzz yeah eyedeekay proven:

zzz 02/20 13:50:32.941 DEBUG [JobQueue 2/4] i2p.router.tunnel.pool.TestJob: register tag with router test #190

zzz 02/20 13:50:32.941 DEBUG [JobQueue 2/4] i2p.router.tunnel.pool.TestJob: test #190 key: [SessionKey: ZGjpZZ5wmXt0smLEAJBNHbPLTPUJR~MeGbm9chzFlvM=] tag: [RatchetSessionTag: otAw0VEtmEE=] len: 81

zzz 02/20 13:50:32.941 DEBUG [JobQueue 2/4] i2p.router.tunnel.pool.TestJob: Sending garlic test #190 msg ID: 250631150 of OB client

zzz 02/20 13:50:33.271 WARN [P reader 2/4] .message.GarlicMessageReceiver: Failed to decrypt [GarlicMessage ID: 250631150 Data: 61 bytes]

zzz 02/20 13:50:56.712 DEBUG [JobQueue 4/4] i2p.router.tunnel.pool.TestJob: Tunnel test #190 timeout: found? false

zzz 02/20 13:50:56.712 WARN [JobQueue 4/4] i2p.router.tunnel.pool.TestJob: Tunnel test #190 failed in 23771ms: OB client

zzz tag was registered with router but test sent to client

eyedeekay crap. Sorry, I think I understand how I mixed that up but that's a pretty self-defeating mistake for me to make

orignal ha. I had the same issue

zzz my guess at a postmortem: not enough testing, too late in release cycle

orignal that tag must be add to destination rather than router

zzz yup

zzz so eyedeekay changed the OB client paired tunnel from IB expl. to IB client but didn't change where he stored the ratchet tag

zzz lets give the fix a test here and see how it goes

zzz ok looks like we'll fail a tunnel after 4 consecutive test failures

zzz 40 seconds each

zzz so that means an OB client tunnel only lasts 160 sec instead of 600

zzz or 1/4 as long.

zzz but assuming half of tunnels are expl and half client

orignal how?

orignal you always have few dests per router

zzz um, no we dont

zzz they're mostly close-on-idle or shared clients

zzz even so, this looks like it could be causing an excess of about 75% of total network-wide tunnel count

orignal I don't understand

orignal your router has only one exploratory pool

zzz for every OB client tunnel, we build 4 every 10 minutes instead of one

orignal and every cleint dest has own tunnels

orignal that I undersand

orignal I don't understand this part

orignal <zzz> but assuming half of tunnels are expl and half client

orignal you always have less expl tunnel than client

zzz not true

orignal then please explain

orignal it's rare that you have only one dest per rouuter

zzz our default install setup is:

zzz one destination for 'shared clients', configured to reduce-on-idle to 1 tunnel

orignal right, same here

orignal we also have another dest for proxies

zzz so that's it. 2 exploratory tunnels, one client tunnel

orignal do your porxy sit on shared dest with 1 tunnel?

orignal *proxy

zzz anyway, this one bug could be doubling the number of tunnels in the network

zzz yes

eyedeekay holy moley

orignal but it's shit

orignal if a user has to access to all eepiste through signle tunnel

orignal how about IB?

zzz this is on idle

orignal if OB-IB pair fails you don't know who to blame

zzz on activity ig builds more tunnels

zzz *it

orignal and they get failed right a way

orignal well after 160 secs

zzz actually on further thought, I don't think there's much impact

zzz first of all, looking at the graph, we've never had as many tunnels inthe net as we had in April '24

zzz although that was at the end of the attacks

zzz but mainly, it's because it only fails if the OB tunnel was the "tested" tunnel

zzz if we're testing an IB tunnel and the OB tunnel was the "paired" tunnel, it works

zzz so we'd have to be pretty unlucky to have four tests of a OB tunnel in a row without a test using it as a "paired" tunnel

zzz so we're unlikely to fail it

zzz graph: cake.i2p/file/vBrxC6eM20_KTjc15EM9ZUtfkM0IkSwWKSiXAyBqV_lF6hgkX9Ly/tunnel.participatingTunnels.60m-365-0-2.png

eyedeekay I'm glad it's not as bad as it could be but still sorry about the mistake

zzz fix looks good:

zzz 5 IB client

zzz 25 IB expl:

zzz 5 OB client

zzz 15 OB expl:

zzz those are fail counts

zzz still seeing a couple failures on expl. because the tag expired

zzz 02/20 14:58:44.445 DEBUG [JobQueue 1/1] i2p.router.tunnel.pool.TestJob: Sending garlic test #545 msg ID: 484679198 of OB expl

zzz 02/20 14:59:29.389 WARN [ handler 1/1] .message.GarlicMessageReceiver: Failed to decrypt [GarlicMessage ID: 484679198 Data: 63 bytes]

zzz 45 seconds !!!