#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

orignal if you use ip you should use "address"

zzz test results with STBM disabled: 47% java, 53% i2pd (vs. 28%/72% with STBM enabled)

zlatinb I got as far 3 i2pds talking to a java router yesterday, now deploying i2pds to 3 more containers

zlatinb there were too many "previous hop == next hop" entries in the java log which made it hard to read

zzz2 starting a 24-hour test with 1-hop IB, 0-hop OB, STBM

zzz2 also started coding SSU2 and fixing proposal issues as I go

zlatinb 5 i2pds, 1 java - java is not building exploratory tunnels but builds participating successfully

zlatinb on one of the i2pds the tunnel success build ratio is 5%

zlatinb yet on another it's 70%

R4SAS that must be bypassed with nat=false...

zlatinb cat !$

zlatinb cat .i2pd/i2pd.conf

zlatinb reseed.urls=https://10.0.3.231:8443/

zlatinb floodfill=true

zlatinb host=10.0.3.39

zlatinb nat=false

zlatinb ifname=eth0

zlatinb ifname4=eth0

R4SAS github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/RouterContext.cpp#L93-L98

R4SAS hm, I think somewhere that code was changed

zlatinb I'm on tag 2.40.0

R4SAS I mean earlier

zlatinb hmm, got one to be OK

R4SAS you can try to do it this way: paste.i2pd.xyz/?8c55543977ed3662#9pLBtuQmnbqJfWUw6hhdLWZ5ZhbSMk46LjoWJHKH9sCt

zlatinb s/host=/address4=/ seems to work for now

zlatinb *** bounces all i2pds ***

zlatinb and at least one has 100% tunnel rate :)

R4SAS I know that villain created testnet too

R4SAS but how he done that - idk

R4SAS github.com/l-n-s/testnet.py

R4SAS that's it

R4SAS another: github.com/l-n-s/docker-testnet

zlatinb I got it to work, and java built client tunnels finally

zlatinb It was address4 that did the trick

R4SAS heh

R4SAS 19:27:04 <+R4SAS> address4 = 10.X.X.X │

R4SAS 19:27:06 <+R4SAS> nat = false

zlatinb I got confused and put host=

zlatinb anyway

zlatinb but already have a tunnel test failure from java

R4SAS from both sides?

zlatinb lots of tunnel test failures in i2pd logs, but I'm investigating a java failure now. Also lots of successful tests too

zlatinb nothing on warn level, turning on debug

zlatinb looks like the message gets lost at the first hop

