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