@eyedeekay
+R4SAS
+RN
+Xeha
+acetone
+orignal
+weko
Hikari
Irc2PGuest67835
Irc2PGuest97144
Leopold
Minogami
Onn4l7h
Onn4|7h
T3s|4_
anon4
eyedeekay_bnc
idk
j6
not_bob_afk
profetikla
qend-irc2p
u5657
x74a6
zer0bitz
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