@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3
eyedeekay_bnc
hagen_
hk
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_1
solidx66
tr
u5657
uop23ip
w8rabbit
weko_
x74a6
dr|z3d
zzz: chunk of the ip restriction patch in ProfileOrganizer looks wrong to me. minor, but it appears that logging excluded peers won't happen.
dr|z3d
git.idk.i2p/i2p-hackers/i2p.i2p/-/merge_requests/45/diffs#8e0f44658e734992c32753787aeab8072372e5b5_1315_1353
dr|z3d
maybe I'm reading it wrong, but the following looks like the correct way to handle logging?
dr|z3d
if (ok) {
dr|z3d
ok = mask <= 0 || notRestricted(peer, ipSet, mask);
dr|z3d
matches.add(peer);
dr|z3d
} else {
dr|z3d
matches.remove(peer);
dr|z3d
if (_log.shouldLog(Log.WARN)
dr|z3d
_log.warn("IP restriction prevents " + peer + " from joining " + matches);
dr|z3d
}
dr|z3d
maybe I'm reading it wrong, ok is defined in the top clause. notwithstanding, I'd expect to see a few exclusion log entries from the ProfileOrganizer. nada as yet.
dr|z3d
ah. nevermind. finally logging triggered.
dr|z3d
matches doesn't print anything, though. just []
dr|z3d
> IP restriction prevents XXXX from joining []
dr|z3d
should that be a tunnel id?
zzz
dr|z3d, I think that code is right, its old code from 12 years ago. I only got a couple hits also, but I verified they were correct by looking up the RIs
zzz
I'm temporarily changing the default from 2 to 1 in TunnelPeerSettings for testing so it hits more often, lets see what happens
dr|z3d
zzz: yeah, my bad, it logs ok, it just doesn't always print the matches. tunnel id instead in the logs?
dr|z3d
it got me thinking though about the scope of the blocks. it's too early I know, but at some point an external list of ranges for specific ranges might be an idea, for example for vps providers, orgs etc. and then of course limiting by country code also seems like a possible use.
zzz
what would tunnel id do for you?
dr|z3d
something that always prints in the logs
zzz
I'm not following, but maybe I need more coffee
dr|z3d
maybe tunnel id's not much help either, but something in the logs that better indicates why the peer's been blocked.
dr|z3d
like the specific network range.
dr|z3d
Blocking [peer] from joining [tunnelid] -> in the same range as [xxxx] and [yyyy] (0.0.0.0/24) or somesuch.
zzz
unfortunately more trouble than it's worth as it's hidden down in MaskedIPSet. The log is there mainly so I can tell that it's working, so it's doing its job
dr|z3d
ok
dr|z3d
if it's hassle, forget it.
zzz
it is also matching on port number and family
zzz
there is also a match for NTCP with cost 2, which I don't understand and need to research
dr|z3d
I can confirm it's apparently working. some config knobs would help test things without recourse to recompiling perhaps. port and family is a good start. much work to slide countries into the mix?
zzz
whats the threat model for same country?
dr|z3d
router.iprestrictRange=24 and router.ipretrictCount=1 I'm thinking of.
dr|z3d
threat model is state level interference class sybil attacks?
dr|z3d
that would also apply to org ranges, to prevent someone from hosting a few hundred "droplets" aka micro-VPSs to perform sybil attacks. apparently that's already happened.
dr|z3d
s/Range/Metric
zzz
that seems better addressed by hidden mode that blocks everybody from your country now
zzz
not sure if disallowing two from the same country does much
dr|z3d
well, at the minimum it ensures your tunnels are using a more diverse set of routers. hidden mode is a different beast, what with the inherent performance downgrade.
zzz
it's something new to be considered and justified separately, won't be thrown into the current effort to fix whats broken
zzz
as we can see even this ip restriction is very rare
zzz
anyway, thanks for testing
dr|z3d
no worries, and yeah, country and list-based org restrictions are a "for consideration" topic, not a proposal for immediate integration :)
dr|z3d
on a completely different topic, i2pd and i2p's http server tunnels apparently have different characteristics that allow for profiling/identification.
zzz
e.g.?
dr|z3d
for a 304 resource, i2pd responds with 0 bytes, i2p will send a good chunk of data, 20 bytes or so, to fulfill the same request.
dr|z3d
*20KB
dr|z3d
what's even more weird is that i2p's tunnel isn't consistent in the amount it sends for a 304.
dr|z3d
i2pd sends the response as a 304, i2p as a 200.
dr|z3d
and even when i2pd sends as a 200, it's still sending a 0 byte response. so definitely some discrepancy in handling.
zzz
why would we send anything with a 304
zzz
it's either a 200 or a 304, cant be both
dr|z3d
that's not an i2p thing, that's a server operator thing. you'd send a 304 because "file not changed"
zzz
if anything it would be a jetty vs. something else thing, not a i2p vs i2pd thing
dr|z3d
nah
dr|z3d
the backend server's the same. not jetty.
dr|z3d
that's what's strange, same backend, i2p or i2pd, different responses.
zzz
our proxies don't turn 304s into 200s or vice versa
dr|z3d
from the logs, it looks like eepget (?) is ignorant of 304 responses and ignores them.
dr|z3d
that's my guess, could be way off the mark, though.
dr|z3d
the only time I see a 304 response in the logs is when i2pd is handling the request. i2p never returns 304 it looks like.
zzz
eepget doesnt send the etag/last mod headers that would provoke a 304 response unless you put it in the command line
dr|z3d
yeah, but that doesn't account for the different response at the business end of things. i2p peer requests update.zip, i2pd responds with either a 200 or 304 and then a 0 byte payload, i2p will handle the same request and always responds with a 200 and a variable sized response. just odd.
dr|z3d
the logging is different, too. i2p logs as domain.i2p, i2pd logs requests as *.b32.i2p
zzz
dunno. not a rabbit hole I'm going to jump into
dr|z3d
I'll do some digging, see if there's anything obvious in the code.
dr|z3d
arstechnica.com/information-technology/2021/12/hackers-launch-over-840000-attacks-through-log4j-flaw
Xeha
no surprise, check how huge the codebase is. its literally bloatware
Xeha
it was fun seeing people try it starting ~1.5 weeks ago