github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #372] Barrier can't connect using hostname, only ip #295

New issue

Closed

opened 2026-05-05 05:58:53 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 05:58:53 -06:00

Owner

Originally created by @evantandersen on GitHub (Jul 25, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/372

Operating Systems

Server: Ubuntu, 4.18.0-26-generic

Client: Mint, 4.15.0-20-generic

Barrier Version

2.3.0 Flatpak

Steps to reproduce bug

Connecting using the ip works fine
Connecting using the hostname (which resolves to the same ip) does not, fails with this error
[2019-07-25T01:57:34] WARNING: failed to connect to server: unknown error for: evan-woodtower:24800
Netcat seems to be able to connect just fine:

$ netcat evan-woodtower 24800

Barrier□□^C
$

Other info

I'm using barrier to control a VM setup where the host and guest each get their own screen. Windows has no problem connecting to the host using it's hostname, but when I switch the VM to linux mint it won't connect. I first had to enable windows hostname resolution on mint, but that seems to be working just fine for other programs (netcat, ping, accessing network shares, etc). So I'm not sure what's going on, or how to debug further. My host machine's ip seems to change multiple times per day right now, and it's annoying to have to used qemu sendkey to update the ip in barrier.

Originally created by @evantandersen on GitHub (Jul 25, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/372 ### Operating Systems ### Server: Ubuntu, 4.18.0-26-generic Client: Mint, 4.15.0-20-generic ### Barrier Version ### 2.3.0 Flatpak ### Steps to reproduce bug ### 1. Connecting using the ip works fine 2. Connecting using the hostname (which resolves to the same ip) does not, fails with this error `[2019-07-25T01:57:34] WARNING: failed to connect to server: unknown error for: evan-woodtower:24800 ` Netcat seems to be able to connect just fine: ``` $ netcat evan-woodtower 24800 Barrier□□^C $ ``` ### Other info ### I'm using barrier to control a VM setup where the host and guest each get their own screen. Windows has no problem connecting to the host using it's hostname, but when I switch the VM to linux mint it won't connect. I first had to [enable windows hostname resolution on mint](https://www.techrepublic.com/article/how-to-enable-linux-machines-to-resolve-windows-hostnames/), but that seems to be working just fine for other programs (netcat, ping, accessing network shares, etc). So I'm not sure what's going on, or how to debug further. My host machine's ip seems to change multiple times per day right now, and it's annoying to have to used qemu sendkey to update the ip in barrier.

gitea-mirror

2026-05-05 05:58:53 -06:00

closed this issue
added the
bug

linux
labels

gitea-mirror commented

2026-05-05 05:59:00 -06:00

Author

Owner

@noisyshape commented on GitHub (Jul 25, 2019):

That error comes from getaddrinfo, which netcat also uses for hostname resolution. I suspect that Barrier isn't using the same network/nameserver configuration, possibly because of Flatpak.

As a workaround, if you control the network you could change the DHCP lease times or assign a static address to the VM host.

@noisyshape commented on GitHub (Jul 25, 2019): That error comes from getaddrinfo, which netcat also uses for hostname resolution. I suspect that Barrier isn't using the same network/nameserver configuration, possibly because of Flatpak. As a workaround, if you control the network you could change the DHCP lease times or assign a static address to the VM host.

gitea-mirror commented

2026-05-05 05:59:03 -06:00

Author

Owner

@enricodias commented on GitHub (Jul 30, 2019):

I have the same issue if I leave my computers locked for the night (not VMs). Both machines stay connected and with the same IP. Even if I put them to sleep, the lease time is long enough to they keep the same IPs.

Barrier could save the last known ip and try to use it if the hostname resolution fail.

@enricodias commented on GitHub (Jul 30, 2019): I have the same issue if I leave my computers locked for the night (not VMs). Both machines stay connected and with the same IP. Even if I put them to sleep, the lease time is long enough to they keep the same IPs. Barrier could save the last known ip and try to use it if the hostname resolution fail.

gitea-mirror commented

2026-05-05 05:59:06 -06:00

Author

Owner

@evantandersen commented on GitHub (Aug 5, 2019):

98% sure this is actually a flatpak issue.

https://github.com/flatpak/flatpak/issues/348

@evantandersen commented on GitHub (Aug 5, 2019): 98% sure this is actually a flatpak issue. https://github.com/flatpak/flatpak/issues/348

No labels

Rows
Columns