UDP routing issue

[pljones]

Hi all,

I've raised this in the past but always dropped it...

• The image on the left is mtr -f 2 93.42.88.44 - that is, it's a progressive ICMP ping trace route.
• The image on the right is mtr -f 2 -u -L 55859 -P 22124 93.42.88.44 - that is, much closer to the Jamulus protocol.

The IP and target port chosen here are visible and work on Jamulus Explorer

and the source port is open at my end. It's not just that host - if I run with showallservers, there's a lot of servers I see with empty ping:
.

There's clearly some issue between ip-plus.net and the target network. So what I'm looking for here are suggestions on how to work around that.

Any help gratefully received.

(Obviously, some servers are set up wrongly - that's clear on Jamulus Explorer. I'm not worried about those. However, the Rainbow boxes appear to be good, as do many of the others that don't return UDP pings.)

-- Peter

[ann0see]

Probably it would be worth contacting the people running servers which show this issue?

[ann0see]

I mean, I can't connect directly. Only if I "requested access" via the GUI and the Directory Server hole punching a Connection works. So I do suspect that it's a thing on their side.

[pljones]

I mean, I can't connect directly. Only if I "requested access" via the GUI and the Directory Server hole punching a Connection works. So I do suspect that it's a thing on their side.

Ahhh... Now that's interesting. I've never understood how the directory hole punch works... but my client will have the same IP address as the directory... just a different source port.

[pljones]

Ahh... right, so the "hole punch" says:

pConnLessProtocol->CreateCLSendEmptyMesMes ( siCurListEntry.HostAddr, InetAddr );

where siCurListEntry.HostAddr is the server address and InetAddr is the client address (requesting the server list).

So if and only if the server requires the hole punch, it will fail if InetAddr is on the same LAN as the directory. That's because the server will get told the LAN address of the client, which is useless!!

That does rather explain it.

Mmm... I think I might be able to fix that...

[pljones]

Nope, sadly my idea (i.e. "do what the directory server does - return zero") didn't work for the "fake client ping".

[pljones]

Of course, if the directory has --serverpublicip set, then it might work... Hm... I'll keep thinking about it.

[hoffie]

Maybe so-called Looking Glasses by several ISPs could help narrowing it down from several sides. I'm not sure though if you get to choose the UDP port there though.
https://looking.house/index.php seems to collect some of those instances, but I don't see a port option there. :(

[pljones]

I've raised #2818 to cover what I think the issue is - thanks to @ann0see for the poke in the right direction. I've a PR on its way with a workaround.

[ann0see]

I hope it's that.