zlatinb 14:32:52@705/ESC[1;34mdebugESC[0m - TransitTunnel: 3787656349->2466389732 created

zlatinb then in java:

zlatinb 2022/02/02 14:35:19.257 DEBUG [JobQueue 5/5] i2p.router.tunnel.pool.TestJob: Sending garlic test #759 of OB client 8WIP: GW KN9o ElG:me.3787656349-->x8-Q EC:3787656349.2466389732-->Nq6X EC:2

zlatinb 466389732.1689515560-->YDst EC:1689515560 exp. Wed Feb 02 14:42:17 GMT 2022 replyMsgID 1820932888 with 3/0 msgs/bytes with 3 consec. failures / IB expl: GW x8-Q EC:4173220792.3295010197-->KN

zlatinb 9o ElG:3295010197.me exp. Wed Feb 02 14:38:49 GMT 2022 replyMsgID 2758099048 with 17/17408 msgs/bytes

zlatinb 2022/02/02 14:35:19.258 DEBUG [JobQueue 5/5] router.tunnel.TunnelDispatcher: dispatch outbound through 3787656349: [GarlicMessage ID: 2086255291 Data: 62 bytes]

zlatinb "2086255" does not appear anywhere in the i2pd debug log

R4SAS certainly

R4SAS because it is failed

R4SAS try to find 2466389732

R4SAS to see where next hop appears

zlatinb only when it's created 3 minutes ago, nowhere else

R4SAS EC:3787656349.2466389732-->Nq6X

R4SAS EC:2466389732.1689515560-->YDst

R4SAS EC:1689515560

zlatinb right, that's the tunnel that was built from java

R4SAS 3787656349->2466389732 message appear on x8-Q?

zlatinb yes, the first thing I pasted: 14:32:52@705/ESC[1;34mdebugESC[0m - TransitTunnel: 3787656349->2466389732 created

R4SAS any logs from Nq6X then?

zlatinb 1 second

R4SAS looks like garlic message decrytion problem can be here (or how it is called, idk)

zlatinb 14:44:05@932/ESC[1;34mdebugESC[0m - Tunnel: Transit tunnel with id 2466389732 expired <-- this is much later in Nq6X

R4SAS that's correct

R4SAS 9 miutes, tunnel marked as expiring

R4SAS ah, not 9, but 11

R4SAS +- some time...

R4SAS but how is it possible

R4SAS OB client 8WIP: 3/0 msgs/bytes with 3 consec. failures

R4SAS IB expl: with 17/17408 msgs/bytes

zlatinb don't know, some tests succeed

R4SAS send failed, but inbound received

zlatinb zzz2: are we reusing replyMessageID's by any chance?

zlatinb for tunnel test messages (type 11) ?

zzz zlatinb, I don't think so

zzz m.setMessageId(ctx.random().nextLong(I2NPMessage.MAX_ID_VALUE));

zlatinb well I'm seeing the same replyMessageID in the logs a lot, but I don't know if it's related to the problem

zlatinb I reproduced it btw in the testnet

zlatinb we're chasing logs now

zzz not sure what you're logging, but maybe you're seeing the same msg as it gets run thru all the selectors?

orignal zzz what epriration time do you set for SSU I2NP messages?

zzz it varies, not a fixed time

zzz depends on the message, and for streaming it depends on the RTO

orignal test message

orignal zlatinb sees "message expired"

orignal in logs

orignal looks like sometimes test fails because i2pd drops this SSU message due to expiration

zzz checking...

zlatinb I need to go afk for ~30 minutes, let me know if you need any experiments in the testnet

zlatinb *** afk ***

orignal I think this is the main cause of the problem

orignal once you have SSU in transports

zzz orignal, 15 seconds

orignal let me check

zzz with any clock skew, that's probably not enough

zzz but of course we're also seeing data messages drop

orignal I use 8

orignal zlatinb tried tests only

zzz do you drop strictly at the expiration or do you allow some "slop"?

orignal also can you test both 1-hop with same OBEP and IBGW?

orignal if (!msg->IsExpired ())

orignal {

orignal m_Handler.PutNextMessage (std::move (msg));

orignal }

orignal else

orignal LogPrint (eLogDebug, "SSU: message expired");

zzz thats not so easy for me to set up

orignal completely

zzz I think almost everywhere we add 60 seconds of "slop"

zzz definitely we do at the IBGW

zzz looking for the OBEP code now

zzz still researching

orignal also zlatinb says Java can't build tunnels wihout SSU

zzz might be a testnet thing, don't know

orignal bascially we wanted to test how it goes through NTCP2 only

orignal just doesn't work

zzz wasn't that long ago I tested ntcp2-only on the live net

orignal idk

zzz looks like we are strict at the OBEP

orignal so you don't check epxiration on SSU level?

zzz not sure, looking

zlatinb *** back ***

zlatinb if the not building with NTCP2 is a testnet thing, I can try allowing only 1 SSU connection

zlatinb I don't know why it's happening tbh

zzz looks like we have a strict check in outbound NTCP2 after it comes out of the queue, nothing in SSU. The main check is in our "OutNetMessagePool"

zzz why are messages expiring in the testnet? I don't get it

orignal that's why we are trying to understand

orignal <zlatinb> ок, y5hS получил сообщение на 152371452, но Nq6X не получил, а в логах: SSU: message expired

zlatinb yes

orignal so message was sent but receving side dropped it

orignal as expired

orignal we suspect it causes the problem

orignal also have you tried to build 1-hop to my router?

zlatinb The "SSU: message expired" was logged in the same second as the tunnel test was initiated. I'm inclined to think it's a timestamp reading/management problem

zlatinb as opposed to message being actually late

orignal but how come?

orignal if it was the same box

zlatinb don't know, LXC containers run on the same kernel so should get the same timestamp

orignal wow

zlatinb so clock skew is unlikely

orignal I see a lot

orignal when I just run

orignal so that's might be a problem

zzz fyi just tried ntcp2-only on live net, no problems

zzz on another router, only about 1% of connected peers have a clock skew between 15 and 60 seconds

orignal let me investigate that message expired issue

orignal brb

zzz return (ts > exp + I2NP_MESSAGE_CLOCK_SKEW) || (ts < exp - 3*I2NP_MESSAGE_CLOCK_SKEW); // check if expired or too far in future

zzz looks like you do have "slop"

orignal yes

orignal 1 minute in one direction

orignal and 3 minutes in another

orignal but just wow

orignal Expired 1643827287198 3170786141000 2049503574

orignal current ts, exp time in msg, diff

R4SAS Mon, 23 Jun 2070 21:55:41 GMT

R4SAS lol

orignal ofc

orignal something strange

orignal *** keeps investigating ***

R4SAS we investigated our code with expiration, it haven't changed for 6 years

R4SAS so that can be that time incorrectly added in java

R4SAS gh died again... :D

zlatinb I can switch to an all-java net and see if the tunnel tests still fail

zlatinb testnet*

zlatinb they should never fail in a testnet unless bugs

R4SAS zlatinb: btw, what about stats between i2pd only?

R4SAS just shutdown i2p

zlatinb ok, restarting with i2pd-only

zlatinb still seeing message expired and tunnel test failed

orignal thanks

orignal will take a look

orignal zzz, do you see these timestamp issues in SSU packets?

orignal I have printed out peers where packets came from

orignal DMul, DnYx, A~7X, PM5C, 287T

orignal only last is i2pd

orignal let me run one more time

zzz I'll turn on some logging and report back tomorrow

orignal nevermid

orignal I see that not only timestamp but whole message is garbage

orignal like message type = 188

orignal so it's my issue somewhere