Jamulus: Add support for IPv6

[tduboys]

Hi,
I'm trying to use Jamulus with my own dedicated server in both ipv4+ipv6 stack.

When I try to connect to the DNS with A and AAAA record, nothing happens. I dont see any packets sent from my client, and on my server (with wireshark).
When I use the IPv4 directly, all is working.
When I use the IPv6 directly, I see my client sending a lot of packets to 127.0.0.1:22124

Is there something wrong on my setup or on the client part regarding IPv6 ?

I'm using Jamulus 3.4.4 on Archlinux
Thanks

[corrados]

IPv6 is not supported by the Jamulus software. Just IPv4.

[corrados]

_This issue has been migrated from Sourceforge. Created: 2015-12-13
Creator: Volker Fischer_

Right now Jamulus only supports IP v4 in the protocol messages. As a results, a Jamulus server cannot be operated if the internet connection is IP v6 only.

Volker Fischer - 2020-03-11

Interestingly, I just tried out to register a Jamulus server on a internet connection which has IPv6 only and the registration succeeded. I have not yet an explaination for this behavior but it is good news that it works.

[gutobenn]

Hi, @corrados!
Could you provide more details about why IPv6 isn't supported?
I'm living in an area where almost everybody's IPv4 are behind CGNAT and isn't easy or cheap to find virtual private servers nearby.
We are interested in understading how much effort is needed to add IPv6 support. Maybe we could try to help on this implementation.

[corrados]

The Jamulus network protocol is completely IPv4 based. New protocol messages would have to be defined. Of course, somehow compatibility to old versions have to be preserved.
I am not sure if you start a Jamulus server on a pure IPv6 network, can a client which is connected via a IPv4 network access that server?
A lot of open questions... And I guess a lot of changes are needed to the Jamulus software to support IPv6 in a clean and compatible way.

[gutobenn]

Good news!

@lfzawacki and I got it working on IPv6 hosts using socat! :smiley:

I'm going to document it very soon. We've tested it only on Linux, but it seems socat can be installed on Mac and Windows too.

[biermanncarl]

@gutobenn Have you already done any documentation on how you did it?
I'm having the same issues with IPv4 being not available. IPv6 support would be really big for Jamulus.

[gutobenn]

1. Install socat on server and clients.
2. On the server, execute sudo socat UDP6-LISTEN:31476,fork UDP4:localhost:31478.
   It makes socat forward IPv6 packets from port 31476 to port 31478 (jamulus default) as IPv4 packets.
   I've choosed 31476, but you can use any other available port. Just don't forget to allow connections to this port on any firewall in your network (routers or computers) and to configure port forwarding in your router, if needed.
3. On the client, run sudo socat UDP4-LISTEN:31478,fork UDP6:[server_ipv6_here]:31476, replacing server_ipv6_here with the server IPv6 address.
   Then connect your Jamulus client to 127.0.0.1.

For debugging, you can execute socat with parameters '-d -d -d -d' and '-v'. Wireshark or similar might be very useful too.

If you want to connect a client to the server in the same LAN network, just use the server's local IPv4 address, like 192.168.0.13.

[streaps]

The Jamulus network protocol is completely IPv4 based. New protocol messages would have to be defined. Of course, somehow compatibility to old versions have to be preserved.

I'm not sure what part of an UDP protocol would be different on IPv6 or IPv4. As the socat experiment shows, this is not really true.

I think the additional IPv6 overhead is 20 byte per packet (with 2.5 ms packets -> 64kbps per stream).

[KnobbyCLARKE]

I have just been through the exercise of getting a Static IPv4 address from my ISP because otherwise mu private Server would not work because ISP uses CGNAT. It is only a matter of time before ISP "encourages" move to IPv6. I have a dual protocol Router but I do not want to have to stop using Jamulus because it does not support IPv6 and as a MacOS user I do not want to have to get involved with the underlying Unix. Please can we at least see some work being done on this issue.

