IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/01/29
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+goose2_
+hagen
+orignal
+postman
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
FreefallHeavens
Irc2PGuest48909
Irc2PGuest69244
Irc2PGuest71836
Nausicaa
Onn4l7h
SoniEx2
T3s|4_
Teeed
anon2
b3t4f4c3__
bak83_
boonst
cumlord
dolphinandcat
dr4wd3
eyedeekay_bnc
goose2
hk
itsjustme
j6
numberwang
onon_1
poriori
profetikla
qend-irc2p
rapidash
shiver_
u5657
unwr
user
veiledwizard
w8rabbit
x74a6
orignal zzz, a question
orignal if we receive different port in SessionCreated but peer test passes what status should we set?
zzz orignal, we wait for two peers to tell us the same ip/port, then do two new peer tests that have the same result, then change status if necessary
zzz so only peer test changes status, but some things trigger peer test to run earlier than scheduled
orignal the thing is that out port is reachable so peer test says "OK"
orignal or what we do with peer test 6 and 7?
orignal I just don't understand what is right status is this case
orignal from one side our port is reachable
orignal from another side our UDP is malfunctioning
zzz we don't "trust" the session created from one peer. we always do peer test if it looks like something changed
orignal so you just ignore it
dr|z3d it's tested and marked as "not right" if it fails the tests.
dr|z3d I don't recall if it gets the banhammer, but it may do.
orignal but it doesn't fail the test
orignal all tests pass
orignal but port is different for some outgoing sessions
dr|z3d is this a specific router, or behavior you're seeing regularly?
orignal a guy just compained
T3s|4 zzz: finally had time to read your Blocking Wireguard post today - nice work. Not sure if you know Jason, but I'd bet he would be interested in an exchange with you. He's frequently about and quite responsive as 'zx2c4' in #wireguard on Libera
dr|z3d that seems pretty suspect, orignal, no? or you have a plausible theory why a router might be varying the port inconsistently?
orignal <onon> SSU2: Our external address is 12.345.67.890:44502
orignal <onon> SSU2: Our port 44502 received from 98.76.54.321:27805 is different from 12345
orignal looks like his ISP replacesthe prot
dr|z3d that's possible, detecting the traffic as p2p and attempting to thwart it. dunno.
orignal fine. but my questuin is what WE do
orignal still consider as OK?
dr|z3d if peer changes port, repeat tests.
dr|z3d <zzz> orignal, we wait for two peers to tell us the same ip/port, then do two new peer tests that have the same result, then change status if necessary
orignal but it's our port
orignal beside wrong port all peer tests are fine
orignal e.g peer test 5 is coming to port 12345
dr|z3d so the peer's sending traffic to not-our-correct-port, but his port is fine and doesn't vary?
orignal his port is fine, he see us from different port
orignal he send back to that port and it reaches us
orignal although it's OK accoridng to the peer test
orignal but our network is definitly not good
dr|z3d that sounds a bit like a hole punch scenario.
orignal yes, especially for test 5
orignal it makes a hole puch and our port is right for test 6
dr|z3d you'll have to wait for zzz for a definitive answer, but my hunch is mark it as firewalled.
orignal but accroding to zzz's description it will be OK
dr|z3d if a router can't talk to me on my advertised port and is talking to me via a hole punch on their port, then they're firewalled, even if we can see their open advertised port, no?
dr|z3d unless there's something I'm missing.
orignal but you can also reach their port
dr|z3d right.
dr|z3d but if they're not able to send outbound traffic on their port, then there's something that's not quite "OK" going on.
orignal but I can
orignal that's the problem
orignal the only issue that other peers see my port different that I publish
orignal and might not like it
dr|z3d sure, or it could be a misbehaving router/firewall/isp.
orignal let's wait zzz
orignal I would suggest to keep publishing addresses but wihtout R
orignal technically internally the status in "Unknown"
dr|z3d sure, that's more or less the same as firewalled or U, but not quite. in the gray zone somewhere :)
zzz you have inconsistent data, use whatever heuristic or rule you want to make a decision
zzz two in a row, best 2 out of 3, or some data's better than others. whatever
zzz nothing's perfect, the other guy could be lying, the other guy could be sym natted, the other guy could have bugs
dr|z3d it is worth introducing a new flag in the netdb to account for the gray zone?
dr|z3d I was thinking specifically a "V" flag for volatile.
zzz no R and no U = "I don't know". That's the way it is now. Don't need more flags.
zzz but you should never let one peer change your state
zzz T3s|4, thanks, I don't know the wireguard folks, I doubt they need any advice from me, they ofc know what WG does and does not do. you can tell them thanks from i2p ))
T3s|4 noted zzz - and in case you didn't know already, Jason, in addition to WG, also wrote/coded 'pass': passwordstore.org :)
dr|z3d zzz: can you voice Titlacahuan, he'd like to chime in about the gray zone.