@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+eche|off
+orignal
+postman
+snex
+wodencafe
Arch
BubbRubb
Chrono
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest16752
Irc2PGuest33667
Irc2PGuest51880
Irc2PGuest97218
Onn4l7h
RN_
Sisyphus
Sleepy_
Teeed
aargh2
ac9f_
b3t4f4c3__
b4dab00m
bak83_
duanin2
eyedeekay_
john231
leopold
makoto
nilbog-
not_bob_afk
poriori_
profetik1
r00tobo_BNC
rapidash
shiver_
solidx66
thetia
tr
u5657
uop23ip
vivid_reader56
w8rabbit
x74a6
xHarr
zzz
good news, found the cause of the network instability
dr|z3d
what's causing the chaos, zzz?
dr|z3d
and followup question. is a fix imminently being pushed to git? :)
zzz
i2pd bug
dr|z3d
can it be mitigated?
zzz
they pushed a fix last night
dr|z3d
so we have to wait for the i2pd contingent of the network to upgrade?
zzz
I'm working on mitigations on our side
dr|z3d
well, you found the bug, that's a good start. what's i2pd doing that's breaking things?
zzz
dropping large amounts of msgs rcvd over SSU
dr|z3d
*** throws some of jrandom's tomatoes at orignal ***
dr|z3d
so that wip patch you've got going on.. is that part of the mitigation strategy, and is it likely to land before next release?
zzz
no and no
zzz
just need to avoid SSU and avoid them in tunnels
dr|z3d
i2np.maxConnections=0 ?
dr|z3d
* i2np.udp.maxConnections=0
zzz
no, just avoid ssu for i2pd
dr|z3d
so you're probing routers to establish whether they're running i2pd then?
zzz
you'll have the fix when I have it
dr|z3d
thanks :) I'm not proposing or even contemplating a fix myself, beyond my paygrade, just trying to establish the scope of the issue.
dr|z3d
any ideas why a router that's definitely not firewalled repeatedly keeps using introducers and needs constant supervision?
dr|z3d
toggle udp and it magically finds it's not firewalled, all the time nothing in event logs, and no indication in the sidebar it's got issues.
dr|z3d
what's all the more odd is that ntcp2 is fine all the while.
dr|z3d
could it be that a peer is blocked at the local firewall, assumes the local router is therefore firewalled, and arranges introducers?
dr|z3d
*assumes that the remote router (ie my router)
zzz
peer testing is not perfect. ipv6 especially
dr|z3d
ipv6 is disabled. and yet it still gets tested, apparently.
zzz
shouldn't
dr|z3d
yeah, that's what I thought.
dr|z3d
Reachability changeFirewalled ➜ IPv4: OK; IPv6: Firewalled
dr|z3d
Reachability changeOK ➜ Firewalled
dr|z3d
something not right going on.
dr|z3d
If the "Disable IPv6" radio is selected, "Disable Inbound (firewalled)" should probably be disabled on submit.
dr|z3d
I don't know if there's a bad interaction between those two options.. possible.
dr|z3d
anyways, if a router is configured as "not firewalled", it should refuse introducers.
dr|z3d
on a related note, there appears to be a bug when disabled and re-enabling udp.. local tunnels aren't closed properly, so you can end up with half a dozen or more of each local tunnel indicated in the sidebar.
dr|z3d
and apparently repeatedly doing that will break graphing, too!
zzz
git.idk.i2p is standing by ready to accept your bug reports :)
dr|z3d
:)
zzz
workarounds pushed
dr|z3d
woop woop!
dr|z3d
skank.i2p/dev/i2pupdate.zip has zzz's buggy i2pd workarounds patch.
RN
"Nicely" worded dr. Heh, that makes the patch sound buggy. (Which I'm prety sure it is not.)
RN
either that or the patch has riders and a horse.
dr|z3d
context, RN :)
dr|z3d
but you're right, zzz's workaround for a buggy i2pd would have been more correct. :)
dr|z3d
or zzz's "buggy i2pd workaround" patch. or something.
RN
important thing is bug found and squashed. Thanks zzz!
RN
speaking of...
dr|z3d
it's only squashed when the network's upgraded. until then, it'll continue to cause network instability.
RN
once enough of the I2PDeerps update.... ;)