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

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?