obscuratus
On 2.0.0-6, I was able to replicate the behavior where peers banned by updates through the news feed would later disappear from the ban list after initally being added.
obscuratus
I'm not seeing this behavior on 2.0.0-9
dr|z3d
obscuratus: I told you it was fixed, I pointed you to the commit. Thanks for confirming what I told you :)
obscuratus
OK, last I knew, it was unclear that removal from the ban list was expected on pre -8
dr|z3d
<dr|z3d> zzz fixed a bug in -8 that prevented blocks to routers using SSU
dr|z3d
this all has the faint whiff of deja-vu about it :) I'm pretty sure we cleared this all up yesterday.
obscuratus
Apologies if this is "Captain Obvious" stuff. But my logs are getting a lot of entries like:
obscuratus
TunnelPool: No peers to put in the new tunnel! selectPeers returned null! boo, hiss!
obscuratus
They're nearly always preceeded by something like:
obscuratus
tunnel.pool.ClientPeerSelector: Picked IPv6-only or unreachable peer for IBGW
obscuratus
I can seldom even find the offending peer in my profile tab. But the ones I find are usually LU
obscuratus
Not sure why I'm getting so many LU routers for IBGWs. That's confusing.
obscuratus
I should clarify the log message is always from ExploratoryPeerSelector. Never for my client tunnels.
dr|z3d
is that just after startup, obscuratus, or ongoing?
obscuratus
Ongoing.
dr|z3d
at a guess, you're bumping into the poor exploratory build success issue the network's been experiencing lately.
obscuratus
Yeah, that's why I passed it along. Wasn't sure if it would be helpful
dr|z3d
it's bad enough that zzz's mooting a possible interim January release if it gets much worse.
obscuratus
This may sound overly simplistic, but why pick a LU as IBGW?
dr|z3d
for exploratory tunnels, the requirements are less than for client tunnels.
obscuratus
That's just about guaranteed to fail.
obscuratus
The IBGW has to be reachable, no?
dr|z3d
but U, hmm. that's definitely a bit odd. possibly fallback strategy because nothing much is working.
obscuratus
Could be.
dr|z3d
well, it's reachable by way of introducers.
dr|z3d
I haven't looked at that code in a while, but I think in I2P+ I eliminate lower tier routers from all client tunnels, so I'm probably not going to be seeing the same issues.
dr|z3d
you might be able to achieve the same result +- with router.excludePeerCaps=K,L,M,N
dr|z3d
without the commas.
dr|z3d
eg router.excludePeerCaps=KLMNU
dr|z3d
that setting will kick in almost immediately, no router restart required.
obscuratus
Thanks, for right now, my router seems to be running OK despite these Exploratory tunnel failures.
obscuratus
I've never even seen a K.
dr|z3d
not many about, you have to really want to handicap your router to run in the K tier :)
obscuratus
Just thinking out load (metaphorically)... If a person decided to run 1000 LU routers from a single IP (each on a different port), would we pick up on that?
dr|z3d
if you enable scanning for non-floodfill routers on sybil scans, sure.
obscuratus
But we don't even store the IP address of unreachable routers, or do we?
dr|z3d
oh, LU, sorry. no, that probably wouldn't trigger any alarm bells.
obscuratus
If you have net.i2p.router.tunnel.pool=WARN or net.i2p.router.tunnel.pool.ExploratoryPeerSelector=WARN, this might be interesting.
obscuratus
grep 'Picked IPv6-only or unreachable peer for IBGW' ~/.i2p/logs/log-router-?.txt | cut -d ' ' -f 18 | sort | uniq -c | sort -rn
obscuratus
I have one router showing up 32 times, but his hash isn't even in my Peer Profiles.