#i2p-dev (irc2p) | 2.7.0-2 | Proposal 168 review Tues. Dec. 3, 8 PM UTC #ls2

Xeha zzz: HaruCode has issues with his java-i2p's http proxy not being able to connect to anything. but connecting via IRC to here works.

Xeha ugh he left :(

zzz how may we help you HaruCode ?

HaruCode hello everyone. the problem is I am unable to open any eepsites, despite router being integrated and irc tunnel working (slowly and breaks all the time). where should I look for problems, given that logs contain no errors? I am behind a double NAT and a rather fascist firewall that doesn't allow outbound UDP.

zzz does the console show you as firewalled?

dr|z3d_ zzz: about SSU IP detection, any way to disable that so that we never get flagged as firewalled on SSU (when we're not?)

dr|z3d_ we have something similar for TCP.. "Always use aut-detected IP (not firewalled)

zzz dr|z3d, I believe if you specify an IP at the top it will force UDP non-firewalled

dr|z3d that's fine on a static ip, but not so much when your ip is dynamically allocated.

dr|z3d there's also the issue of the sidebar status being inaccurate when NTCP is fine and SSU is firewalled.

zzz yeah I get it, but in practice fixed IP ~= not firewalled, more or less

dr|z3d If I'm firewalled on SSU and not on NTCP, status should reflect that.

dr|z3d sure, for a fixed ip, fine, but there should be some method of enforcing not-firewalled on a dynamic ip, too.

dr|z3d I mean, I'm being flagged as firewalled because some router can't see my port, right?

zzz yeah our split in sidebar is v4/v6, not TCP/UDP, since our default setup is that SSU does the detection and then tells NTCP what it is

dr|z3d So my firealled status is entirely dependent on another router's appraisal of my reachability.

zzz of course, you can't reliably detect your own state by yourself. that's why we have peer testing

zzz SSU2 is expected to significantly improve the peer test reliability

dr|z3d yeah, but here's the thing.. if NTCP detects my ip correctly, why does SSU say firewalled and NTCP say OK? I should be able to tell the router to use the NTCP IP address in the event of divergence, surely?

zzz because NTCP does not tell SSU. NTCP does not support ip and state detection and does not communicate state to SSU

dr|z3d so SSU determines I'm not firewalled.. communicates that fact to NTCP.. NTCP remains unfirewalled the whole time, while SSU becomes firewalled. doesn't make much sense.

dr|z3d I mean, sure, if my UDP port was periodically getting blocked locally, but that's pretty unlikely.

zzz ssu tells ntcp when its firewalled, and ntcp should change state also

dr|z3d except it doesn't. I'm not seeing that at all.

dr|z3d what's needed is a config that says "Not firewalled, never attempt to put me in firewalled mode. Ever". :)

zzz if you forced TCP non-firewalled then it will say OK on the peers tab

dr|z3d Right, and it always displays the correct IP address.

dr|z3d imagine this scenario.. my hardware router blacklists ips, some of which may be i2p routers. when those routers attempt to connect, they fail, and then tell me I'm firewalled. I should be able to override that.

zzz ssu2 will fix that

dr|z3d really? so no more being firewalled when I know I'm not?

zzz or maybe not. you'd need to pull the blacklist in

zzz if you have a auto-banning router, that's kinda like a firewall

dr|z3d you have one too, though I don't know if you've enabled that feature. it's called openwrt :)

mesh zzz: btw, I've noticed some issues with 1.18. It's hard to document them (random stuff like outproxy disappearing, the router locking up). I did see the following in my logs: git.idk.i2p/mesh/i2p.i2p/-/issues/6

mesh it's quite strange. 1.17 ran for months with no issue, but in the last week I've had to restart my router 2x

dr|z3d and sure, my i2p router may be firewalled as far as the blocked router is concerned, but I _should_ be able to ignore them telling my router I'm firewalled.

zzz what is 1.18?

mesh oops

mesh 1.8.0-11+

mesh I keep saying 1.17 and 1.18, sorry

dr|z3d mesh: you need to say deadlock for zzz to really take notice :)

mesh yeah, router locking up == router becoming completely unresponsive, and deadlock errors in the log

zzz oh cool, the first find for the new deadlock detector! woooo

mesh I gotta run but I'll continue to collect evidence.

zzz you have local mods, or are you running drz's version, because we don't have any thread called "UDPPktHandler"

mesh I'm running i2P+ yeah

dr|z3d UDP Packet Handler, zzz..

zzz yeah I get it but pottery barn rules here

zzz mesh you have clock skew problems on that box?

mesh yes

mesh 2022/08/05 21:27:51.255 CRIT […PReceiver 3] …t.i2p.util.Clock: Large clock shift forward by 18m

mesh 2022/08/05 21:09:18.024 CRIT […PReceiver 3] …t.i2p.util.Clock: Large clock shift forward by 59m

mesh 2022/08/05 20:09:17.490 CRIT […PReceiver 2] …t.i2p.util.Clock: Large clock shift forward by 42m

mesh 2022/08/04 23:10:06.605 CRIT […PReader 5/6] …t.i2p.util.Clock: Large clock shift forward by 54m

zzz why?

mesh msg likes that are all over thje logs

mesh I assume because my computer goes to sleep and wakes up

zzz yeah so fix that

mesh it usually fixes itself. Would that explain why the outproxy (purokishi.i2p) disappears and the router freezes up?

zzz perhaps

mesh I see stuff like

mesh 2022/08/05 21:27:51.258 WARN […andler 8/12] …dp.PacketHandler: NTP failure, UDP adjusting clock by 547ms

mesh 2022/08/05 21:27:51.258 WARN […ndler 11/12] …dp.PacketHandler: NTP failure, UDP adjusting clock by 453ms

mesh 2022/08/05 21:27:51.256 ERROR […PReceiver 3] …2p.router.Router: Restarting after large clock shift forward by 18mms

mesh 2022/08/05 21:27:51.255 CRIT […PReceiver 3] …t.i2p.util.Clock: Large clock shift forward by 18m

mesh 2022/08/05 21:09:23.505 WARN […ter Restart] …2p.router.Router: Restart complete

mesh 2022/08/05 21:09:23.505 WARN […ter Restart] …2p.router.Router: Restarting the client manager…

mesh 2022/08/05 21:09:22.894 ↓↓↓ 4 similar messages omitted

mesh in my logs but again it doesn't usually cause problems

zzz your name is mesh, when p2p nodes randomly go to sleep and don't know what time it is, there will be consequences

zzz no it shouldnt be deadlocking but I can't fix that in 5 minutes

dr|z3d stop your pc from going to sleep, it should fix itself, mesh.

zzz especially when all the line numbers are off because it's plus.

dr|z3d all the clock related stuff should be virgin, not touched by me.

mesh I could stop the pc from sleeping but I have concerns about dust and running all night. This is a laptop after all. The strange thing though is this stuff never happened uner 1.7. I tell you i2p ran fine for months (Feb-July) and then all of a sudden lots of issues

dr|z3d concerns are unfounded, laptop will run fine powered on all the time.

mesh I guess the system has become more sensitive to clock shifts

dr|z3d as a workaround for firewalled status, zzz, can we increase the frequency of SSU ip detection checks?

dr|z3d also, re laptops, one that remains on all the time is less prone to failure; changing sleep states tends to stress components.

zzz they're already pretty quick, especially with a pending change

zzz behind openwrt you have a public or private IP?

zzz mesh please copy the issue over to our gitlab account, with full version info

dr|z3d net router -> openwrt -> i2p.

zzz when openwrt bans an inbound IP does it ban it outbound too?

dr|z3d depends on the ip, I've got a bunch of rules active.

dr|z3d (using banIP)

zzz in my experience openwrt is very flaky on ipv6. when i2p thinks ipv6 is firewalled it often means openwrt needs a restart

dr|z3d actually, looking at the rulesets, it's just banning the src ip.

dr|z3d oh, yeah, ipv6, I don't bother with that at all. pain in the ass. disabled.

zzz pfft

dr|z3d disabled on the i2p router and openwrt.

zzz so how is i2p getting its public IP? is it public behind openwrt, or via upnp, or via peer test? I'm trying to see if disabling peer test would do it for you

zzz if you ban outbound, then maybe your router will start banning those routers, and it won't try to peer test with them

dr|z3d port forwarding from the net router.

dr|z3d can try blocking outbound too, sure.

zzz the reason why we don't have force-non-fw except bound to force-ip is that you can't be non-fw w/o an IP

zzz if you have a direct public IP interface, or UPnP works, then we'll start out non-firewalled, but otherwise we need peer test to get there

dr|z3d I disable UPnP as a matter of principle. It's all port forwarding here.

dr|z3d And for the most part i2p starts up unfirewalled. It's a strange issue, can go weeks or more without getting firewalled, and then it seems to be more or less persistent.

dr|z3d banip and luci-app-banip is what I'm using to enforce a blacklist on openwrt, fwiw.

dr|z3d ok, disabling outbound for blaklisted ips not making any difference. :|

zzz you can try changing PeerTestEvent.shouldTest() to always return false, but I don't think it will work, you may just stay stuck at "unknown" forever

zzz it's not going to help in 2 minutes

dr|z3d I restarted router.

dr|z3d initially, both SSU and NTCP not firewalled, then after a couple of minutes, SSU firewalled.

dr|z3d I might just try lowering the TEST_FREQUENCY perdiod, currently 13 minutes.

dr|z3d we've also got a config option, maybe that's what I was looking for? i2np.udp.disablePeerTest

dr|z3d_ so far, so good. looks like disabling peer testing via that config gives me a stable SSU ip address.

dr|z3d_ if that turns out to be the case, it might be worth exposing that in the UI.

zzz I can't find that option

dr|z3d private static final String PROP_DISABLE_PEER_TEST = "i2np.udp.disablePeerTest";

dr|z3d in PeerTestEvent.java

zzz not in my trunk

dr|z3d orly? I don't remember adding that myself, though it's not entirely out of the question.

dr|z3d If that's the case, then here's the rest of it:

dr|z3d private boolean shouldTest() {

dr|z3d String override = _context.getProperty(PROP_DISABLE_PEER_TEST);

dr|z3d if ("true".equalsIgnoreCase(override))

dr|z3d return false;

dr|z3d return ! (_context.router().isHidden() ||

dr|z3d _context.router().gracefulShutdownInProgress() ||

dr|z3d (_transport.isIPv4Firewalled() && _transport.isIPv6Firewalled()));

dr|z3d //String val = _context.getProperty(PROP_SHOULD_TEST);

dr|z3d //return ( (val != null) && ("true".equals(val)) );

dr|z3d }

dr|z3d that'll probably tell you if it's your code or mine :)

zzz all you bubba

dr|z3d chocolate star for me :)

dr|z3d anyways, I think it has the same net effect as always returning false as you suggested above, no? in which case, router is reporting status OK.

zzz so you already added a fix for your problem, forgot about it, and needed my help to find it again? please don't use me as support for your code )))

dr|z3d pfft

dr|z3d I doubt my issue is unique, there are probably plenty of people out there who experience the same issue and don't have a fix.