~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest14111
Irc2PGuest2974
Leopold
Liorar_
Nausicaa
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori_
qend-irc2p_
thetia
u5657
T3s|4
lols dr|z3d - told our absent favorite 'novice' on -chat; RN: as predicted, your date of forced re-Conkification destiny has arrived on + :D
dr|z3d
rare NPE spotted in InboundMessageDistributor, eyedeekay, zzz.. (only seen it once). proposed fix follows:
dr|z3d
public InboundMessageDistributor(RouterContext ctx, Hash client) {
dr|z3d
_context = ctx;
dr|z3d
_client = client;
dr|z3d
_log = ctx.logManager().getLog(InboundMessageDistributor.class);
dr|z3d
_receiver = new GarlicMessageReceiver(ctx, this, client);
dr|z3d
// all createRateStat in TunnelDispatcher
dr|z3d
if (_client != null) {
dr|z3d
TunnelPoolSettings clienttps = _context.tunnelManager().getInboundSettings(_client);
dr|z3d
String nickname = clienttps != null ? clienttps.getDestinationNickname() : "UNKNOWN";
dr|z3d
if (_log.shouldLog(Log.DEBUG)) {
dr|z3d
_log.debug("Initializing client " + nickname +
dr|z3d
" [ " + _client.toBase32().substring(0,12) + "..." + "] " +
dr|z3d
"\n* InboundMessageDistributor with tunnel pool settings: " + clienttps);
dr|z3d
}
dr|z3d
_clientNickname = clienttps != null ? clienttps.getDestinationNickname() : "UNKNOWN";
dr|z3d
_msgIDBloomXor = clienttps != null ? clienttps.getMsgIdBloomXor()
dr|z3d
: RandomSource.getInstance().nextLong(I2NPMessage.MAX_ID_VALUE);
dr|z3d
} else {
dr|z3d
_clientNickname = "NULL/Expl";
dr|z3d
_msgIDBloomXor = RandomSource.getInstance().nextLong(I2NPMessage.MAX_ID_VALUE);
dr|z3d
if (_log.shouldLog(Log.DEBUG))
dr|z3d
_log.debug("Initializing NULL or Exploratory InboundMessageDistributor...");
dr|z3d
}
dr|z3d
}
zzz
please verify the code is identical in canon
dr|z3d
it won't be identical, logging will be slightly different, but I'll check. the issue arose with _clientNickname after the first clause iirc.
zzz
please enter ticket if you can verify
zzz
eyedeekay has other IMD issues I just discovered
dr|z3d
yup, appears that in the same location, the code is identical: _clientNickname = clienttps.getDestinationNickname();
zzz
put the stack trace in the ticket please
dr|z3d
don't think I have it anymore
dr|z3d
(line 56)
zzz
then at least put in the line number
zzz
and the proposed fix as a diff vs. canon
zzz
while IMD was recently reverted back to 2.3.0, and almost all my review is focused on the diff vs. 2.3.0, I've discovered a major issue with the 2.2.1 -> 2.3.0 changes
zzz
in IMD
dr|z3d
major issue, easy remedy, or something worse?
zzz
see #475
dr|z3d
if I was trying to be amusing, I'd ask you if you think I'm fat. :)
dr|z3d
Not seeing the drops you're witnessing on the router I'm currently looking at, at least not in the current logs.
dr|z3d
plenty of these, though, not sure why they're categorized as WARN: OutboundEndpoint I2NP Message from [TunnelId 272397814] to Router [XXXXXX] ➜ Count: 161 / 358
zzz
I think 475 is an issue on long-lived connections like for snark where you're doing ratchet acks, but just a guess right now
dr|z3d
ok
dr|z3d
so it turns out the WIP mitigation for dns bypass via fbi.com is probably the same place in the code where dodgy urls can be blocked.
dr|z3d
not the best solution, but I'm thinking as an interim fix providing it with a list of urls we don't want to serve and just blocking them.
zzz
this is all much better implemented and maintained externally
zzz
you could write a simple helper pipe in a shell script
zzz
you're not going to see urls for https anyway
zzz
just stick a simple transparent proxy between i2p and your current external proxy and do whatever filtering you want there
dr|z3d
different context, I'm talking about the .i2p exploit scanners.
zzz
that's the proposal to enhance access filter to pass the url to it
zzz
access filter may also be the solution for throttling keepalive requests
dr|z3d
re the first, I thought we decided access filters wasn't the place to handle url requests. throttling, otoh, sure.
dr|z3d
either way, filtering could do with some love.
dr|z3d
I mean, it's useful, but it's also a bit of a nuisance to set up and configure right now.
zzz
it doesn't now but it could.
dr|z3d
ok, if you think it can be modified to scan urls, great.
zzz
in theory but it would be complex enough it would need a formal proposal to enhance the filter file spec
dr|z3d
I'd probably want to approach it from the UI angle first, see what we can do in the tunnel manager to make things a bit less cumbersome.
dr|z3d
if you're removing things in html that were otherwise hidden via css, zzz, make sure you remove all the css-hidden elements.
dr|z3d
that is, assuming you want visual parity.