[GH-ISSUE #174] IPv6 support disables IPv4

gitea-mirror commented

2026-05-05 05:22:00 -06:00

Owner

Originally created by @Malvineous on GitHub (Nov 10, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/174

The recent IPv6 support is great, however if you try to use it with dual-stack hosts you can run into problems.

This is because the client does a DNS lookup and connects to the first IP it gets. If the host has IPv4 and IPv6 addresses, as most will do, then sometimes the client will try to connect via IPv4 and sometimes via IPv6.

Since the server by default listens on IPv4 only, and with -a :: can listen on IPv6 only, it means that connections will intermittently be unreliable as clients randomly try to connect over IPv4 and IPv6, but the server is only listening on one protocol.

I see a few possible solutions:

By default listen on both 0.0.0.0 (IPv4) and :: (IPv6) so that the server can accept either connection.
Allow multiple -a options to be specified on the server, so you can do -a 0.0.0.0 -a :: to listen on both protocols at the same time.
Add the defacto standard options -4 and -6 to the client to force it to connect using a specific protocol, taking care to ensure a DNS lookup that returns multiple IP addresses has all of them checked if the first one doesn't match the requirements of the -4 or -6 options.

Steps to reproduce bug

Have a system set up so that host myserver returns two IP addresses:

$ host myserver
myserver.lan has address 1.2.3.4
myserver.lan has IPv6 address 2001:db8::1234

Connect to the server by hostname and observe random failures when the client picks a protocol that the server isn't listening on.

Originally created by @Malvineous on GitHub (Nov 10, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/174 The recent IPv6 support is great, however if you try to use it with dual-stack hosts you can run into problems. This is because the client does a DNS lookup and connects to the first IP it gets. If the host has IPv4 and IPv6 addresses, as most will do, then sometimes the client will try to connect via IPv4 and sometimes via IPv6. Since the server by default listens on IPv4 only, and with `-a ::` can listen on IPv6 only, it means that connections will intermittently be unreliable as clients randomly try to connect over IPv4 and IPv6, but the server is only listening on one protocol. I see a few possible solutions: 1. By default listen on both `0.0.0.0` (IPv4) and `::` (IPv6) so that the server can accept either connection. 2. Allow multiple `-a` options to be specified on the server, so you can do `-a 0.0.0.0 -a ::` to listen on both protocols at the same time. 3. Add the defacto standard options `-4` and `-6` to the client to force it to connect using a specific protocol, taking care to ensure a DNS lookup that returns multiple IP addresses has all of them checked if the first one doesn't match the requirements of the `-4` or `-6` options. ### Steps to reproduce bug ### 1. Have a system set up so that `host myserver` returns two IP addresses: ``` $ host myserver myserver.lan has address 1.2.3.4 myserver.lan has IPv6 address 2001:db8::1234 ``` 2. Connect to the server by hostname and observe random failures when the client picks a protocol that the server isn't listening on.

gitea-mirror

2026-05-05 05:22:01 -06:00

closed this issue
added the
bug

linux
labels

gitea-mirror commented

2026-05-05 05:22:07 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Dec 25, 2018):

I'm not so sure that :: is supposed to mean IPv6 only on dual-stack machines. At least on Linux, this behaviour is controlled with /proc/sys/net/ipv6/bindv6only.

@brianjmurrell commented on GitHub (Dec 25, 2018): I'm not so sure that `::` is supposed to mean IPv6 only on dual-stack machines. At least on Linux, this behaviour is controlled with `/proc/sys/net/ipv6/bindv6only`.

gitea-mirror commented

2026-05-05 05:22:10 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 26, 2018):

Interesting. Some research shows that this can be overridden by the application, the proc setting just controls the default value. On my system the proc entry is set to 0, meaning binding to :: should by default receive IPv4 and IPv6 connections, however IPv4 clients cannot connect.

@Malvineous commented on GitHub (Dec 26, 2018): Interesting. Some research shows that this can be overridden by the application, the `proc` setting just controls the default value. On my system the `proc` entry is set to `0`, meaning binding to `::` should by default receive IPv4 and IPv6 connections, however IPv4 clients cannot connect.

gitea-mirror commented

2026-05-05 05:22:13 -06:00

Author

Owner

@troxor commented on GitHub (Jan 21, 2019):

As a workaround, I set up Avahi to advertise the server's IPv4 address at hostname-of-server.local, and set up the barrier client to connect to that.

Edit: this was done on a Linux server, using a macOS client.

@troxor commented on GitHub (Jan 21, 2019): As a workaround, I set up Avahi to advertise the server's IPv4 address at hostname-of-server.local, and set up the barrier client to connect to that. Edit: this was done on a Linux server, using a macOS client.

gitea-mirror commented

2026-05-05 05:22:16 -06:00

Author

Owner

@brianjmurrell commented on GitHub (Jan 23, 2019):

To bring Barrier into the current century, I think it needs to be switched to listen on :: on Linux (and perhaps/probably OS/X). That will allow both IPv6 and IPv4 connections (depending on the setting of /proc/sys/net/ipv6/bindv6only on Linux, but I suspect most distros have that set to 0 at this point in time).

There is a doc that describes how to do the same thing for Windows.

Short of this, if a host is IPv6 capable, it should default to listening on IPv6 since the source address selection and DNS lookup priority (AAAA vs. A) typically default to prioritising IPv6 on most (all, current at least?) O/S these days and so a server defaulting to IPv4-only while a client can find AAAA records for the server will always fail to connect, particularly since barrierc doesn't seem to fall back to IPv4 if an IPv6 attempt returns an ECONNREFUSED.

Ultimately in dual-stack environments, the existing out-of-the-box (i.e. without the user having to twiddle) default behaviour of Barrier just doesn't work.

@brianjmurrell commented on GitHub (Jan 23, 2019): To bring Barrier into the current century, I think it needs to be switched to listen on `::` on Linux (and perhaps/probably OS/X). That will allow both IPv6 and IPv4 connections (depending on the setting of `/proc/sys/net/ipv6/bindv6only` on Linux, but I suspect most distros have that set to `0` at this point in time). There is a [doc](https://docs.microsoft.com/en-us/windows/desktop/winsock/dual-stack-sockets) that describes how to do the same thing for Windows. Short of this, if a host is IPv6 capable, it should default to listening on IPv6 since the source address selection and DNS lookup priority (AAAA vs. A) typically default to prioritising IPv6 on most (all, current at least?) O/S these days and so a server defaulting to IPv4-only while a client can find AAAA records for the server will always fail to connect, particularly since `barrierc` doesn't seem to fall back to IPv4 if an IPv6 attempt returns an ECONNREFUSED. Ultimately in dual-stack environments, the existing out-of-the-box (i.e. without the user having to twiddle) default behaviour of Barrier just doesn't work.

gitea-mirror commented

2026-05-05 05:22:19 -06:00

Author

Owner

@LovesTha commented on GitHub (Oct 2, 2020):

I think what I just experienced is related to this topic:

Had barrier working on a IPv4 network, moved the PCs to another office and it wasn't working. Put in the IPv4 address the server GUI told me it was listening on, didn't work. Checked the output of netstat -ln and saw it was listening on :: and not on v4 at all, switched the client to the IPv6 address and it worked.

At least displaying the right address in the GUI would make the experience a lot better.

@LovesTha commented on GitHub (Oct 2, 2020): I think what I just experienced is related to this topic: Had barrier working on a IPv4 network, moved the PCs to another office and it wasn't working. Put in the IPv4 address the server GUI told me it was listening on, didn't work. Checked the output of netstat -ln and saw it was listening on :: and not on v4 at all, switched the client to the IPv6 address and it worked. At least displaying the right address in the GUI would make the experience a lot better.

gitea-mirror commented

2026-05-05 05:22:23 -06:00

Author

Owner

@DanielGlaas commented on GitHub (Dec 11, 2020):

Hi,
by random I noticed this issues:
My setup is Ubuntu 20.04 as server and raspberry pi 4 as a client. I connected them with two methods:

Fritz!Box Wifi with both IPv4 and IPv6 support, both devices are connected to this network. --> Connection is done via IPv6.
Raspberry pi spans its own Wifi only supporting IPv4 and Ubuntu server connects to this network --> Connection is done via IPv4.

Switching the Ubuntu server between these two Wifis work flawless without any need to change something on the server side. On the client, I have two instances of barrierc running, one for each Wifi as the server gets assigned different IP addresses.

So the question is whether this is still a recent topic?

@DanielGlaas commented on GitHub (Dec 11, 2020): Hi, by random I noticed this issues: My setup is Ubuntu 20.04 as server and raspberry pi 4 as a client. I connected them with two methods: 1. Fritz!Box Wifi with both IPv4 and IPv6 support, both devices are connected to this network. --> Connection is done via IPv6. 2. Raspberry pi spans its own Wifi only supporting IPv4 and Ubuntu server connects to this network --> Connection is done via IPv4. Switching the Ubuntu server between these two Wifis work flawless without any need to change something on the server side. On the client, I have two instances of barrierc running, one for each Wifi as the server gets assigned different IP addresses. So the question is whether this is still a recent topic?

gitea-mirror commented

2026-05-05 05:22:26 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 11, 2020):

The issue for me is when you are on a network that supports IPv4 and IPv6, but some of the clients trying to connect only speak IPv4. It seems that when listening on IPv6, no IPv4 clients can connect.

@DanielGlaas Are you able to test that scenario?

@Malvineous commented on GitHub (Dec 11, 2020): The issue for me is when you are on a network that supports IPv4 and IPv6, but some of the clients trying to connect only speak IPv4. It seems that when listening on IPv6, no IPv4 clients can connect. @DanielGlaas Are you able to test that scenario?

gitea-mirror commented

2026-05-05 05:22:28 -06:00

Author

Owner

@DanielGlaas commented on GitHub (Dec 11, 2020):

@Malvineous:
I made a test with following configuration:

Ubuntu 20.04 server:

daniel@Daniel-Laptop:~$ ip addr show wlp4s0
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether a4:17:31:24:ff:87 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.26/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp4s0
valid_lft 848936sec preferred_lft 848936sec
inet6 2001:* :509d:325b/128 scope global dynamic noprefixroute
valid_lft 5370sec preferred_lft 1770sec
inet6 2001: :ce13:899f/64 scope global temporary dynamic
valid_lft 6258sec preferred_lft 2658sec
inet6 2001: :14e5:2ec3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 6258sec preferred_lft 2658sec
inet6 fe80:: *:509d:325b/64 scope link noprefixroute
valid_lft forever preferred_lft forever

rapsberry pi:
pi@raspberrypi:~ $ sudo sysctl net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1`
resulting to

pi@raspberrypi:~ $ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether dc:a6:32:12:d9:e2 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.21/24 brd 192.168.178.255 scope global dynamic wlan0
valid_lft 863710sec preferred_lft 863710sec

For me, this is a scenario where the network supports IPV4 and IPV6 but the client speaks only IPv4, right?

On the raspberry pi (client), barrierc is started witch this command line:
barrierc -f --name raspberrypi --enable-crypto 192.168.178.26
The connection works flawless, even if I start and stop the server process, reconnection works within seconds.

For debugging, here is the netstat output of server and client:

Ubuntu server:
Why is there written tcp6 although it is connected via IPv4?

daniel@Daniel-Laptop:~$ sudo netstat -tnp -W | grep barrier
tcp6 0 0 192.168.178.26:24800 192.168.178.21:56678 VERBUNDEN 32916/barriers

raspberry pi client

pi@raspberrypi:~ $ sudo netstat -tnp -W | grep barrier
tcp 0 0 192.168.178.21:56678 192.168.178.26:24800 VERBUNDEN 1311/barrierc

Is this helpful for you?

@DanielGlaas commented on GitHub (Dec 11, 2020): @Malvineous: I made a test with following configuration: - Ubuntu 20.04 server: > daniel@Daniel-Laptop:~$ ip addr show wlp4s0 3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether a4:17:31:24:ff:87 brd ff:ff:ff:ff:ff:ff inet 192.168.178.26/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp4s0 valid_lft 848936sec preferred_lft 848936sec inet6 2001:* *:509d:325b/128 scope global dynamic noprefixroute valid_lft 5370sec preferred_lft 1770sec inet6 2001:* *:ce13:899f/64 scope global temporary dynamic valid_lft 6258sec preferred_lft 2658sec inet6 2001:* *:14e5:2ec3/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 6258sec preferred_lft 2658sec inet6 fe80::* *:509d:325b/64 scope link noprefixroute valid_lft forever preferred_lft forever - rapsberry pi: `pi@raspberrypi:~ $ sudo sysctl net.ipv6.conf.all.disable_ipv6=1` `net.ipv6.conf.all.disable_ipv6` = 1` resulting to > pi@raspberrypi:~ $ ip addr show wlan0 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether dc:a6:32:12:d9:e2 brd ff:ff:ff:ff:ff:ff inet 192.168.178.21/24 brd 192.168.178.255 scope global dynamic wlan0 valid_lft 863710sec preferred_lft 863710sec For me, this is a scenario where the network supports IPV4 and IPV6 but the client speaks only IPv4, right? On the raspberry pi (client), barrierc is started witch this command line: `barrierc -f --name raspberrypi --enable-crypto 192.168.178.26` The connection works flawless, even if I start and stop the server process, reconnection works within seconds. For debugging, here is the netstat output of server and client: - Ubuntu server: Why is there written tcp6 although it is connected via IPv4? >daniel@Daniel-Laptop:~$ sudo netstat -tnp -W | grep barrier tcp6 0 0 192.168.178.26:24800 192.168.178.21:56678 VERBUNDEN 32916/barriers - raspberry pi client > pi@raspberrypi:~ $ sudo netstat -tnp -W | grep barrier tcp 0 0 192.168.178.21:56678 192.168.178.26:24800 VERBUNDEN 1311/barrierc Is this helpful for you?

gitea-mirror commented

2026-05-05 05:22:30 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 12, 2020):

