IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/01/26
@eyedeekay
+R4SAS
+RN
+RN_
+Xeha
+orignal
FreeRider
Irc2PGuest22478
Irc2PGuest48042
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
eyedeekay_bnc
not_bob_afk
profetikla
shiver_1
u5657
weko_
x74a6
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 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