orignal
delayed ack is possible
orignal
I need to fix that part
orignal
because I resend whole packet with initial ack block
zzz
ok
orignal
the trouble is network problems there I guess
orignal
I will fix resends later
orignal
SSU2: RelayResponse status code=68
orignal
wtf 68?
orignal
why it can't just send HolePunch instead?
zzz
if alice is already connected to charlie, why are we doing relay?
orignal
it looks like you were stuck with that connection
orignal
because I didn't have it on Alice side
zzz
hmm
orignal
so, if I receive 68 should I just restart a session?
orignal
assumign hole punch already
orignal
it was 5 or 6 attempts with code 68
orignal
I was able to connect only after 15-120 minutes
orignal
15-20
zzz
yeah I see them but dinner time, will investigate in the morning and let you know
orignal
no problem
orignal
please try to find out why the session was not dropped on time
zzz
ok
zzz
I don't see a problem on my side
zzz
looks like you are the one that forgot about the session:
orignal
fine
zzz
07-01 00:21:34.732 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 0 as charlie nonce 1971080285 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:21:46.404 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 3961045171 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:23:47.995 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 3012517303 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:24:44.172 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 212263956 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:27:30.159 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2731266011 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:30:19.605 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2257861679 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:30:41.265 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2505872536 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:31:38.917 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2380069603 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:31:52.730 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2695904708 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:33:45.577 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 2148413251 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:34:41.718 WARN [leTimer2 4/4] r.transport.udp.PacketBuilder2: Sending termination 2 to : [2001:470:1f06:405:0:0:0:2]:29948 cdoFbN IB2 recvAge: 13m sendAge: 13m sendAttemptAge: 13m sendACKAge: 13m lifetime: 13m RTT: 141 RTO: 1000 MTU: 1408 LMTU: 1500 cwin: 5281 acwin: 5281 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 3/0 pkts sent OK/Dup: 2/0 IBM: 0 OBQ: 0 OBL: 0
orignal
the question is
zzz
^^^^ stayed up 13 minutes, inbound to me
orignal
why this session stayed so long
orignal
why 13 minutes?
zzz
vvvvvvv then after that, another successful relay, another 68, stayed up 168 seconds
zzz
07-01 00:37:38.438 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 0 as charlie nonce 439355217 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:39:53.247 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie nonce 1292647942 to bob [2001:470:1f06:6ad:0:0:0:2]:12388 Qreu1M
zzz
07-01 00:40:26.747 WARN [leTimer2 2/4] r.transport.udp.PacketBuilder2: Sending termination 2 to : [2001:470:1f06:405:0:0:0:2]:29948 cdoFbN IB2 recvAge: 167s sendAge: 167s sendAttemptAge: 168s sendACKAge: 167s lifetime: 168s RTT: 142 RTO: 1000 MTU: 1408 LMTU: 1500 cwin: 5281 acwin: 5281 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 3/0 pkts sent OK/Dup: 2/0 IBM: 0 OBQ: 0 OBL: 0
zzz
idle timeout changes based on number of peers
orignal
I forgot for the reason
orignal
because I was restarting
orignal
that's why
orignal
is there a way to restart session?
orignal
in this case
zzz
it's a good question
zzz
since you lose the chacha keys we'd have to start over
orignal
and it was idling for 13 minutes are you sure that HolePunch was still valid?
orignal
I care more about hole punch
zzz
I should ping periodically if I'm firewalled
zzz
maybe, since it's signed, we could "believe" the relay request and tear down the old session. I don't know
zzz
don't you send a destroy when you're restarting?
orignal
well I was restaring due to hmmm ... hardware issue ))
orignal
simply specking hard drive started malfuctioning there
zzz
so a local destroy then ))
orignal
the box has rebooted
orignal
the problem with this box it's being abused all the time because mining
zzz
you sure that's the reason? I got the 2nd relay intro only 12 seconds after the first. You rebooted and restarted i2p in 12 seconds?
orignal
no I'm talking about first one
orignal
when I received 68 after few attempts after restart
zzz
yeah the first one
orignal
and got confused
zzz
07-01 00:21:34.732 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 0 as charlie
zzz
07-01 00:21:46.404 INFO [ handler 1/1] nsport.udp.IntroductionManager: Send relay response 68 as charlie
orignal
so you think I have missed first one or what?
zzz
no, because a session was actually set up between those two
orignal
or you received SessionConfirmed?
zzz
you can see because it expired 13 minutes later
zzz
07-01 00:34:41.718 WARN [leTimer2 4/4] r.transport.udp.PacketBuilder2: Sending termination 2 to : [2001:470:1f06:405:0:0:0:2]:29948 cdoFbN IB2 recvAge: 13m sendAge: 13m sendAttemptAge: 13m sendACKAge: 13m lifetime: 13m
zzz
I wasn't logging handshake, but I must have received session confirmed, yes
orignal
but again why 13 minutes?
zzz
that's when it timed out for me
zzz
doesn't matter if the timeout was 13 seconds. I still would have sent you a 68 after 12 seconds
orignal
maybe ack to session conrirmed was missing
zzz
maybe, but same thing happened twice
orignal
I think I tried it again after 12 seconds
orignal
it's possible
orignal
but they question is what has happened with original session
zzz
and I didn't see any retransmitted session confirmed from you
orignal
and how we can restart
orignal
I will investigate
zzz
ok
orignal
but restart
orignal
if I send a new SessionRequest when I receive 68
orignal
what will happen?
zzz
in SSU 1 I'll replace the old session with the new one. Should work for SSU 2 also but haven't looked to see if it's ever happened
orignal
I think how to handle 68
zzz
we also need to talk about when to work on 'path challenge'
orignal
agree
orignal
also successive relay is still rare
orignal
interesting coincidence
orignal
seem relay works only through 2RRY
orignal
10:56:17@924/info - SSU2: RelayResponse status code=68
orignal
wtf again?
orignal
I have just started the router a minute ago
orignal
I even haven't received HolePunch
orignal
and my that router was offline for more than an hour
zzz
wasn't my router
orignal
68 is Charlie
orignal
and I tried to connect to you
zzz
I'm charlie?
obscuratus
In the context of SSU2, what is "Relay"? Is there somewhere I can read up on it?
zzz
basically the same as in SSU 1 obscuratus see 'introduction' section in i2p-projekt.i2p/en/docs/transport/ssu
obscuratus
zzz: Thanks
obscuratus
Ah, hence the importance of connection time. If the introducer isn't connected, then the hole punch is lost.
orignal
yes, you are
orignal
the question is why 68
zzz
I have not sent any 68 in the last 12 hours
orignal
then any ideas where is might come from?
orignal
maybe Bob did something worng?
zzz
who was the bob?
orignal
not 2RRY for sure