Very helpful! The only thing missing is netstat -lnp | grep barrier on the server to verify it is listening on IPv6 and not choosing IPv4 only. And it would be useful to compare that to running the server with the -a :: parameter to specifically say you want to listen on all IPv6 interfaces (which should still result in it receiving IPv4 connections through the IPv6 port, but where my set up was failing).

That would confirm it for sure, but it does seem like it may indeed be working now.

@Malvineous commented on GitHub (Dec 12, 2020): Very helpful! The only thing missing is `netstat -lnp | grep barrier` on the server to verify it is listening on IPv6 and not choosing IPv4 only. And it would be useful to compare that to running the server with the `-a ::` parameter to specifically say you want to listen on all IPv6 interfaces (which should still result in it receiving IPv4 connections through the IPv6 port, but where my set up was failing). That would confirm it for sure, but it does seem like it may indeed be working now.

gitea-mirror commented

2026-05-05 05:22:32 -06:00

Author

Owner

@DanielGlaas commented on GitHub (Dec 13, 2020):

Very helpful! The only thing missing is netstat -lnp | grep barrier on the server to verify it is listening on IPv6 and not choosing IPv4 only.

Here is my output of 'ps -aux | grep barrier' on the server:

/usr/bin/barriers -f --no-tray --debug INFO --name Daniel-Laptop --enable-crypto -c /home/daniel/synergy_raspi.conf --address :24800

