Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for IPv6 #46

Closed
tduboys opened this issue Apr 8, 2020 · 54 comments
Closed

Add support for IPv6 #46

tduboys opened this issue Apr 8, 2020 · 54 comments
Labels
feature request Feature request

Comments

@tduboys
Copy link

tduboys commented Apr 8, 2020

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
Copy link
Contributor

corrados commented Apr 8, 2020

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

@corrados corrados changed the title IPv6 not working Add support for IPv6 Apr 12, 2020
@corrados
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

Good news!

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

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
Copy link

@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
Copy link

gutobenn commented May 26, 2020 •
edited
Loading

  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
Copy link

streaps commented May 27, 2020

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
Copy link

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
Copy link

berndbb commented Oct 23, 2020 •
edited
Loading

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
Copy link

berndbb commented Oct 23, 2020

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?

@jarmar jarmar mentioned this issue Nov 14, 2020
Closed
@cbix
Copy link

cbix commented Dec 6, 2020

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
Copy link
Contributor

corrados commented Dec 6, 2020

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
Copy link

cbix commented Dec 6, 2020

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
Copy link

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
Copy link

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
Copy link
Contributor

corrados commented Dec 8, 2020

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
Copy link

gene96817 commented Dec 8, 2020 •
edited
Loading

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
Copy link

cbix commented Dec 8, 2020

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
Copy link

@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 #756 (comment). 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
Copy link

@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
Copy link

drummer1154 commented Dec 10, 2020 •
edited
Loading

@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
Copy link

@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
Copy link

cbix commented Dec 10, 2020

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
Copy link

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 #756 (comment)), 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 ...

@jardous
Copy link
Contributor

jardous commented Feb 18, 2021

Hello guys, I have first version of the IPv6 support. Please take a look: jardous@68933a4

@jardous
Copy link
Contributor

jardous commented Feb 18, 2021

Testers welcome :) #1017

@bjacke
Copy link

bjacke commented Feb 18, 2021 via email •
edited
Loading

@bjacke
Copy link

bjacke commented Feb 18, 2021

Connecting to plain a IPv4 address is not working any more with that patch applied.
It also doesn't load the list of public servers.

@gilgongo gilgongo linked a pull request Feb 19, 2021 that will close this issue
IPv6 support #1017
Closed
@mstolle629
Copy link

Hello,
I just wrote a patch for Jamulus 3.7.0 in conjunction with linux, which enables dual-stack support.
As i am normally not a developer (i did that long ago), but have network background, i am not so experienced in github.

It is essential for the choir i am singing in and for friends to have ipv6 support working, because in our regions (near Frankfurt and Cologne) many people use internet providers which don't have native ipv4 support, but have "Dual stack lite" with ipv6 native and ipv4 only over a central NAT instance, which leads to problems with ipv4.

I have to keep backward compatiblity for jamulus and not disturb the registration on central server, therefore i decided to introduce a new option "ipmode", which defaults to ipv4 first and ipv6, if there is no ipv4 address for the server.
I introduced two command line option flags "-4" and "-6".
"-4 -6" = default
"-6 -4" = -v6 first, -4 (if there is no ipv6 support for the Hostname)
"-4" = ipv4 only
"-6" = ipv6 only

For backward compatiblity, the connection to the central registration server is done by ipv4 only.

I think, we should discuss, whether a registration for ipv6 on central server should be supported. My idea would be, to register the server twice, one time for ipv4 (as usual) and a second time with a Server name Postfix of "_v6" for ipv6.

I patched ParseNetworkAddress(), so that it supports the additional parameter of "ipmode" with default to "0", so that old sources with ipv4 only are supported.

I replaced sendto() and recvfrom() with sendmsg() and recvmsg(), added some setsockopts() at the start of a socket(), so that i can read the local ip address, which the client connected to, on the server, to choose the right ip address for the answer - i think, this is useful for ipv4 only, too. Therefore I added a field "LocalAddress" to Hostaddr.

I used "ipv4 mapped ipv4".
Shall i send you my patch - I never did a fork and pull request before, because i am not accustomed to github...

In addition, i do not have development platforms for Windows and Mac, therefore i don't know, how much work it is to get it run under Windows and Mac.

@mstolle629
Copy link

I just created a fork and replaced the files i edited. If you want to, someone could review it.
On the other hand, i can see in the sources, that there are differences caused by "delay panning", which i would love to have.

How can i merge both?

@cbix
Copy link

cbix commented Mar 31, 2021

@mstolle629 just open a Pull Request on this repo, that's the best way for others to review, discuss and to see the diff, update your branch etc. If you are not familiar with Git/GitHub basics, maybe this introduction helps :)

@gene96817
Copy link

@mstolle629 Are you distributing the server IPv6 address manually (i.e. out-of-band by email)? With the work you have done, it appears the biggest missing piece is supporting IPv6 in the central directory. Instead of having a server register twice, it would be good to extend the registration message to include (an optional) IPv6 address.

@mstolle629
Copy link

mstolle629 commented Mar 31, 2021 via email

@mstolle629
Copy link

