@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+orignal
+postman
+weko
An0nm0n
Arch
FreefallHeavens
Gid
Hikari
Irc2PGuest12867
Irc2PGuest1893
Irc2PGuest4253
Irc2PGuest51959
Leopold
Minogami
Onn4l7h
Sleepy
Soni
Teeed
aargh1
admin
anon
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
idk
itsjustme
j6
limak
not_bob_afk
pihole
polistern
poriori__
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
u5657
user100
w8rabbit
x74a6
yourtrueself
zer0bitz
eyedeekay
Latest checkin on test1 and congestion-cap-penalties sends the routerInfo to the requester the first time somebody tries to build a tunnel through a G-capped router, then waits another 9 requests for them to stop before banning them
dr|z3d
eyedeekay: what if we send out our RI to new routers requesting tunnels if our congestion cap has changed since we last flooded our RI?
obscuratus
What if we just treat our congestion caps as informational. Other routers can pay attention to them or not. Ostensibly, they'll be more reliable if they avoid us when we warn them.
obscuratus
I really don't like it that where we used to have a limit, and dropped requests after that, we are now setting a new hard limit at 80%-90% of our previous limit, and we're gonna start banning peers when we even get close to our limits.
obscuratus
It makes the limits we set very confusing. If we say we want to limit our part tunnels to 700, we start banning at 630.
obscuratus
So our bandwidth limit is not longer our bandwidth limit. Our tunnel limit is no longer our tunnel limit. The limit is now another number.
dr|z3d
I don't think there's an issue per se with rejecting first, tallying the amount of requests after we've said no, and then setting a threshold above that to ban, *as long as* we know the requesting router has our current RI with the congestion cap.
eyedeekay
My hypothesis, and maybe I'm wrong, is that the tunnel spam attackers will more or less ignore all congestion caps and send tunnels to routers that indicate congestion, and that would be a reliable way of identifying malicious behavior, assuming at least that the G cap is honored by a router and that we can be reasonably sure it's got our RI
dr|z3d
And congestion caps were always intended to be a fine tune of bandwidth caps. So I don't see an issue with using them more proactively.
eyedeekay
But maybe banning outright isn't the right wau
dr|z3d
As long as the ban is relatively shortlived, don't think there's an issue.
dr|z3d
15m? 1h?
RN
doesn't i2pd completely ignore caps? so they'd all end up getting banned if we were congested.
eyedeekay
No they do have cap handling
eyedeekay
It's in the backlog up there, RouterInfo.cpp 12~~ something
obscuratus
The whole part about tunnels bugs me. So we set our congestion caps to G when when get within 90% of our tunnel limit. How the heck does the router building tunnels know that? They're not necessarily connected. And we have no idea who initiated the tunnel build. So we can't send them our updated RI.
obscuratus
Who do we even ban on tunnel builds anyways?
eyedeekay
Fuck you're rigjt
eyedeekay
I'm banning the wrong guy, it's the RI that we got it from last
obscuratus
Lol
eyedeekay
I'll walk it back
obscuratus
eyedeekay: In your patch "Router: drop lookups from routers we already banned", the if conditional is backwards.
obscuratus
Instead of "if (!isBanned) {" it should be "if (isBanned) {"
obscuratus
This is router/java/src/net/i2p/router/networkdb/kademlia/FloodfillDatabaseLookupMessageHandler.java
obscuratus
That might help the 100% lookup failure I'm seeing on my testing network. :)
obscuratus
Did we talk about this one before? I can't remember. It would be a good spot for a Warning or Error along the lines of "Why are we even talking with someone we banned?"
eyedeekay
Pushed both, yes we did talk about this before IIRC
eyedeekay
Anecdotally, my ETBS for the day is way above my running average