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

orignal Look like you don't like token I use from HolePunch message, because you don't reply to my SessionRequest

zzz yeah I see it in the logs, don't know why... but you should have gotten a retry

zzz investigating...

zzz don't see anything obvious, but I'm not logging the token I sent, only the one I got. will have to update the log msg and restart

orignal so it's token issue?

orignal no, I have gotten nothing

orignal that's a problem

zzz yes token issue

zzz 06-28 14:38:53.322 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 0 as charlie nonce 2417426456 to bob [2a09:7c44:0:0:0:0:0:e9d]:15110 2RRYXk OB2 recvAge: 10m sendAge: 10m sendAttemptAge: 10m sendACKAge: 0ms lifetime: 39m RTT: 18 RTO: 1000 MTU: 1408 LMTU: 1500 cwin: 2919 acwin: 2919 SST: 2560 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 115 pkts rcvd OK/Dup: 112/0 pkts sent OK/Dup:

zzz 121/5 IBM: 0 OBQ: 0 OBL: 0 theyRelayToUsAs: 3814582535 for alice [2001:470:1f06:405:0:0:0:2]:29948 [RouterInfo:

orignal please check if token in HolePunch header and RelayResponse block is the same

zzz 06-28 14:38:53.451 INFO [ handler 1/1] ort.udp.InboundEstablishState2: Invalid token -1217973377808424861 in session request from: /[2001:470:1f06:405:0:0:0:2]:29948

orignal I take on from header

orignal last 8 bytes

orignal *one

zzz no it's after the signature

orignal what's in HolePunch?

orignal I meant last 8 byte of header

orignal 24-32

orignal or it's different token?

zzz I think it's just random, ignore it. that's what the spec says

orignal that's the problem

zzz because the token is part of the relay response block

orignal my point is

zzz ok. that's what the spec says anyway.

orignal if I receive HolePunch I even don't need to process payload

orignal why don't you put token there?

zzz it's a good question

orignal anyway I will fix it

zzz i guess the point was just to send the same relay response block in the hole punch also

orignal yes, but it's for verification only

zzz that's what we decided but it was like two months ago, I don't remember

orignal you don't need it to start session

orignal yes we did

orignal to verify signatures etc.

zzz I didn't do a lot of work about it. We decided to add a token and I did, I didn't think too hard about it

orignal my point is

zzz we can put it in the header too, just like retry, if you want

orignal we need relay response block to verify address

orignal if it matches enpoint HolePunch came from

orignal I can extract it from relay response no problem

orignal Just confused about token field

zzz yup

zzz oh also good job on finding the followon fragment problem. I haven't looked in the logs for it yet

orignal just typo

orignal we will see

orignal more imporntant bug is error code 70

orignal this frag field in RouterInfo breaks everything really

zzz if i2np followon fragments work, we should see much more traffic, tunnels will stay up longer

orignal we will see

orignal I see the problem with retry

orignal will fix

zzz got a followon fragment from xZ9s i2pd

zzz invalid

orignal what exactly wrong?

zzz sec

orignal it's possible

orignal I will check

orignal but it's good that you even receive it now

zzz have you verified it's working? please don't make me your only tester...

zzz 06-29 14:09:04.944 INFO [ handler 1/1] outer.transport.udp.PeerState2: Got FRAGMENT block: 2557150930 fragment 0 len 1381 isLast? false on 5.183.32.144:13039 x

zzz Z9nsA OB2 recvAge: 86s sendAge: 86s sendAttemptAge: 87s sendACKAge: 87s lifetime: 87s RTT: 162 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 5186 acwin: 5186 SST: 52428

zzz 8 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 2 pkts rcvd OK/Dup: 4/0 pkts sent OK/Dup: 2/0 IBM: 0 OBQ: 0 OBL: 0

zzz 06-29 14:09:04.944 ^^^ 1 similar message omitted ^^^

zzz 06-29 14:09:04.944 WARN [ handler 1/1] outer.transport.udp.PeerState2: Message invalid: IB Message: 2557150930 from [Hash: xZ9nsAJAxQ~nrN4HBDco2BG9vwbnsaZ5uGMp

zzz utC7W9g=] completely received with 2139 bytes in 2 fragments lifetime: 0 PeerState: 5.183.32.144:13039 xZ9nsA OB2 recvAge: 86s sendAge: 86s sendAttemptAge: 87s

zzz sendACKAge: 87s lifetime: 87s RTT: 162 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 5186 acwin: 5186 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 2 msgs sent: 2 pk

orignal I check that it's created proeprly

zzz ts rcvd OK/Dup: 5/0 pkts sent OK/Dup: 2/0 IBM: 0 OBQ: 0 OBL: 0

zzz net.i2p.data.i2np.I2NPMessageException: I2NP length in TGM: 2129 but remaining bytes: 2124

zzz Caused by: java.io.IOException: Block 1 type 125 length 19891 at offset 766 runs over frame of size 788

orignal so please exaplain

zzz there's a length problem

orignal length of what? I2NP?

zzz when I reassembled the two fragments

zzz and then the next block was bad too

zzz looking...

orignal where do you have that length?

zzz so it was a tunnel gateway message

zzz the length in the TGM header was 2129, but the remaining bytes in the message was 2124

zzz so you're 5 too short

orignal so you found the problem when tried to process I2NP message. right?

zzz the followon fragment block size must have been wrong also, because the next block was bad too

zzz that's right

zzz and also hit the same problem when I tried to process the next block

orignal worng block size and 5 bytes difference can't be a coincidence ))

orignal let me check

zzz you're off by 5 bytes somewhere

zzz note that the followon fragment block has 5 bytes at the front :)

orignal yes, that's what I mean

orignal let me check

orignal found it ))

orignal let me commit

orignal updating routers

zzz great. you really need to do some more testing on fragmentation and reassembly. it has to be perfect, we can't have any problems

orignal but I did ... with a single blokc

orignal going to write a test but today ))

orignal I copied the code from SSU for it

orignal xZ9s restarted

orignal and I see you connected

orignal 2RRY also updated

zzz got my eye on it, will let you know when I see anything from i2pd

orignal good

orignal I will continues testing this afternoon