@eyedeekay
+RN
+acetone
+orignal
+polistern
Irc2PGuest63393
Leopold
Minogami
Onn4l7h
Onn4|7h
ProRu
R4SAS_
eyedeekay_bnc
limak
not_bob_afk
profetikla
weko_
x74a6
zer0bitz
zzz
I think I found a problem
zzz
with expl. tunnel peer selection
zzz
haven't made a chart yet
zzz
but the fastest routers have the worst expl. build success
zzz
the slow routers are fine and happy
zzz
when build success % is low, we pick mostly from high cap instead of all
zzz
that's a good strategy for slow routers
zzz
but congestion starts from the top
zzz
so that's the wrong strategy
zzz
so fast and ff routers should always pick from all, at least after initial startup
zzz
I'll work on it but I gotta land my refactor first
zzz
I'm getting close
zzz
dr|z3d, did you fix the funk?
obscuratus
orignal: Do I2PD participating tunnels have something akin to a grace period after they provide their promised 10 minutes of availability?
obscuratus
I'm noticing a pattern of high bandwidth participating tunnels that stay 100% active using all available bandwidth all the way through the 2 minute grace period.
zzz
hmm
dr|z3d
possibly funk removal, zzz, was looking for confirmation from orignal.
zzz
well, did you confirm removed?
dr|z3d
obscuratus: there is no 2 minute grace period. just 1. after 11 minutes, tunnel should be gone.
dr|z3d
at least, not with java. 2m grace period for transit tunnels on i2pd, orignal?
dr|z3d
no. asked yesterday, awaiting response.
zzz
then test it, that's how you confirm
dr|z3d
how I confirm is orignal saying "yes it's fixed". if orignal he say, "no, still funk", then I'll look into testing. :)
zzz
with all due respect, you should test it yourself before asking others to, especially if it's easy. That's how to fix things quickly
dr|z3d
just like you, I'm not an octopuss with 96 hours in a day.
zzz
sure but why waste everybody's time if you didn't confirm you fixed it and didn't confirm postman is running it?
zzz
but I'll butt out, that's between you and the other guys
dr|z3d
I've done a preliminary test. No dupe leasesets for irc.postman I can see. postman also reports both LS's being published normally. So, you know, I'm waiting for orignal, the reporter of the bug, to shed some light.
zzz
great
dr|z3d
top 3 peers re tunnel count all on that ip address. all X tier.
orignal
yes still 2 leasesets
orignal
obscuratus what can I do in this siatuation?
orignal
I accept a tunnel and it start shitting out bandwidth
dr|z3d
ok, orignal, thanks. and you've restarted your router in the last 24h?
dr|z3d
orignal: java has 1 minute of grace after the 10m, then tunnel is dropped.
orignal
dr|z3d tarnsit tunnels dies after 11 minutes
orignal
dr|z3d no
dr|z3d
ok, same as java then.
orignal
can reatsrt if you wish
dr|z3d
orignal: if you don't mind, that would be helpful just to rule out any residual leasesets. thanks.
orignal
I don't think it would
orignal
these 2 leasesets must be gone long time
orignal
will restart tonght
dr|z3d
you're probably right, but thanks.
dr|z3d
that ip above smells real funny.
dr|z3d
adding 185.213.155.0/24 to blocklist.
obscuratus
orignal: Thanks for the feedback. I don't know about dr|z3d, but my Java I2P router has a two minute grace period. I was trying to figure out if the behavior I'm seeing means these participating tunnels are somehow using only Java I2P routers (because they run for an extra minute?).
dr|z3d
obscuratus: private static final long GRACE_PERIOD = 60*1000; in BuildExecutor
dr|z3d
unless I'm mistaken, that's the additional time allowed on an expired tunnel.
orignal
so, if I should use 2 minutes let me know
orignal
just need a confirmation from zzz
orignal
if (ts > tunnel->GetCreationTime () + TUNNEL_EXPIRATION_TIMEOUT)
orignal
it = m_TransitTunnels.erase (it);
orignal
const int TUNNEL_EXPIRATION_TIMEOUT = 660; // 11 minutes
dr|z3d
long expireBefore = now + 10*60*1000 - BuildRequestor.REQUEST_TIMEOUT - GRACE_PERIOD;
orignal
so what should I use? 11 or 12?
orignal
let's wait for zzz
dr|z3d
pretty sure we're all on 11.
obscuratus
I'd wait for zzz to chime in.
dr|z3d
I dunno where obscuratus us getting 12 from. but sure, wait for zzz to confirm.
zzz
reading up...
zzz
researching...
zzz
so is the question when the creator expires it or when the hops expire it?
zzz
or both?
obscuratus
We're talking about participation tunnels, so when a router hosting a participation tunnel expires the hop.
zzz
were you seeing the issue on testnet or live net?
obscuratus
I'm seeing the issue on the live net. On test net, everything always expires politely.
zzz
sure, no clock skews
orignal
the question how long partcipant should wait
orignal
11 minutes or 12?
zzz
we wait 12 minutes, although I don't think there's anything wrong with 11
zzz
11 should be fine
zzz
one thing, originator should set LS timeout and OB tunnel timeout based on 10 minutes from when request was sent (not when reply was received)
obscuratus
So, it has me pondering. If I see a participating tunnel that stays 100% active all the way through the grace period, can I conclude that there have been no I2PD participating hops prior to mine?
zzz
you're seeing that on a java router, so 12 minutes?
obscuratus
zzz: yes.
orignal
so should I change to 12 or leave 11?
zzz
orignal, please double check your LS exp. and OB tunnel exp. at originator is 10 minutes from request sent, not reply received
orignal
will do
zzz
it just doesn't seem too likely that originator clock is off 59 seconds one way and some other peer is 59 seconds off the other way
zzz
but it could be
orignal
and it must be 10 minutes?
zzz
yes, 10 minutes from request sent
orignal
m_CreationTime (i2p::util::GetSecondsSinceEpoch ())
orignal
I set creationm time when create new tunnel
orignal
if (ts + TUNNEL_EXPIRATION_THRESHOLD > tunnel->GetCreationTime () + TUNNEL_EXPIRATION_TIMEOUT)
orignal
tunnel->SetState (eTunnelStateExpiring);
orignal
where const int TUNNEL_EXPIRATION_THRESHOLD = 60; // 1 minute
orignal
so if exceeds 10 mintes I set "expriting" state and don't use that tunnel anymore
zzz
on one router with ~1000 connections the max clock skew is 8 seconds
orignal
auto ts = tunnels[i]->GetCreationTime () + i2p::tunnel::TUNNEL_EXPIRATION_TIMEOUT - i2p::tunnel::TUNNEL_EXPIRATION_THRESHOLD; // in seconds, 1 minute before expiration
orignal
if (ts > expirationTime) expirationTime = ts;
orignal
htobe32buf (m_Buffer + offset, ts);
orignal
that's what I put to Lease
zzz
TIMEOUT is 660 and THRESHOLD is 60 so the LS time is 10 minutes, that looks right
zzz
but when do you stop using your outbound tunnel? 660 or 600?
orignal
if (ts - lastTs >= TUNNEL_MANAGE_INTERVAL) // manage tunnels every 15 seconds
orignal
it pratcicaslly means I might update tunnel state with up to 15 sec delay
orignal
I stop using when state becomes "expiring"
orignal
but as I said it might be with 15 sec delay
orignal
I will fix that part
zzz
yeah but your outbound tunnel expires after 11 minutes or 10?
orignal
10
orignal
but I might check it not after 10 but 10.15
zzz
shouldn't be a problem
orignal
I think so too
zzz
so I don't see any reason for what obscuratus is reporting, other than huge clock skews
zzz
or hacked attack routers
orignal
he uses testnet. no?
obscuratus
What about when a router is having trouble building new tunnels (due to congestion). Well Java I2P or I2PD keep using the existing tunnels though 10 minutes until new tunnels are built?
obscuratus
orignal: What I'mseeing is on the live net.
zzz
could also be picking a reply tunnel for tunnel build or netdb lookup that's about to expire?
zzz
if it is an attack, maybe I should change from 12 to 11...
zzz
no use letting more spam through
zzz
we could also bandwidth limit tunnels while in grace period
orignal
no when I pick a tunnel tha prupose doesn't matter
orignal
I don't pick "expiring" tunnels
zzz
yeah but would you pick a tunnel expiring in 5 seconds as a reply tunnel?
orignal
linke 9.55? yes
zzz
probably not good for a reply tunnel for outbound builds, but doesn't seem like a big problem
zzz
netdb replies would not be a lot of bandwidth
zzz
but maybe tunnel build spammer could be doing it?
zzz
it would be easy for me to choke the bandwidth during the grace period, I think I'll try that
orignal
so what's you suggestion? limit to 9.30 ?
zzz
looking...
zzz
we don't do that, we go right up to 10 minutes
orignal
fine