[GH-ISSUE #32] IPv6 Connections refused to Linux server

gitea-mirror commented

2026-05-05 04:47:11 -06:00

Owner

Originally created by @ramesh45345 on GitHub (Apr 27, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/32

Referencing issue #18, when connecting to an Ubuntu 18.04 server running barriers (git master 0b5ca57b), a Fedora 27 client (same barrier version) connecting via IPv6 (resolved from the avahi hostname resolution as well as router hostname resolution) receives a connection refused message. Both the server and client are using SSL, and both work fine when an IPv4 address is hard-coded. The following log is generated on the client (Fedora 27):

[2018-04-27T08:48:15] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:15] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839
[2018-04-27T08:48:15] WARNING: failed to connect to server: Connection refused
	/var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301
[2018-04-27T08:48:16] NOTE: connecting to 'rkrishna-pc': fd5b:88e:f3e5::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:16] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839
[2018-04-27T08:48:16] WARNING: failed to connect to server: Connection refused
	/var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301
[2018-04-27T08:48:17] INFO: stopping barrier desktop process
[2018-04-27T08:48:17] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800
	/var/tmp/barrier/src/lib/client/Client.cpp,146
[2018-04-27T08:48:17] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839

The following log is generated on the server running Ubuntu 18.04 (basically nothing, since the server doesn't hear anything from the client):

[2018-04-27T08:46:54] INFO: starting server
[2018-04-27T08:46:54] INFO: config file: /tmp/Barrier.h26056
[2018-04-27T08:46:54] INFO: log level: INFO
[2018-04-27T08:46:54] NOTE: started server, waiting for clients
	/var/tmp/barrier/src/lib/barrier/ServerApp.cpp,540

Note: The openssl version on the server is as follows:

[2018-04-27T08:48:17] INFO: OpenSSL 1.1.0g  2 Nov 2017
	/var/tmp/barrier/src/lib/net/SecureSocket.cpp,839

Operating Systems

Server: Ubuntu 18.04
Client: Fedora 27
Both updated to latest software from repositories.

Barrier Version

git master 0b5ca57b, compiled on their respective machines. After upgrading to Ubuntu 18.04, barrier was recompiled as a precaution.

Steps to reproduce bug

On the client, either specify an IPv6 address for the server (this I didn't test), or use a hostname which resolves to an IPv6 address first through avahi or router name resolution (this was used in my case).
Ensure SSL is enabled on both the client and server.
Ask the client to connect. The client will not be able to connect, saying connection refused.
Replace the IPv6 address with an IPv4 address.
Connection will work properly.

Other info

Bug doesn't prevent me from using barrier, however it is inconvenient since hostname resolution is IPv6 first on all my networks, and then IPv4. As a workaround, I'm not sure if barrier can ask for an IPv6 address first from avahi, and then an IPv4 address?

Originally created by @ramesh45345 on GitHub (Apr 27, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/32 Referencing issue #18, when connecting to an Ubuntu 18.04 server running barriers (git master 0b5ca57b), a Fedora 27 client (same barrier version) connecting via IPv6 (resolved from the avahi hostname resolution as well as router hostname resolution) receives a connection refused message. Both the server and client are using SSL, and both work fine when an IPv4 address is hard-coded. The following log is generated on the client (Fedora 27): ``` [2018-04-27T08:48:15] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800 /var/tmp/barrier/src/lib/client/Client.cpp,146 [2018-04-27T08:48:15] INFO: OpenSSL 1.1.0h-fips 27 Mar 2018 /var/tmp/barrier/src/lib/net/SecureSocket.cpp,839 [2018-04-27T08:48:15] WARNING: failed to connect to server: Connection refused /var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301 [2018-04-27T08:48:16] NOTE: connecting to 'rkrishna-pc': fd5b:88e:f3e5::f2f:24800 /var/tmp/barrier/src/lib/client/Client.cpp,146 [2018-04-27T08:48:16] INFO: OpenSSL 1.1.0h-fips 27 Mar 2018 /var/tmp/barrier/src/lib/net/SecureSocket.cpp,839 [2018-04-27T08:48:16] WARNING: failed to connect to server: Connection refused /var/tmp/barrier/src/lib/barrier/ClientApp.cpp,301 [2018-04-27T08:48:17] INFO: stopping barrier desktop process [2018-04-27T08:48:17] NOTE: connecting to 'rkrishna-pc': 2601:cb:8100:9400::f2f:24800 /var/tmp/barrier/src/lib/client/Client.cpp,146 [2018-04-27T08:48:17] INFO: OpenSSL 1.1.0h-fips 27 Mar 2018 /var/tmp/barrier/src/lib/net/SecureSocket.cpp,839 ``` The following log is generated on the server running Ubuntu 18.04 (basically nothing, since the server doesn't hear anything from the client): ``` [2018-04-27T08:46:54] INFO: starting server [2018-04-27T08:46:54] INFO: config file: /tmp/Barrier.h26056 [2018-04-27T08:46:54] INFO: log level: INFO [2018-04-27T08:46:54] NOTE: started server, waiting for clients /var/tmp/barrier/src/lib/barrier/ServerApp.cpp,540 ``` Note: The openssl version on the server is as follows: ``` [2018-04-27T08:48:17] INFO: OpenSSL 1.1.0g 2 Nov 2017 /var/tmp/barrier/src/lib/net/SecureSocket.cpp,839 ``` ### Operating Systems ### Server: Ubuntu 18.04 Client: Fedora 27 Both updated to latest software from repositories. ### Barrier Version ### git master 0b5ca57b, compiled on their respective machines. After upgrading to Ubuntu 18.04, barrier was recompiled as a precaution. ### Steps to reproduce bug ### 1. On the client, either specify an IPv6 address for the server (this I didn't test), or use a hostname which resolves to an IPv6 address first through avahi or router name resolution (this was used in my case). 2. Ensure SSL is enabled on both the client and server. 3. Ask the client to connect. The client will not be able to connect, saying connection refused. 4. Replace the IPv6 address with an IPv4 address. 5. Connection will work properly. ### Other info ### Bug doesn't prevent me from using barrier, however it is inconvenient since hostname resolution is IPv6 first on all my networks, and then IPv4. As a workaround, I'm not sure if barrier can ask for an IPv6 address first from avahi, and then an IPv4 address?

gitea-mirror

2026-05-05 04:47:11 -06:00

closed this issue
added the
bug

help wanted
labels

gitea-mirror commented

2026-05-05 04:47:16 -06:00

Author

Owner

@walker0643 commented on GitHub (Apr 28, 2018):

HI @ramesh45345 -

This is a very well-written bug report. Thank you! We're currently short on IPv6 developers but I've asked a couple people to have a look at this. Hopefully we can get you up and running shortly. Stay tuned!

@walker0643 commented on GitHub (Apr 28, 2018): HI @ramesh45345 - This is a very well-written bug report. Thank you! We're currently short on IPv6 developers but I've asked a couple people to have a look at this. Hopefully we can get you up and running shortly. Stay tuned!

gitea-mirror commented

2026-05-05 04:47:20 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 28, 2018):

If it helps any, I know IPv6 works on barrier, I have my server bound to ::1. (client remote port-forwards connection over SSH and connects). I could also test to see if synergy connects of a /127 prefix IPv6 address. I would test over a normal /64 but my ISP has broken DHCPv6-PD and I haven't called them to fix it, and too lazy to setup an internal /64

@AdrianKoshka commented on GitHub (Apr 28, 2018): If it helps any, I know IPv6 works on barrier, I have my server bound to `::1`. (client remote port-forwards connection over SSH and connects). I could also test to see if synergy connects of a `/127` prefix IPv6 address. I would test over a normal `/64` but my ISP has broken DHCPv6-PD and I haven't called them to fix it, and too lazy to setup an internal `/64`

gitea-mirror commented

2026-05-05 04:47:22 -06:00

Author

Owner

@ramesh45345 commented on GitHub (Apr 29, 2018):

Thanks a bunch @walker0643 . I think this should be easily reproducible, I have another set of machines using barrier (Ubuntu 18.04 on the client, and Fedora 27 on the server, the reverse of my bug report above), and seem to have the same problem. Connection refused when I use the avahi IPv6 autoconfigured address. @AdrianKoshka , what git revision of barrier are you using (or released version, if applicable)? Perhaps I should test an older version and see if I have the same problem.

@ramesh45345 commented on GitHub (Apr 29, 2018): Thanks a bunch @walker0643 . I think this should be easily reproducible, I have another set of machines using barrier (Ubuntu 18.04 on the client, and Fedora 27 on the server, the reverse of my bug report above), and seem to have the same problem. Connection refused when I use the avahi IPv6 autoconfigured address. @AdrianKoshka , what git revision of barrier are you using (or released version, if applicable)? Perhaps I should test an older version and see if I have the same problem.

gitea-mirror commented

2026-05-05 04:47:27 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 29, 2018):

Release 2.0.0 @ramesh45345

@AdrianKoshka commented on GitHub (Apr 29, 2018): Release `2.0.0` @ramesh45345

gitea-mirror commented

2026-05-05 04:47:30 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 29, 2018):

