@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+dr|z3d
+hottuna
+orignal
+postman
+weko
Arch
FreefallHeavens
Hidenet
Irc2PGuest13676
Irc2PGuest15345
Irc2PGuest19856
Irc2PGuest2827392
Irc2PGuest33877
Irc2PGuest34200
Irc2PGuest68850
Leopold
Onn4l7h
Onn4|7h
ProRu
Sleepy
Soni
Teeed
aargh3
acetone_
admin
anon1
b3t4f4c3__
eyedeekay_bnc
idk
itsjustme
j6
limak
miozzz
not_bob_afk
polistern
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
w8rabbit
x74a6
zer0bitz
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.