#ls2 (irc2p) | #ls2 proposal review channel

orignal when you say that destid is wrong what extacly it doesn't match?

orignal one you send in Retry before token or one that somes in my original SessionRequest?

orignal I think that's the source of the problem

orignal becuase I ignore one from Retry message

dr|z3d SSU error for you, zzz:

dr|z3d ERROR […DPPktPusher] …udp.PacketPusher: SSU Output Queue Error

dr|z3d java.lang.IndexOutOfBoundsException: Shift too big: 5842

dr|z3d at net.i2p.router.transport.udp.SSU2Bitfield.set(SSU2Bitfield.java:78)

dr|z3d at net.i2p.router.transport.udp.PacketBuilder2.buildPacket(PacketBuilder2.java:309)

dr|z3d at net.i2p.router.transport.udp.PacketBuilder2.buildSessionDestroyPacket(PacketBuilder2.java:375)

dr|z3d at net.i2p.router.transport.udp.UDPTransport.sendDestroy(UDPTransport.java:2266)

dr|z3d at net.i2p.router.transport.udp.UDPTransport.failed(UDPTransport.java:3371)

dr|z3d at net.i2p.router.transport.udp.UDPTransport.failed(UDPTransport.java:3346)

dr|z3d at net.i2p.router.transport.udp.PeerState.finishMessages(PeerState.java:1585)

dr|z3d at net.i2p.router.transport.udp.PeerState2.finishMessages(PeerState2.java:235)

dr|z3d at net.i2p.router.transport.udp.OutboundMessageFragments.getNextVolley(OutboundMessageFragments.java:298)

dr|z3d at net.i2p.router.transport.udp.PacketPusher.run(PacketPusher.java:41)

dr|z3d at java.base/java.lang.Thread.run(Thread.java:1589)

dr|z3d at net.i2p.util.I2PThread.run(I2PThread.java:103)

dr|z3d and what looks like a related error:

dr|z3d CRIT […eTimer2 4/4] …til.SimpleTimer2: SimpleTimer2: Timed task net.i2p.router.transport.udp.UDPTransport$ExpirePeerEvent@7f004a3e exited unexpectedly, please report

dr|z3d java.lang.IndexOutOfBoundsException: Shift too big: 5858

dr|z3d at net.i2p.router.transport.udp.SSU2Bitfield.set(SSU2Bitfield.java:78)

dr|z3d at net.i2p.router.transport.udp.PacketBuilder2.buildPacket(PacketBuilder2.java:309)

dr|z3d at net.i2p.router.transport.udp.PacketBuilder2.buildSessionDestroyPacket(PacketBuilder2.java:375)

dr|z3d at net.i2p.router.transport.udp.UDPTransport.sendDestroy(UDPTransport.java:2266)

dr|z3d at net.i2p.router.transport.udp.UDPTransport$ExpirePeerEvent.timeReached(UDPTransport.java:3776)

dr|z3d at net.i2p.util.SimpleTimer2$TimedEvent.run2(SimpleTimer2.java:501)

dr|z3d at net.i2p.util.SimpleTimer2$TimedEvent.run(SimpleTimer2.java:440)

dr|z3d at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)

dr|z3d at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)

dr|z3d at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)

dr|z3d at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

dr|z3d at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

dr|z3d at java.base/java.lang.Thread.run(Thread.java:1589)

zzz orignal, the destids in your first and second session requests are different

dr|z3d zzz: did you catch the java.lang.IndexOutOfBoundsException: Shift too big stacktraces I posted earlier?

zzz yeah thx dr|z3d, I need to bulletproof that

dr|z3d ok, np

dr|z3d bloom filter issue appears to have mostly disappeared now I've set max b/w in FIFO refiller higher.

dr|z3d was seeing a lot of hostile packets (too far in past) yesterday on the SC router, so hostile packets now elicit a short temp here, not seeing them today.

