Directory: Use configured Directory Public IP for Client when hole-punching

[pljones]

Short description of changes

Some Servers are inaccessible from a Client on the LAN of the Directory. This is because of how the "directory hole punch" works. We advertise this as a way of avoiding interfering with a router, to ease running a server. It works by sending a Jamulus message claiming to come from the client requesting the server list from the directory, to each server in the list.

However, where the client is on the same LAN as the directory, the source address for the client is the LAN address, not the public IP address which the server will subsequently receive. Hence the "hole punch" fails.

This change tries to make use of the directory public IP address, where that is explicitly known. (CHostAddress().InetAddr isn't enough - it needs to be set through --serverpublicip.) It avoids requiring a known value, however - it will simply continue failing as currently.

CHANGELOG: Directory: Use configured Directory Public IP for Client when hole-punching

Context: Fixes an issue?

Fixes: 2818 (#2818)

Does this change need documentation? What needs to be documented and how?

I would strongly suggest we review the documentation regarding the directory hole punch to make it clearer that there are known limitations in its effectiveness.

Status of this Pull Request

Genre Jazz is currently running with it. I can see most of the servers that were previously not working. The only one not working in my client is also not working in Jamulus Explorer. So I consider than 100% effective.

What is missing until this pull request can be merged?

Reviews.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[softins]

Will look at the code later, but just wanted to pick up on one part of the description:

It works by sending a Jamulus message claiming to come from the client requesting the server list from the directory, to each server in the list.

This is not accurate. The directory sends a Jamulus message to each listed server from itself (not claiming to be from the client). It is the content of the message that says "please send a message to <client>". When a server acts on that message by sending a message to the specified client, that has the effect of priming the server's NAT/firewall to accept subsequent messages from that client.

[pljones]

It works by sending a Jamulus message claiming to come from the client requesting the server list from the directory, to each server in the list.

This is not accurate. The directory sends a Jamulus message to each listed server from itself (not claiming to be from the client). It is the content of the message that says "please send a message to <client>". When a server acts on that message by sending a message to the specified client, that has the effect of priming the server's NAT/firewall to accept subsequent messages from that client.

Yep, I realised that on a re-read of the code and changed an "as" to back to "to". So there's a protocol message actually from the directory (and source address says so), actually to the server (dest address says so) carrying the address of the client requesting the server list. The server is then expected to send (i.e. "reply" but not a reply as such at all) a message to that address, opening its firewall to a response (which may never happen but would likely be the client connect dialogue asking for the ping time to the server).

[hoffie]

Logic seems good to me, but haven't run any tests. Should certainly wait for Tony's review now that he has offered it! :)

@pljones PR title/Changelog/Commit title could even more specific. Maybe
Directory: Use configured Public IP for Client when hole-punching?

[pljones]

https://jamulus.io/wiki/Custom-Directories (to be renamed, IIRC) should have an additional note added under "Points to note about Directories":

• When using a client on the same LAN as a directory, the directory itself needs to be run with the correct --serverpublicip value, so that any (non-LAN) servers registering with the directory that require the "hole punch" can be accessed by the LAN client(s). This is because otherwise the directory would provide the LAN address of the client to the server and the "hole punch" would fail.

Does that sound right?

[ann0see]

@gilgongo should judge that

[pljones]

And probably get confirmation I've got it clear from @softins, too 😄.

[softins]

I can't really test this, as it is particular to a rare scenario, such as that of @pljones. But the logic looks sound.

As I understand it, it only affects the unusual situation where a directory server is on the same LAN as the client, but the directory server has external servers registered to it via port forwarding. In this situation, it ensures that the IP address specified in the body of the message request sent to the remote servers is actually the public IP (assumed shared by the client and the directory), and not the LAN IP of the local client.

[pljones]

Running on all my directories (and servers) apart from updatecheck2.jamulus.io, which remains on latest.

[pljones]

jamulussoftware/jamuluswebsite#815 raised, so removing "Needs documentation" label.