&zzz
+R4SAS
+RN_
+T3s|4
+eche|off
+nilbog
+orignal
+postman
+qend-irc2p
+sourceress
Arch
Birdy
Danny
Irc2PGuest30010
Irc2PGuest36077
Irc2PGuest49364
Irc2PGuest51117
Irc2PGuest6564
Irc2PGuest65656
Irc2PGuest67278
Irc2PGuest74235
Irc2PGuest83482
MatrixBot
Onn4l7h
Over
Sleepy
Teeed
Yotsu
__bob_
aargh3
ac9f
acetone_
ahiru
anontor
b3t4f4c3__
cims
dr4wd3_
dr|z3d
duanin2
hababam
hagen_
leopold
makoto
marek
marek22k
n2
noidea
not_bob_afk2
nyaa2pguy
o3d3_
poriori
profetikla
r00tobo
rapidash
solidx66
stormycloud[m]
test7363673
uop23ip
urist_
user_
w8rabbit
zelgomer
dr|z3d
any thoughts on a table of transient bans on /peers that notes detected ips (with count), country flag(s), reason, ban controls etc, zzz?
zzz
sounds hard
dr|z3d
shouldn't be, a fair chunk of the data's already in the banlist.
zzz
we display flag and reason (including IP if available) and an unban icon now, so I'm not sure what you're after beyond that
dr|z3d
the ip bans can be linked back to the banned hash, adding an edit button to manually unban peers, easy. what else? :)
dr|z3d
I was thinking of the data, or some of it, presented in a table, just for the transient bans.
zzz
are you asking about the hash bans on /peers or the transient IP blocklist on /configpeers?
dr|z3d
mostly transient bans, though come to think of it, hash bans where there are repeated part tunnel requests might qualify as well.. then you can keep track of the amount of requests for the most frequent offenders.
dr|z3d
nothing so heavy that it gives the browser a job to do in rendering, something like top 20/30 offenders.
zzz
define 'transient bans', I'm confused. We have hash bans (temp. or permanent) and IP blocklist (temp. or permanent)
dr|z3d
transient being session only.
zzz
IPs or hashes?
dr|z3d
in the case of hash bans that originate from the blocklist, we've now got transient ip bans that stem from those, no?
zzz
for hash banlist we store reasons. for IP blocklist we do not
dr|z3d
could be either, assuming session only. we probably don't care about no transport-related bans, more the part tunnel excess requests, hostile requests etc.
zzz
we do not ban for any tunnel reason
dr|z3d
oh, yeah, that's true, my bad. I'm conflating with what I've implemented here recently. short temp bans for hostile tunnel requests.
dr|z3d
I've been seeing a lot of those hostiles lately, so figured I'd put the brakes on the offenders.
dr|z3d
so what does that leave us with? a list of excess tunnel requests where we start dropping them and a count, hostile tunnel requests (count), and ips assocaiated with a banned hash. those events could form the basis of a Hall of shame type table. perhaps? Or maybe it's a non-starter.
zzz
I still don't know what you're asking for. Hash banlist stores reason and it's displayed. IP blocklist does not, nothing to display.
dr|z3d
yeah, forget ip blocklist.
dr|z3d
I'm referring to the discovered ips associated with a banned hash.
zzz
not saved anwhere
dr|z3d
oh? I though those transient ips were a new feature of the blocklist.
dr|z3d
the session-only banlist is probably what I mean.
zzz
no
zzz
again. Hash banlist stores reason and it's displayed. IP blocklist does not, nothing to display.
dr|z3d
yeah, understood. where I got it wrong was thinking that a hash in the blocklist would cause specific ips to then be added to the session-only banlist when detected.
dr|z3d
so if there's nothing much to count (number of tunnel request rejections / drops per hash, for example), then nevermind. I just figured something fairly simple that tracks various blocks and drops for the worst offending peers might be handy.
dr|z3d
on a related note, it may be too early to tell, but the recent fixes to SSU blocking might be responsible for the lack of 40MB/s on the sc outproxy lately.
zzz
if you want to ban hashes out of your tunnel code, add whatever you want to the reason. If you're asking for us to gather stats on the behavior of banned peers, per-peer and post-ban, and somehow annotate each peer in the console on what it's been up to in the afterlife, no
dr|z3d
:)
dr|z3d
hash bans for hostile requests already fixed up with reason strings.