dr|z3d you may also be interested to learn that ~40MB/s is about as much as you can squeeze from a quad core @ 3.9MHz (Ryzen 9).

zzz oh, so you weren't on m=28 after all?

dr|z3d in BMProcessor?

zzz no, in ivv

dr|z3d IVV, 28.

dr|z3d I tried bumping it higher, everything went to shit :)

dr|z3d I've just bumped up the max bandwidth the router can push in the FIFO b/w refiller.

zzz ok

dr|z3d public static final int MAX_OUTBOUND_BANDWIDTH = SystemVersion.isSlow() || SystemVersion.getCores() == 1 ? 16384 :

zzz be careful with your tinkering, sometimes you lose your mind, which kinda matters since you're running the outproxies

dr|z3d SystemVersion.getCores() < 3 || SystemVersion.getMaxMemory() < 1024*1024*1024 ? 32768 :

dr|z3d SystemVersion.getCores() < 6 || SystemVersion.getMaxMemory() < 3072*1024*1024 ? 65536 :

dr|z3d 131072;

dr|z3d sure, valid point. potentially dodgy tweaks get a bake in period before they're made generally available.

zzz here's where you lost the script. be careful and don't be tweaking everything for fun, sometimes you break stuff gitlab.com/i2pplus/I2P.Plus/-/commit/08b9bc50c02a7a1243ea3339f06b31900f00f173

dr|z3d ah, / instead of *

dr|z3d thanks for pointing that out.

dr|z3d yeah, hmm. not great.

dr|z3d if (maxMemory < 32*1024*1024) {

dr|z3d nr = nw = 1;

dr|z3d } else if (maxMemory < 64*1024*1024) {

dr|z3d that looks right?

dr|z3d actually, it looks like getMaxMemory() is already doing the multiplication.

dr|z3d and I'm not even sure testing for less than 32 or 64 is even necessary. those values look way too low.

zzz getMaxMemory() is in bytes

dr|z3d yeah got it now, thanks. must have been over-tired when I messed with that one :|

zzz np, saw it a while ago, just forgot

dr|z3d but the question remains, do we really need to check for < 32 or 64 MB?

dr|z3d that seems pretty much obsolete.

zzz android

dr|z3d why not SystemVersion.isAndroid() then instead?

zzz or old rasp pi maybe

dr|z3d ok, fair enough. corner cases, but ok.

orignal thanks

orignal does it happen every tme of randomly?

orignal *or

zzz hard to say, not happening with java alice, I see it about 10 times per hour on a low-bandwidth router

orignal can you try to hit 2RRY?

orignal never mind

orignal i2pd must be alice

orignal do you think i2pd can't connect to Java router at all?

zzz seems like it's mostly after session request and retry

zzz not sure if token request and retry is affected

zzz and of course without retry should be working fine

orignal but you said also after token request

orignal that's important

orignal token request and retry is more frequent scenrio

orignal and my question is

orignal why sessionrequest->token even happens

orignal sorry retry

orignal it means I have your non-expired token on my side

orignal and you don't have it anymore

zzz because I limit the cache size for tokens

zzz would you please try to reproduce, either on the alice or bob side?

orignal I will try with you router

orignal a little later

orignal it's easy

orignal send sessionrequest with shitty token and get retry back

zzz a quick check and log message should allow you to confirm it

zzz thank you

orignal is you ruter still online?

zzz yes, but it has token fixes so you won't get retry as often. other java routers without the fixes send a lot more retries

orignal but if I send shitty token I should get Retry back?

zzz yes, of course

orignal that's enough to reproduce

dr|z3d another interesting error for you, zzz...

dr|z3d [NTCPPumper ] …ntcp.EventPumper: Error in the event pumper

dr|z3d java.lang.NullPointerException: Cannot invoke "com.southernstorm.noise.protocol.CipherState.destroy()" because "this._sender" is null

dr|z3d at net.i2p.router.transport.ntcp.NTCPConnection.sendTermination(NTCPConnection.java:919)

dr|z3d at net.i2p.router.transport.ntcp.NTCPConnection.sendTerminationAndClose(NTCPConnection.java:886)

dr|z3d at net.i2p.router.transport.ntcp.EventPumper.run(EventPumper.java:335)

dr|z3d at java.base/java.lang.Thread.run(Thread.java:1589)

dr|z3d at net.i2p.util.I2PThread.run(I2PThread.java:103)

zzz gah. will put on the list

zzz actually, you also reported that to me July 25, apparently I never got to it

dr|z3d oh, I did? fairly rare that one.

zzz seems impossible since there's a null check right above, I think that's where I got stuck in July, but I think I see now how it could happen

dr|z3d yeah, well there's already if (!addrs.isEmpty() && !_context.router().isHidden()) { but obviously that's not sufficient?

zzz dunno where you're looking but it's not NTCPConnection line 919

dr|z3d oh, my bad, looking at NTCPTransport.

dr|z3d if (_sender != null) { is the npe check, so hmm.

dr|z3d doesn't like this. for some reason?

dr|z3d must be hallucinating, just as fast as I saw this., it's gone.

zzz it's synced which is why I was stumped

zzz but the sendNTCP2() call can loop back around and null out the sender out from under it

zzz fixed and pushed

dr|z3d *thumbs up*

zzz one is a cosmic glitch, two is a trend...

dr|z3d you can trust me to keep you on your toes, worry not :)

zzz oooh orignal have more information

zzz it's way more complicated than I thought

zzz 1) you send me a session request with a ZERO EPHEMERAL KEY

