@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3
eyedeekay_bnc
hagen_
hk
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_1
solidx66
tr
u5657
uop23ip
w8rabbit
weko_
x74a6
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