zzz
rats, I still have packet size problems, I see errors trying to send 1503 byte packets
dr|z3d
do you need to add something to the debug logs to see how exactly you're arriving at that size?
zzz
no, I have the logs, I just need to check in some other stuff first to make way
zzz
here's one where I tried to fit 7! fragments in one packet
zzz
Size is 1475 for 1475 byte pkt with 95.165.99.143:4568 priority=200 data size 1443 pkt size 1503 MTU 1500 Fragments:
zzz
[Fragment 0 (296 bytes) of OB Message 1284603767 seq 836 type 19 size 296 volleys: 1 lifetime: 1358 unacked],
zzz
[Fragment 0 (182 bytes) of OB Message 2961834546 seq 837 type 19 size 182 volleys: 1 lifetime: 1357 unacked],
zzz
[Fragment 0 (176 bytes) of OB Message 3656396380 seq 838 type 19 size 176 volleys: 1 lifetime: 1357 unacked],
zzz
[Fragment 0 (169 bytes) of OB Message 4479473 seq 839 type 19 size 169 volleys: 1 lifetime: 1357 unacked],
zzz
[Fragment 0 (165 bytes) of OB Message 468173920 seq 840 type 19 size 165 volleys: 1 lifetime: 1357 unacked],
zzz
[Fragment 0 (224 bytes) of OB Message 3220947046 seq 841 type 19 size 224 volleys: 1 lifetime: 1357 unacked],
zzz
[Fragment 0 (210 bytes) of OB Message 1000391246 seq 843 type 19 size 210 volleys: 1 lifetime: 1152 unacked]
dr|z3d
ambitious!
zzz
unfortunately this is in the logs from 2 weeks ago, missed it
zzz
ok I think I found it, dumb mistake, will soak it for a day
zzz
next problem:
zzz
08-25 02:30:12.829 INFO [ handler 1/1] ort.udp.InboundEstablishState2: Invalid token 0 in session request from: /213.221.12.254:16095
zzz
^^ from i2pd
zzz
oh I see why. just before:
zzz
08-25 02:30:12.594 WARN [ handler 1/1] sport.udp.EstablishmentManager: Corrupt Session/Token Request from: 213.221.12.254:16095
zzz
java.security.GeneralSecurityException: Skew exceeded in Session/Token Request: 27007594
zzz
orignal,
zzz
<zzz> next problem:
zzz
<zzz> 08-25 02:30:12.829 INFO [ handler 1/1] ort.udp.InboundEstablishState2: Invalid token 0 in session request from: /213.221.12.254:16095
zzz
<zzz> ^^ from i2pd
zzz
<zzz> oh I see why. just before:
zzz
<zzz> 08-25 02:30:12.594 WARN [ handler 1/1] sport.udp.EstablishmentManager: Corrupt Session/Token Request from: 213.221.12.254:16095
zzz
<zzz> java.security.GeneralSecurityException: Skew exceeded in Session/Token Request: 27007594
zzz
If token request is too skewed, I send a retry with a zero token and a termination block. Please handle
dr|z3d
dunno if this is a legacy issue, but I've been forwarded the following error:
dr|z3d
java.lang.IllegalStateException: Bad state for Retry Sent: IB_STATE_RETRY_SENT at net.i2p.router.transport.udp.InboundEstablishState2.retryPacketSent(InboundEstablishState2.java:477) at net.i2p.router.transport.udp.PacketBuilder2.buildRetryPacket(PacketBuilder2.java:461) at net.i2p.router.transport.udp.InboundEstablishState2.receiveSessionRequestAfterRetry(InboundEstablishState2.java:540)
zzz
that's the 2nd-order error from the above zero token thing, will fix shortly
dr|z3d
at net.i2p.router.transport.udp.EstablishmentManager.receiveSessionOrTokenRequest(EstablishmentManager.java:704) at net.i2p.router.transport.udp.PacketHandler.receiveSSU2Packet(PacketHandler.java:919)
dr|z3d
roger that
zzz
please thank the reporter for me :)
dr|z3d
your gratitude has been duly conveyed :)
orignal
what?
orignal
maybe somebody try to connect using SSU1?
zzz
no.
zzz
If token request is too skewed, I send a retry with a zero token and a termination block.
zzz
you should interpret a zero token and/or terminatino block as a rejection
orignal
what's the scenario again?
orignal
I send session request or token request?
zzz
token request with a datetime block too skewed
orignal
ok. so clock skew
orignal
and what you do?
zzz
I reply with retry, token = 0, and termination block
zzz
you reply with session request with zero token (((
orignal
and no dattime block?
orignal
because I don't check it
zzz
retry should have datetime block but I'll double check
orignal
why don't you send datetime?
orignal
it would let me adjust clock
zzz
verified, retry does contain datetime block
zzz
you should interpret a zero token and/or termination block in the retry as a rejection... do not send a session request
orignal
so if I receive zero token, should I resend token request?
orignal
because I know clock offset now
orignal
anyway, let me add this check
zzz
sure, but maybe should create new session ids? I may treat the old session id as "dead"
orignal
fine
orignal
didn't know you reply with zero token
orignal
do I have to?
orignal
or I can send datetime and termination only?
zzz
and of course it depends if you adjusted your clock... you should check termination block for reason
zzz
of course, it might be me that has the bad clock
orignal
I adjust clock based on datetime block
zzz
yeah but you should only adjust if you're sure you are the one that's wrong...
orignal
let me check that part
orignal
I know
orignal
I don't adjust immediately
orignal
there is some logic
zzz
I don't think you _have_ to set the token to 0, as long as it has a termination block
orignal
let me check if even check datetime for in tokenrequest
zzz
yeah it's good to do it there because the session request is much more expensive
orignal
will add this check
zzz
2% SSU2 already paying off... I found and fixed a packet length bug today too
orignal
is it good or not?
orignal
HidUser0 said today he was able to connect to I2P even without internet
orignal
because TCP didn't work but UDP did
zzz
is what good?
orignal
2%
zzz
seems to be enough to find more problems, I guess
zzz
but only 20% of network has updated so far, so there will be more
orignal
I don't see any SSU2 issues so far
orignal
some issue about symmetric NAT
orignal
but I think it's not a real issue
zzz
great. only minor things so far
zzz
I checked in my connection migration code
orignal
people see symmetric NAT error too often
dr|z3d
zzz: this looks like an i2p+ specific issue relating to refusing to accept K or L tier RI's published over 4 hours ago, so it's probably out of scope for trunk, but still.. cake.i2p/view/PNRlSSl9CR_MfzkapSakN7f2unneZoqHVDofatarf_05kn5LqY47/payloaderror
dr|z3d
I think I'll just put the error behind a if (!e.toString().contains("RouterInfo store fail")) and be done with it, unless there's a specific issue with that?