zzz 2) I validate the tag, then try to decrypt, and fail and error-out

zzz 3) one second later, you send it to me again, but this time it has a key in it

zzz * 2) validate the _token_

zzz 4) you retransmit the session request, but this time it has a good key in it. but the token is now bad, I removed it in 2)

zzz 5) I send a retry

zzz 6) you send me the *third* session request, but the dest conn id is bad

zzz example of the first session request packet:

zzz 12/14 17:02:37.641 DEBUG [ handler 1/1] ort.udp.InboundEstablishState2: Session request error, State at failure: XK-SSU2 FAILED Handshake State:

zzz Symmetric State:

zzz ck: xT3Wl64BQJ~ZLufhD4BgWuwo1svtSHIyM5ooTEUcUb8=

zzz h: onXgF--aeG3YwvxUJWJG2fmfTmgWXqlzoqhJ7P8uoEI=

zzz Cipher State:

zzz nonce: 1

zzz poly key: aQyURkc07BYLlUdRDzA8GhxO8PtKSVPV99OogksOAYg=

zzz Local static public key (s) : BXQWzxofPktKLnU3XEmKJuzhpqBtA9Pe3Dt3-kpVvFk=

zzz Remote static public key (rs) : null

zzz Local ephemeral public key (e) : null

zzz Remote ephemeral public key (re) : jn6VAskA8BRmzAwvODSs-Q~hqC5QwIkB~2AHLXbDTGI=

zzz 00000000 b9 4f 8a ea 01 06 44 15 00 00 00 00 00 02 02 00 |.O....D.........|

zzz 00000010 fd 8e ca 09 83 18 92 ec 1c ec b5 e8 cd fd 63 2a |..............c*|

zzz 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

zzz 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

zzz 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

zzz 00000050 00 00 00 00 00 00 00 |....... |

dr|z3d easiest fix to keep the token around for a bit longer after a fail?

dr|z3d maybe do what you do with RIs, and schedule a mass removal?

dr|z3d it sounds like just keeping the token around for a couple of minutes before nuking it might work?

zzz sure, but that doesn't fix root cause

dr|z3d obviously that's not a total fix, that needs to come from original it sounds like, but it's a workaround of sorts until it's fixed?

zzz not just zero key; the whole payload is zeros

dr|z3d gotcha.

zzz oh I see what's happening. It's a 87 byte packet, every time

zzz it's leaking through my packet classifier