[berndbb]

I just setup an IPV6-only Server just to discover, that I cannot use it for its main purpose: Jamulus. Bad Luck. _Of course, I would like to see IPv6 working._
I wouldn't mind setting up something like socat on the server (although I have to admit I would never have found this solution ...).

But my mates from our choir will surely ran away if things are getting even more complicated than installing asio-driver, a new unknown software Jamulus and typing strange letters into the server field.

[berndbb]

I just want to confirm that the "socat-method" from gutobenn (May 26th) worked on my ubuntu-server 20.04. I was able to connect from my home pc to a Jamulus Server running on the ubuntu instance which is only reachable via ipv6.

Maybe I have to supply a script for the users to let them connect with one click (by using the "Jamulus -c" option). Have to check for socat for windows first.

Does somebody know how to write such a start script for Mac-Devices?

[cbix]

I would like to request for a potential implementation to be able to choose between different A/AAAA records based on the ping (or manually).
Some servers I tested with have a route/ping difference of as much as 10ms between IPv4 and IPv6 and it might be desirable to regard that :)

[corrados]

have a route/ping difference of as much as 10ms between IPv4 and IPv6

Do you mean the IPv4 has higher or smaller delay compared to IPv6?

Is it consistent that one protocol version has always higher delay or is it dependend on the server so that sometimes IPv4 is faster and sometimes IPv6 is faster?

[cbix]

Do you mean the IPv4 has higher or smaller delay compared to IPv6?

It depends on the server. Actually on the datacenter + your ISP but in simple terms, host A can have 10 ms shorter ping over v4 while host B has 6 ms shorter ping over v6.

[drummer1154]

