~dr|z3d
@RN
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+RTP
+Unbur
+Xeha
+acetone
+cumlord
+dolphinandcat
+goose2_
+j6
+poriori
+profetikla
+r00tobo
+snex
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
Irc2PGuest48909
Irc2PGuest54864
Irc2PGuest69244
Irc2PGuest71836
Nausicaa
Onn4l7h
anon2
anontor
anu
bak83_
boonst
enoxa
fujifilm
goose2
itsjustme
mareki2pb
onon_1
qend-irc2p
shiver_
u5657
unwr
user
veiledwizard
xen_NULL
cumlord
Rpi 3 might struggle with floodfill still
Xeha
that's why you use a proper odroid ;)
cumlord
rpi knockoffs are the way to go
cumlord
The orange pi’s are pretty happy haven’t looked at odriod
uop23ip
Hi orignal. does i2pd handle the caps D router the same way as canon or plus and would a pi4 get a D in i2pd?:
uop23ip
D: Medium congestion, or a low-performance router (e.g. Android, Raspberry Pi) Other routers should downgrade or limit this router's apparent tunnel capacity in the profile.
orignal
what?
orignal
i2pd publishes D when 70% of max capacity
orignal
your D because you have too much transit tunnels
orignal
inscrease this limit
orignal
you can do it from the web consol
uop23ip
so i2pd doesn't give arm/pi a D because of arm/pi? it does it if 70% of maxParticipatingTunnels is reached. Increasing this limit would change that, right?
orignal
only when 70% of limit
orignal
yes
orignal
number of transit tunnels or bandwidth
uop23ip
Ok thanks, a needed info :)
dr|z3d
orignal: you said you were up for blocking Tor if zzz ok'd it. zzz ok'd it.
dr|z3d
next + feature being worked on is a custom url list blocker for the http server tunnel.
dr|z3d
create a list of paths or files on your server that you don't want accessible over i2p, or aren't there and are signs of a vuln scanner spidering your site, and when they're accessed the client will get blocked and his b32 will be written to a file you can optionally configure via the tunnel filter to ban the b32.
dr|z3d
think of it like a primitive WAF (web application firewall) for I2P.
dr|z3d
ok, available for testing on the /dev/ update path.
dr|z3d
blocks go in ~/.i2p/http_blocklist.txt (one string per line)
dr|z3d
any clients (b32s) that trigger a block will be logged to ~/.i2p/http_blocklist_clients.txt
dr|z3d
the clients list will only contain unique b32s, so multiple blocked requests from the same b32 will only show a single dest in the blockfile.
orignal
no I didn't say this
orignal
because people use i2p over Tor
dr|z3d
we were discussing your theory the attacker's sitting behind Tor, orignal. when I raised the issue of blocking Tor, your words were iirc, "up to zzz". but no matter, we're blocking Tor now in Java-land, so Tor users are siloed.
dr|z3d
(or rather, canon I2P is also blocking Tor now, + has been blocking for a while)
not_bob
Using I2P over tor, while it works is not good.
not_bob
Or, did work :)
orignal
it wouldn't solve the problem
orignal
my point was another one
orignal
I want to exclude Tor peers from MY tunnels
dr|z3d
so you need to implement a tor exit node blocklist type feature.
orignal
yes, but first I need to clollect actual IPs of U routers
dr|z3d
if you want a list generator, help yourself to: git.skank.i2p/i2pplus/I2P.Plus/src/branch/master/installer/resources/maketorblocklist.sh
dr|z3d
if you intended to remove the ticks on the graphs for 2.5.2, zzz, they're still present.
dr|z3d
if not, nevermind.
zzz
ticks are gone for me, I did test it ))
dr|z3d
I was looking at a canon 2.5.2 install.
dr|z3d
I mean, they're gone for me, too, but when I looked at canon pngs they were still there.
zzz
may not have looked closely at pngs. I verified pngs still worked, but that's it
zzz
dr|z3d, re: URL pattern matching
zzz
reading/parsing/compiling patterns from a file on every request is completely untenable, except as a toy demo
zzz
ditto reading/appending the dest block file
zzz
and you're not using that file for anything, because you're not blocking them unless they match patterns again? afaict
zzz
the place to start, as discussed long ago, is access filter, which does it all right - patterns in memory, reload only if changed on disk, batch bans in memory and write out periodically, both happen in background threads
T3s|4
zzz: not sure if I just got lucky, but I want to believe the new vs old RI path you're on is important. On my end, -1+ built tunnels and connected to IRC much faster than 0+
zzz
dunno what's in -1+ but nothing from me would have made a difference
zzz
the new/old thing is orignal's and weko's proposal, I'm just trying to keep up
orignal
old problem new approach
T3s|4
noted zzz, so I must have been lucky. In any event, glad you're trying to crack larger issues