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.
dr|z3d
ok
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.