Note: I first made a setup with synergy on Ubuntu 18.04 on the server. But after upgrading to Ubuntu 20.04 barrier became my new choice and the configuration file stills works unchanged. :-)
The corresponding output of netstat -lnp | grep barrier with no connected client is:

tcp6 0 0 :::24800 :::* LISTEN 43327/barriers

And it would be useful to compare that to running the server with the -a :: parameter to specifically say you want to listen on all IPv6 interfaces (which should still result in it receiving IPv4 connections through the IPv6 port, but where my set up was failing).

I changed the parameters to /usr/bin/barriers -f --no-tray --debug INFO --name Daniel-Laptop --enable-crypto -c /home/daniel/synergy_raspi.conf **--address ::** with this result of netstat -lnp | grep barrier

tcp6 0 0 :::24800 :::* LISTEN 43573/barriers

You see the new PID, but despite of this nothing changed.

That would confirm it for sure, but it does seem like it may indeed be working now.

I think so, yes!

@DanielGlaas commented on GitHub (Dec 13, 2020): > Very helpful! The only thing missing is `netstat -lnp | grep barrier` on the server to verify it is listening on IPv6 and not choosing IPv4 only. Here is my output of 'ps -aux | grep barrier' on the server: > /usr/bin/barriers -f --no-tray --debug INFO --name Daniel-Laptop --enable-crypto -c /home/daniel/synergy_raspi.conf **--address :24800** Note: I first made a setup with synergy on Ubuntu 18.04 on the server. But after upgrading to Ubuntu 20.04 barrier became my new choice and the configuration file stills works unchanged. :-) The corresponding output of `netstat -lnp | grep barrier` with no connected client is: > tcp6 0 0 :::24800 :::* LISTEN 43327/barriers > And it would be useful to compare that to running the server with the `-a ::` parameter to specifically say you want to listen on all IPv6 interfaces (which should still result in it receiving IPv4 connections through the IPv6 port, but where my set up was failing). I changed the parameters to `/usr/bin/barriers -f --no-tray --debug INFO --name Daniel-Laptop --enable-crypto -c /home/daniel/synergy_raspi.conf **--address ::**` with this result of `netstat -lnp | grep barrier` > tcp6 0 0 :::24800 :::* LISTEN 43573/barriers You see the new PID, but despite of this nothing changed. > That would confirm it for sure, but it does seem like it may indeed be working now. I think so, yes!

gitea-mirror commented

2026-05-05 05:22:34 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 27, 2020):

Thanks so much for testing! I'm going to close this now as clearly it is working the way it should.

@Malvineous commented on GitHub (Dec 27, 2020): Thanks so much for testing! I'm going to close this now as clearly it is working the way it should.

gitea-mirror commented

2026-05-05 05:22:37 -06:00

Author

Owner

@DanielGlaas commented on GitHub (Dec 27, 2020):

Thanks so much for testing! I'm going to close this now as clearly it is working the way it should.

Your are welcome, I like to contribute something at least by testing some circumstances. Please feel free to contact me if there is anything else that needs to be tested!

@DanielGlaas commented on GitHub (Dec 27, 2020): > Thanks so much for testing! I'm going to close this now as clearly it is working the way it should. Your are welcome, I like to contribute something at least by testing some circumstances. Please feel free to contact me if there is anything else that needs to be tested!

Rows
Columns

[GH-ISSUE #174] IPv6 support disables IPv4 #141

Steps to reproduce bug