@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21881
Irc2PGuest5995
Irc2PGuest88897
Irc2PGuest95630
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
T3s|4__
aargh2
acetone_
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb_
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
x74a6
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.