IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/12/14
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+not_bob_afk
+orignal
+weko
FreeRider
Irc2PGuest71506
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
T3s|4__
aargh2
anon
cancername
eyedeekay_bnc
hk
profetikla
shiver_
u5657
x74a6
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.
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?
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