My code just now doesn't work with windows (and possibly mac).
I sent my code to a friend in another choir in cologne for code review and adaptation to win/mac. He has a Windows Development environment and mac. He wanted to review the code over the easter holidays, so i'll wait with my pull request till next week. In that time, you can see my changes in my jamulus fork.

@gene96817
Copy link

I offer these opinions to forward the thinking.

Whether we register a server twice or once (with two addresses) has the same result, there is a table entry with two addresses.

It should be relatively simple to extend the registration process to be backward compatible.
Old clients continue to register IPv4 addresses. New clients would have a new protocol (extension) that registers two addresses.

To maintain backward compatibility, when a client request the server list, the directory assumes it is an old client and delivers the old IPv4 only list, When a new client request the server list, it indicates it is IPv6 capable and the directory delivers the server list with both IPv4 and IPv6 addresses.

The first benefit of IPv6 support will be some users will magically see lower overall delay when they automatically use IPv6 instead of the network-scale (IPv4) NAT.

@mstolle629
Copy link

mstolle629 commented Apr 1, 2021 via email

@gene96817
Copy link

but we need a solution, that a server or a client with ipv6 only can communicate.

This doesn't sound right. A server will have many clients that have only IPv4 addresses and a client will need to be able to access a server with only an IPv4 address. That is why there are carrier-scale NATs. For the most part, we already have clients and servers with only IPv6 assigned by their ISP but they are able to connect to the IPv4 Jamulus world through the carrier-scale NAT. (with occasional reports of problems).

it should get a list with servers supporting v6 on the one hand - and the other servers with ipv4 on the other hand.

I feel we are making things sound confusing. A server will be either IPv4-only or IPv4 & IPv6 (meaning they can be reached by either IPv4 or IPv6). Even a native IPv6 server will be reachable by IPv4 (because of the carrier-scale NAT). If there is an IPv6-only server listed that means all the IPv4 uses cannot reach the IPv6-only server. There would be a huge outcry.

A server with the new protocol has to signal that it supports v4, v6 & v4 - or v6 only, because the central server couldn't know that. Depending on that signal it is included in one or both of these lists.

I think this approach does not provide a smooth transition to IPv6. As mentioned in the previous point, for the near term, all IPv6 clients and servers also have the ability to communicate to IPv4 destinations. A server registering with the directory should (will always) know it's IPv4 address.

If one server registers ipv4 only - and another ipv6 only with the same name, what should happen?

The simple view is that:

  1. All the servers in the directory has an IPv4 address
  2. Some servers have both IPv4 and IPv6 addresses
  3. IPv4 clients would receive the full list of servers with only IPv4 addresses
  4. IPv6 clients would receive the full list of servers with both IPv4 and IPv6 addresses. (Its the coder's choice if the full list of servers is delivered with only one address, IPv6 if possible, IPv4 otherwise. I can't get excited about the difference in total bytes of the server table.)

@mstolle629
Copy link

mstolle629 commented Apr 1, 2021 via email

@mstolle629
Copy link

mstolle629 commented Apr 1, 2021 via email

@gene96817
Copy link

Separate registration events to allow the directory server to verify the address is a very good reason!

@hoffie
Copy link
Member

hoffie commented Apr 1, 2021

Registering twice is necessary in my eyes for security reasons. The central server needs to see the real ip address of the server, which wants to register itself. Otherwise it would be easily possible, that a bad server could register with wrong ip addresses - and disturb or attack the jamulus system.

Sadly, this is already possible, either by directly using the protocol, playing with strange local ip addresses or using command line flags.

So I'd say that this should not be the deciding criterion.

@mstolle629
Copy link

mstolle629 commented Apr 3, 2021 via email

@gene96817
Copy link

Sadly, this is already possible, either by directly using the protocol, playing with strange local ip addresses or using command line flags.

So I'd say that this should not be the deciding criterion.

I agree the current system is not secure. What would push us to need security in this area? The straightforward solution would be to require every server to have a valid cert (not a self-signed cert) and use IPSEC (part of IPv6). I expect a lot of allergic reactions to this kind of solution. Anything else might add a bit more security (through complexity) but adding complexity is not security

@mstolle629
Copy link

Hello, my version works now on Windows, Linux and Mac.
I have one possible regression, but this could be fixed easily:
I work with ipv6 mapped ipv4 addresses. If there is no ipv6 stack at all in the OS, jamulus might not work. This could be fixed easily in the init code of the socket. Shall i fix this before pull request - or shall i send a pull request first? In a second step, the protocol should be extended for central server support of ivp6 addresses.

@gilgongo gilgongo linked a pull request Apr 6, 2021 that will close this issue
Basic IPv6 support for Jamulus #1455
Closed
@ann0see
Copy link
Member

ann0see commented Aug 8, 2021 •
edited
Loading

Hi all, please have a look at #1938 for working direct connection IPv6 support.

@ann0see
Copy link
Member

ann0see commented Sep 5, 2021

Closing since #1950 is the next step to get towards full IPv6 support. Basic IPv6 support will be possible with v3.8.1 (and the -6 CLI flag)

@ann0see ann0see closed this as completed Sep 5, 2021
@pljones pljones removed a link to a pull request Feb 19, 2022
Basic IPv6 support for Jamulus #1455
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature request Feature request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

IPv6 support jardous/jamulus