Only because today I discovered that servers on DS-Lite based internet connections (e.g. German m-net fiber) cannot be reached via IPv4 because they do not have a public IPv4 address assigned (so a Private Jamulus Server set up behind a router fed by DS-Lite (https://tools.ietf.org/html/rfc6333) cannot be reached from outside) I would like to ask the network protocol experts (@gene96817 ?) whether a quick solution to provide IPv6 support in Jamulus would be to use packet encapsulation (see https://tools.ietf.org/html/rfc2473 because I think that Lightweight 4over6 (https://tools.ietf.org/html/rfc7596) would be needed to be provided by the ISP). I am not a protocol guy but more a coder, so this is just guessing.

[gene96817]

IPv6 is very old. Finally, the Internet world is reaching the limits of delaying IPv6 with IPv4 tricks. If we want a quick solution, the best way is to ask DS-Lite what is their minimum IPv6 configuration. Then we would know the minimum amount of work to be compatible with DS-Lite.

[corrados]

I discovered that servers on DS-Lite based internet connections (e.g. German m-net fiber) cannot be reached via IPv4

That's interesting. My parents also have a fiber internet connection with DS-Lite and I can register a Jamulus server and also can connect to it from the outside. Maybe "DS-Lite" is not "DS-Lite", meaning that the providers maybe have some choices how to set it up.

[gene96817]

Most Internet providers try to support IPv4 for consumers and officially IPv4 addresses ran out a few years ago. More and more effort has gone into reclaiming and recycling IPv4 addresses. Eventually, it will really not be possible to have new (recycled) IPv4 addresses. It is more likely some parts of DS-Lite's network is now only IPv6. I would expect more and more parts of the Internet is only IPv6.

[cbix]

Not an expert with DS Lite but reaching a UDP port behind a NAT/firewall sound like a typical problem that can be solved with an external STUN server. Supporting this in Jamulus would make a different feature request though.

Took a quick look at the code and I believe the networking stack in Jamulus would need some refactoring anyway, but also for IPv6 support. There is a mix of Qt networking functions abstracting C sockets and vice-versa, address lookup using QHostInfo, then storing a QHostAddress but eventually creating a C socket (from only a port attribute) which needs a sockaddr_in for sendto ...

I don't know if the idea was to make it more efficient but it could at least be much simpler by either using only C sockets or Qt sockets, both of which can by themselves be completely transparent to the IP protocol. A client would do something like:

hints.ai_family = AF_UNSPEC;    /* Allow IPv4 or IPv6 */
hints.ai_socktype = SOCK_DGRAM; /* Datagram socket */
hints.ai_flags = 0;
hints.ai_protocol = 0;          /* Any protocol */
s = getaddrinfo("my.jamulus.server", "22124", &hints, &result);
// ...
for (rp = result; rp != NULL; rp = rp->ai_next) {
  sfd = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
  if (sfd == -1)
    continue;
    // here we could also have a concurrent ping check like the one in the server list
  if (connect(sfd, rp->ai_addr, rp->ai_addrlen) != -1)
    break;                  /* Success */

  close(sfd);
}
freeaddrinfo(result);
if (rp == NULL) {               /* No address succeeded */
  fprintf(stderr, "Could not bind\n");
  exit(EXIT_FAILURE);
}

// ... then after connecting simply use sendto/recvfrom with rp->ai_addr/ai_addrlen

Of course the server will also have to bind to IPv4 and IPv6 address ...

I don't have any experience with Qt but from the QUdpSocket docs it looks like a good alternative to raw C sockets!

[drummer1154]

@corrados

My parents also have a fiber internet connection with DS-Lite and I can register a Jamulus server and also can connect to it from the outside.

Is it possible to get the provider name? I would like to look up their AGBs and compare them to m-net's. And yes, I have read elsewhere that for DS-Lite the port mapping is not tightly specified so ISPs have room for different implementations.

On Monday afternoon prior to the rehearsal evening we got a private Jamulus server running on the iMac of our key/tp player, see https://github.com/corrados/jamulus/issues/756#issuecomment-737903152. The local Jamulus client on the same iMac could connect to the server (at 127.0.0.1) so it was possible to test audio. But it was not possible to get the server registered with the Jamulus central server. Also not possible was the attempt to set up a DynDns address. To me it appears that the fiber end point has a local DSLAM set up which provides private IPv4 addresses (192.168. 0.0/16) to the connected DSL routers (a FB 7430 provided by m-net in our case). So if we set up DynDns, the FB sends its private IPv4 to the DynDns server which is of course rejected. I believe the same happens with Jamulus central server.

Has anyone out there successfully set up a private Jamulus server on an m-net fiber based internet connection (<600 Mbit/s download)? If you have 600+ Mbit, you will also get a public IPv4 address assigned...

[gene96817]

@drummer1154 Not everything you describe makes sense to me. There are some gaps. I am now going into debugging mode. I apologize if some things are trivial to you.

1- The server is at a private IPv4 address. Did it get a full set of address configuration through DHCP? (gateway router and DNS address)? Were these addresses supposed to be manually configured? Failure to reach the central Jamulus server and DynDNS suggests a problem with these addresses. The ability to communicate with a client on the local network demonstrates the server and client software were installed correctly.

2- When the computers on the local network communicate to the Internet, the router AND the NAT function maps packets carrying the local address to the gateway router's external interface external IP address and a port. This internal/external address pairing (or mapping) is used to rewrite the packet addresses for inbound packets.

3- The host table at DynDNS will have the gateway router's (external port) address. You can manually set this entry to test inbound traffic. However, it does take time for the information to propagate from DynDNS to the global network of DNS servers. The rule of thumb is that it takes as much as two days.

4- One complication, if you are on an old DSL service, there could be an authentication step between your CPE and the DSLAM. This authentication protocol also carries the equivalent of DNS data for startup configuration. So there are two points of failure. (1) The authentication failed. (2) the router was not properly configured with the DNS server addresses (from authentication, or DNS protocol, or manually).

This is how it should work. As far as I can tell the only reason this description does not make sense is if another set of jargon is being used.

Let me know if my description does not help. It is always possible I forgot some detail not common in the USA.

[drummer1154]

@gene96817 Thanks for commenting, I have described a scenario which indeed might not be understandable outside Germany. The CPE (DSL modem + router) in use is a Fritz!Box 7430 (https://en.avm.de/service/fritzbox/fritzbox-7430/overview/) behind a fiber/DSL converter which uses DS-Lite (https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_(DS-Lite)). You can find an English blog entry describing a working IPv6 port forwarding in this scenario at https://klaus.hohenpoelz.de/mnet-ipv6-port-forwarding-fritzbox-7430.html - not so relevant for our problem but you can see what the CPE's GUI looks like.

I need to say again that I am not a network protocol expert. The information I have put above is a compilation of statements found in other forums - mostly in German, and a short research in Wikipedia and IETF RFC 6333. The result of the said discussions is that it is not possible to perform IPv4 port forwarding if you are connected via DS-Lite.

You already said that ISPs tend to provide both public IPv4 and IPv6 addresses to their clients, so-called Dual Stack. The problem with ISP m-net is that they only provide a public IPv6 address for download rates below 600 Mbit/s and handle IPv4 traffic via DS-Lite. They set up a DSL network local to a building, transforming the fiber traffic into DSL traffic. The local DSL modems (CPEs) get private IPv4 addresses via DHCP on the WAN interface (external port) and perform NAT to translate into the private IPv4 address LAN range set up by the router. (I do not currently know if they also get an IPv6 address - will research this - my current impression is that the fiber/DSL converter performs the encapsulation of the IPv4 packets into IPv6 packets.)

Maybe I was not clear enough: The CPE performs IPv4 NAT between two private IPv4 address ranges.

The problematic part is the so-called Carrier Grade NAT (CGN) which transforms the IPv6 encapsulated IPv4 traffic back into IPv4 traffic (a second NAT in the chain). I was not yet able to dig deeper into this, so for the time being I do not know how this CGN is supposed to work in more detail than given in Wikipedia as linked above.

Regarding DynDNS, as far as I understood, the CPE sends the WAN address to the DynDNS server (initially at service setup in the CPE and subsequently as soon as the WAN address changes). As we needed to use IPv4 with Jamulus, we created only an A record in the DynDNS server, so the server queries the CPE's IPv4 WAN address which is the private IPv4 address in the DSL network. This is rejected and the CPE displays an error message.

A few remarks in addition to your points:

1 - The iMac is set up correctly with DHCP and can communicate with the internet. It only cannot provide IPv4 port forwarding, so we cannot set up a private Jamulus server. Why registering the server with the Central Jamulus server did not work needs further investigation. Edit: If Volker's parents have the same ISP and connection setup then we clearly know that something is wrong in our configuration. /Edit

2 - Yes

3 - Yes; but the propagation appears to be much quicker here.

4 - I do not believe that we have this problem as internet access works fine except the described Jamulus server issue.

Cheers from Munich
Helmuth

[gene96817]

@drummer1154 What a mess. And you know a lot about these IPv4/IPv6 issues. Even if we both understand the issue, it will be difficult to explain to other Jamulus users. Take a step away from the details. Why not jus support IPv6 in Jamulus instead of trying to make IPv4 work through all these IPv4/IPv6 mappings. Doesn't Linux, MacOS, and Win10 already have enough IPv6 support for our needs? Are we trying too hard to keep using IPv4?

[cbix]

Are we trying too hard to keep using IPv4?

@gene96817 No, the current implementation is just a bit messy and intransparent to IP, but it requires some work to be fixed, so just be patient :) Or try to help refactoring the code ;)

[drummer1154]

I need to say that currently my 1st priority is to create a setup in which our band can rehearse with all 3 musicians being at home. We must live with the given ISPs (see https://github.com/corrados/jamulus/issues/756#issuecomment-737903152), and I do not see a better platform than Jamulus - also because there are a lot of discussions ongoing. I expicitly want to express my thanks to all contributing persons.

As a matter of fact Jamulus currently only works with IPv4, and DS-Lite does not support IPv4 port forwarding (simply because a single public IPv4 address is shared with multiple users/CPEs and therefore the external access to a specific CPE via (uniquely assigned) public IPv4 address and port number combination cannot work). The currently measured delays/latencies suggest to establish a server in the m-net environment, register with the central server, let the 2 other members connect and then de-register the server again so as to not be disturbed by anyone else (we need to rehearse our partially "sophisticated" arrangements and are not aimed at jamming).

I hope we can find a working setup and use the workaround above. I do not yet know how the registration with the central server works. When I enable "Make My Server Public", I think the local server initially contacts the central server (via IPv4), the "IPv4-in-IPv6 tunnel" should be established and then also the communication in the reverse direction is supposed to work.

Of course it would be great if Jamulus could be made "IPv6-ready" but I fear this will take time which we in our band do not really have ...

[gene96817]

@cbix Thank you and the rest of the team for working on Jamulus. I have discovered long ago that I am better at other task than coding.

@drummer1154 Sorry to hear you are stuck with this IPv4 mapping problem. It is a real mess. Would it be possible for you to create a IPv6 VPN tunnel for your Jamulus connections? Yes, this is another kludge. However, if you do this, your four Jamulus nodes (3 musicians plus server) will see IPv4. You will have four IPv4 devices (?) providing IPv6 VPN tunnels and your ISP will only see IPv6. Essentially you are creating a mini-CGN function totally under your control. (Alternative perspective, you are overlaying your own IPv6 network. Your NAT issues are simplified by supporting a small 4 node IPv4 network.)

[cbix]

@cbix Thank you and the rest of the team for working on Jamulus. I have discovered long ago that I am better at other task than coding.

I wish I had more free time for contributing to amazing projects like this, but so far I wasn't involved (yet) in any work on Jamulus – your thanks should go to @corrados ;)

[drummer1154]

@gene96817

Would it be possible for you to create a IPv6 VPN tunnel for your Jamulus connections?

Could you please help me setting up such a tunnel. What I tried is setting up a VPN connection between my CPE (https://avm.de/service/fritzbox/fritzbox-7580/uebersicht/ - page only available in German) and the keyboardist's (https://en.avm.de/service/fritzbox/fritzbox-7430/overview/) by configuring the VPN in both CPEs. We use the the manufacturer (AVM) service (https://sso.myfritz.net/) to resolve the symbolic addresses which are required to be entered in the CPE's VPN configuration panel.

But while my LAN can be accessed by the keyboardist, I cannot access his LAN. I always get a timeout error in the eventlog of my CPE. I think the reason is that AVM says: "The FRITZ!Box does not support IPv6 VPN connections since they cannot transmit IPv4 data." (https://en.avm.de/service/fritzbox/fritzbox-7430/knowledge-base/publication/show/1306_Can-a-FRITZ-Box-on-a-DS-Lite-internet-connection-be-used-for-VPN-connections/).

I think when we establish the VPN from the 7430, it uses my public IPv4 => access is possible. In the reverse direction (from my 7580) it does not work. However, what I do not understand is: Why can I not access the 7430 LAN, even while the 7430 has established the VPN connection to my 7580? If I deactivate the VPN configuration in my 7580 and ping the 7430 LAN I receive "Destination net unreachable." - obviously my CPE does not create a route back to the incoming VPN tunnel, and the connection is also lost from the 7430 (clear because the authentication is lost).

So I do not know how to go on...

[gene96817]

@drummer1154 Ok, now I regret my suggestion. LOL
I will look at the details but it will be spread out over some days. I hope Google translate will be good enough for the technical information. you can send me email at [email protected].