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.