@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+acetone
+dr|z3d
+hottuna
+postman
+weko
An0nm0n
Arch
FreefallHeavens
Hidenet1
Irc2PGuest19856
Irc2PGuest2827392
Irc2PGuest33877
Irc2PGuest62859
Irc2PGuest68850
Irc2PGuest95543
Leopold
Onn4l7h
Onn4|7h
Palimpsest
ProRu
Sleepy
Soni
T3s|4_
Teeed
aargh3
admin
anon
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme_
limak
not_bob_afk
orignal_
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
w8rabbit
x74a6
yourtrueself_
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.... ;)