So I tested with this setup and it worked (used SSL):

server: ::40/127 Fedora 27
client: ::41/127 Debian 9 stretch

Of course, I sepcified the IPv6 address(es) for both client and server in my systemd template user unit.

Replication

If you want a quick and dirty way to replicate what I did.

Server:

sudo ip addr add dev enp1s0 ::40/127 (replace enp1s0 with your interfaces' name)
barriers --address ::40 --enable-crypto --no-restart --no-daemon --config /path/to/your/config

Client:

sudo ip addr add dev enp2s0 ::41/127 (replace enp2s0 with your intefaces' name)
barrierc --enable-crypto --no-restart --no-daemon ::40

Cleanup:

kill barriers and barrierc
sudo ip addr del dev enp1s0 ::40/127 (replace ::40 with ::41 on the client, and enp1s0 with your intefaces' name)

@AdrianKoshka commented on GitHub (Apr 29, 2018): So I tested with this setup and it worked (used SSL): - server: `::40/127` Fedora 27 - client: `::41/127` Debian 9 stretch Of course, I sepcified the IPv6 address(es) for both client and server in my systemd template user unit. - [`barriers@::40.service`](https://github.com/AdrianKoshka/config/blob/master/.config/systemd/user/barriers%40.service) - [`barrierc@::40.service`](https://github.com/AdrianKoshka/config/blob/master/.config/systemd/user/barrierc%40.service) ## Replication If you want a quick and dirty way to replicate what I did. ### Server: 1. `sudo ip addr add dev enp1s0 ::40/127` (replace `enp1s0` with your interfaces' name) 2. `barriers --address ::40 --enable-crypto --no-restart --no-daemon --config /path/to/your/config` ### Client: 1. `sudo ip addr add dev enp2s0 ::41/127` (replace `enp2s0` with your intefaces' name) 2. `barrierc --enable-crypto --no-restart --no-daemon ::40` ## Cleanup: 1. kill `barriers` and `barrierc` 2. `sudo ip addr del dev enp1s0 ::40/127` (replace `::40` with `::41` on the client, and `enp1s0` with your intefaces' name)

gitea-mirror commented

2026-05-05 04:47:32 -06:00

Author

Owner

@ramesh45345 commented on GitHub (May 8, 2018):

@AdrianKoshka Thanks for the insight, I should have tested the CLI apps before. I have tested IPv6 and it seems to work when I call it from the command line for git version 5e19820 (which is the closest to 2.0.0), as well as master (b43581c). I am using the below command for the server (Fedora 28):

barriers --address fd7f:7549:7489::2cc --enable-crypto --no-restart --no-daemon --config ~/test.cfg

And the below command for the client (Fedora 28 as well):

barrierc -f --enable-crypto fd7f:7549:7489::2cc

I believe there are two things going on here:

I believe the GUI barrier program does not by default listen on IPv6 when it calls barriers on the server.
Furthermore, when I feed an IPv6 address into the client GUI for master b43581c (when both the server and client are running via Barrier GUI), the client's barrierc log from the GUI gives an "unknown error" when trying to connect:

[2018-05-08T18:11:01] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,304

Notice the repeated 24800 port above. I would bet that has something to do with the problem. In my entry for the client in the GUI, I have omitted the port altogether (I only filled an IPv6 address). I think the GUI is doing the duplication.

@walker0643 I guess I have two questions:

Is the GUI listening on IPv6 as well as IPv4 by default? It would explain my earlier "Connection Refused" messages in my initial report if it wasn't doing this.
Any idea why the GUI client and GUI server have differing behavior than the CLI commands? It seems I can get IPv6 working from the CLI, but not the GUI, and barrierc does not duplicate the port like in the GUI output above.

@ramesh45345 commented on GitHub (May 8, 2018): @AdrianKoshka Thanks for the insight, I should have tested the CLI apps before. I have tested IPv6 and it seems to work when I call it from the command line for git version 5e19820 (which is the closest to 2.0.0), as well as master (b43581c). I am using the below command for the server (Fedora 28): ``` barriers --address fd7f:7549:7489::2cc --enable-crypto --no-restart --no-daemon --config ~/test.cfg ``` And the below command for the client (Fedora 28 as well): ``` barrierc -f --enable-crypto fd7f:7549:7489::2cc ``` I believe there are two things going on here: 1. I believe the GUI barrier program does not by default listen on IPv6 when it calls `barriers` on the server. 2. Furthermore, when I feed an IPv6 address into the client GUI for master b43581c (when both the server and client are running via Barrier GUI), the client's barrierc log from the GUI gives an "unknown error" when trying to connect: ``` [2018-05-08T18:11:01] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800 /mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,304 ``` Notice the repeated 24800 port above. I would bet that has something to do with the problem. In my entry for the client in the GUI, I have omitted the port altogether (I only filled an IPv6 address). I think the GUI is doing the duplication. @walker0643 I guess I have two questions: 1. Is the GUI listening on IPv6 as well as IPv4 by default? It would explain my earlier "Connection Refused" messages in my initial report if it wasn't doing this. 2. Any idea why the GUI client and GUI server have differing behavior than the CLI commands? It seems I can get IPv6 working from the CLI, but not the GUI, and `barrierc` does not duplicate the port like in the GUI output above.

gitea-mirror commented

2026-05-05 04:47:34 -06:00

Author

Owner

@wltjr commented on GitHub (May 8, 2018):

Just to chime in here, I did not author, but I did update the IPv6 patches for Synergy. Which I believe is the basis for this in Barrier. Looking back over that patch in symless/synergy-core/pull/6178. Even in the original symless/synergy-core/pull/4499. It was just patching lib, client and server, not gui. Based on that, it seems there may have been further IPv6 changes done as part of the work in Barrier.

@walker0643 that may be a partial answer to your question 2. Seems they furthered the code into the GUI and something maybe off there. Which is why one works and the other does not.

I can see about taking a look there, but not sure if I can help at all. I was contacted regarding the patches and this issue. Thus chiming in, and I am happy to help if I can.

@wltjr commented on GitHub (May 8, 2018): Just to chime in here, I did not author, but I did update the IPv6 patches for Synergy. Which I believe is the basis for this in Barrier. Looking back over that [patch](https://patch-diff.githubusercontent.com/raw/symless/synergy-core/pull/6178.patch) in symless/synergy-core/pull/6178. Even in the original symless/synergy-core/pull/4499. It was just patching lib, client and server, not gui. Based on that, it seems there may have been further IPv6 changes done as part of the work in Barrier. @walker0643 that may be a partial answer to your question 2. Seems they furthered the code into the GUI and something maybe off there. Which is why one works and the other does not. I can see about taking a look there, but not sure if I can help at all. I was contacted regarding the patches and this issue. Thus chiming in, and I am happy to help if I can.

gitea-mirror commented

2026-05-05 04:47:37 -06:00

Author

Owner

@walker0643 commented on GitHub (May 10, 2018):

It's entirely possible that the GUI is to blame. The GUI does not open any sockets nor do any real networking itself, it simply starts barriers/barrierc (and barrierd on windows) and passes configuration params as arguments.

@ramesh45345 Can you enable debugging info in the GUI settings window (any level INFO and above iirc) and compare the arguments that it passes to barriers/barrierc to those that you were using above?

@walker0643 commented on GitHub (May 10, 2018): It's entirely possible that the GUI is to blame. The GUI does not open any sockets nor do any real networking itself, it simply starts barriers/barrierc (and barrierd on windows) and passes configuration params as arguments. @ramesh45345 Can you enable debugging info in the GUI settings window (any level INFO and above iirc) and compare the arguments that it passes to barriers/barrierc to those that you were using above?

gitea-mirror commented

2026-05-05 04:47:40 -06:00

Author

Owner

@wltjr commented on GitHub (May 10, 2018):

I would assume something is being passed incorrectly from UI to CLI, however that is done. It seemed above a port was duplicated. I do not use any UI with synergy, just text config and starting via cli. That part should be good to go with any IPv6 address.

@wltjr commented on GitHub (May 10, 2018): I would assume something is being passed incorrectly from UI to CLI, however that is done. It seemed above a port was duplicated. I do not use any UI with synergy, just text config and starting via cli. That part should be good to go with any IPv6 address.

gitea-mirror commented

2026-05-05 04:47:43 -06:00

Author

Owner

@ramesh45345 commented on GitHub (May 10, 2018):

@walker0643 Here is the output from the server:

[2018-05-10T07:46:33] INFO: starting server
[2018-05-10T07:46:33] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name rkrishna-pc --enable-crypto -c /tmp/Barrier.i22916 --address :24800
[2018-05-10T07:46:33] INFO: config file: /tmp/Barrier.T22916

I think in modern versions of barriers the ":24000" is unnecessary? In my command line post earlier, I fed an IPv6 address into barriers, however ideally I would have wanted to accept connections from alll IPv6 and IPv4 addresses.

@ramesh45345 commented on GitHub (May 10, 2018): @walker0643 Here is the output from the server: ``` [2018-05-10T07:46:33] INFO: starting server [2018-05-10T07:46:33] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name rkrishna-pc --enable-crypto -c /tmp/Barrier.i22916 --address :24800 [2018-05-10T07:46:33] INFO: config file: /tmp/Barrier.T22916 ``` I think in modern versions of barriers the ":24000" is unnecessary? In my command line post earlier, I fed an IPv6 address into barriers, however ideally I would have wanted to accept connections from alll IPv6 and IPv4 addresses.

gitea-mirror commented

2026-05-05 04:47:45 -06:00

Author

Owner

@walker0643 commented on GitHub (May 10, 2018):

That's very helpful. Can you test the dualstacked branch to see if it fixes this?

https://github.com/debauchee/barrier/tree/dualstacked

@walker0643 commented on GitHub (May 10, 2018): That's very helpful. Can you test the dualstacked branch to see if it fixes this? https://github.com/debauchee/barrier/tree/dualstacked

gitea-mirror commented

2026-05-05 04:47:47 -06:00

Author

Owner

@ramesh45345 commented on GitHub (May 11, 2018):

Hmm, using the dualstacked branch (4806a66a), I am still getting the same result.

Server command:

[2018-05-11T17:22:06] INFO: starting server
[2018-05-11T17:22:06] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name HomeLaptop --enable-crypto -c /tmp/Barrier.Woawqk --address :24800
[2018-05-11T17:22:06] INFO: config file: /tmp/Barrier.WcMPIT
[2018-05-11T17:22:06] INFO: log level: DEBUG2

Client log (same version, 4806a66a):

[2018-05-11T17:23:50] NOTE: connecting to 'HomeLaptop': fd7f:7549:7489::2cc:24800
	/mnt/nasvol/DLs/barrier/src/lib/client/Client.cpp,146
[2018-05-11T17:23:50] INFO: OpenSSL 1.1.0h-fips  27 Mar 2018
	/mnt/nasvol/DLs/barrier/src/lib/net/SecureSocket.cpp,839
[2018-05-11T17:23:50] WARNING: failed to connect to server: Connection refused
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301

Looks like the GUI is still not listening on IPv6 by default. IPv4 still works normally. The above client log was taken with avahi resolution of the IPv6 address. It seems that if you fill in the IPv6 address into the client GUI manually, it still duplicates the port:

[2018-05-11T17:28:09] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301

@ramesh45345 commented on GitHub (May 11, 2018): Hmm, using the dualstacked branch (4806a66a), I am still getting the same result. Server command: ``` [2018-05-11T17:22:06] INFO: starting server [2018-05-11T17:22:06] INFO: command: /usr/local/bin/barriers -f --no-tray --debug DEBUG2 --name HomeLaptop --enable-crypto -c /tmp/Barrier.Woawqk --address :24800 [2018-05-11T17:22:06] INFO: config file: /tmp/Barrier.WcMPIT [2018-05-11T17:22:06] INFO: log level: DEBUG2 ``` Client log (same version, 4806a66a): ``` [2018-05-11T17:23:50] NOTE: connecting to 'HomeLaptop': fd7f:7549:7489::2cc:24800 /mnt/nasvol/DLs/barrier/src/lib/client/Client.cpp,146 [2018-05-11T17:23:50] INFO: OpenSSL 1.1.0h-fips 27 Mar 2018 /mnt/nasvol/DLs/barrier/src/lib/net/SecureSocket.cpp,839 [2018-05-11T17:23:50] WARNING: failed to connect to server: Connection refused /mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301 ``` Looks like the GUI is still not listening on IPv6 by default. IPv4 still works normally. The above client log was taken with avahi resolution of the IPv6 address. It seems that if you fill in the IPv6 address into the client GUI manually, it still duplicates the port: ``` [2018-05-11T17:28:09] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800 /mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,301 ```

gitea-mirror commented

2026-05-05 04:47:49 -06:00

Author

Owner

@walker0643 commented on GitHub (May 12, 2018):

Take 2 ... this time barriers will tell you explicitly which socket family it's using. There will be a NOTE-level line in the debug output stating either

NOTE: started server (IPv4), waiting for clients
or
NOTE: started server (IPv4/IPv6), waiting for clients

Also you can confirm via netstat or another similar tool (netstat -46l for example) whether or not barrier has opened the correct socket type.

@walker0643 commented on GitHub (May 12, 2018): Take 2 ... this time barriers will tell you explicitly which socket family it's using. There will be a NOTE-level line in the debug output stating either - NOTE: started server (IPv4), waiting for clients or - NOTE: started server (IPv4/IPv6), waiting for clients Also you can confirm via netstat or another similar tool (netstat -46l for example) whether or not barrier has opened the correct socket type.

gitea-mirror commented

2026-05-05 04:47:52 -06:00

Author

Owner

@ramesh45345 commented on GitHub (May 12, 2018):

Excellent! It works! It did start in IPv6/IPv4 mode, and the client was able to connect using the avahi name resolution.

Server:

[2018-05-12T10:25:27] INFO: starting server
[2018-05-12T10:25:27] INFO: config file: /tmp/Barrier.EwSlum
[2018-05-12T10:25:27] INFO: log level: INFO
[2018-05-12T10:25:27] NOTE: started server (IPv4/IPv6), waiting for clients

There is only one small issue remaining, and that is manually inputting an IPv6 address into the client GUI's "Server IP" field. It still yields the following results in 5bc3fef8:

[2018-05-12T10:31:52] INFO: starting client
[2018-05-12T10:31:52] INFO: command: /usr/local/bin/barrierc -f --no-tray --debug DEBUG2 --name HomeServer --enable-crypto fd7f:7549:7489::2cc:24800
[2018-05-12T10:31:52] INFO: config file: /tmp/Barrier.lvqIHI
[2018-05-12T10:31:52] INFO: log level: DEBUG2
[2018-05-12T10:31:53] NOTE: started client
	/mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,393
[2018-05-12T10:31:53] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800

I admit that I probably won't rely on this much, but I can see this bug needing to be fixed at some point. I believe the way it is working right now, for an IPv6 address, I can't specify the port using the command line in order for it to connect properly. For example, using the following command (without the GUI) on the client works:

barrierc -f --enable-crypto fd7f:7549:7489::2cc

However, this results in the port error seen above:

barrierc -f --enable-crypto fd7f:7549:7489::2cc:24800

I suspect the issue is specifc to parsing the semi-colons in IPv6 addresses (a wild guess on my part). Might explain why hostnames or IPv4 addresses work just fine with ports.

@ramesh45345 commented on GitHub (May 12, 2018): Excellent! It works! It did start in IPv6/IPv4 mode, and the client was able to connect using the avahi name resolution. Server: ``` [2018-05-12T10:25:27] INFO: starting server [2018-05-12T10:25:27] INFO: config file: /tmp/Barrier.EwSlum [2018-05-12T10:25:27] INFO: log level: INFO [2018-05-12T10:25:27] NOTE: started server (IPv4/IPv6), waiting for clients ``` There is only one small issue remaining, and that is manually inputting an IPv6 address into the client GUI's "Server IP" field. It still yields the following results in 5bc3fef8: ``` [2018-05-12T10:31:52] INFO: starting client [2018-05-12T10:31:52] INFO: command: /usr/local/bin/barrierc -f --no-tray --debug DEBUG2 --name HomeServer --enable-crypto fd7f:7549:7489::2cc:24800 [2018-05-12T10:31:52] INFO: config file: /tmp/Barrier.lvqIHI [2018-05-12T10:31:52] INFO: log level: DEBUG2 [2018-05-12T10:31:53] NOTE: started client /mnt/nasvol/DLs/barrier/src/lib/barrier/ClientApp.cpp,393 [2018-05-12T10:31:53] WARNING: failed to connect to server: unknown error for: fd7f:7549:7489::2cc:24800:24800 ``` I admit that I probably won't rely on this much, but I can see this bug needing to be fixed at some point. I believe the way it is working right now, for an IPv6 address, I can't specify the port using the command line in order for it to connect properly. For example, using the following command (without the GUI) on the client works: ``` barrierc -f --enable-crypto fd7f:7549:7489::2cc ``` However, this results in the port error seen above: ``` barrierc -f --enable-crypto fd7f:7549:7489::2cc:24800 ``` I suspect the issue is specifc to parsing the semi-colons in IPv6 addresses (a wild guess on my part). Might explain why hostnames or IPv4 addresses work just fine with ports.

gitea-mirror commented

2026-05-05 04:47:54 -06:00

Author

Owner

@yupi2 commented on GitHub (May 12, 2018):

Wrapping the IPv6 address in brackets seems to be the notation used to separate port and address (since IPv6 uses colons). https://serverfault.com/questions/205793/how-can-one-distinguish-the-host-and-the-port-in-an-ipv6-url

Would need to change parsing in 24987e0694/src/lib/net/NetworkAddress.cpp (L60)
and then make the GUI put brackets around IPv6 addresses (with the port outside the brackets) I imagine.

@yupi2 commented on GitHub (May 12, 2018): Wrapping the IPv6 address in brackets seems to be the notation used to separate port and address (since IPv6 uses colons). https://serverfault.com/questions/205793/how-can-one-distinguish-the-host-and-the-port-in-an-ipv6-url Would need to change parsing in https://github.com/debauchee/barrier/blob/24987e069496b185ad88de09657dced2a73189ef/src/lib/net/NetworkAddress.cpp#L60 and then make the GUI put brackets around IPv6 addresses (with the port outside the brackets) I imagine.

gitea-mirror commented

2026-05-05 04:47:57 -06:00

Author

Owner

@walker0643 commented on GitHub (May 12, 2018):

Among other cleanup and bookkeeping items I also added today (what I hope is) a fix for the host:port argument issue you mentioned. Take a look and please let me know if you see anything else related that needs to be addressed before merging. Thanks!

@walker0643 commented on GitHub (May 12, 2018): Among other cleanup and bookkeeping items I also added today (what I hope is) a fix for the host:port argument issue you mentioned. Take a look and please let me know if you see anything else related that needs to be addressed before merging. Thanks!

gitea-mirror commented

2026-05-05 04:48:01 -06:00

Author

Owner

@ramesh45345 commented on GitHub (May 12, 2018):

No further complaints from me, 92e8e1e seems to be working regarding everything reported above. Thanks a bunch for your work on this, its a really appreciated fork of the synergy codebase.

@ramesh45345 commented on GitHub (May 12, 2018): No further complaints from me, 92e8e1e seems to be working regarding everything reported above. Thanks a bunch for your work on this, its a really appreciated fork of the synergy codebase.

gitea-mirror referenced this issue

2026-05-05 07:56:03 -06:00

[PR #24] [MERGED] docker recipes for several linux distributions #1544