search

input-leap / input-leap

Open-source KVM software
Other
4.25k stars 186 forks source link

Barrier can't connect - Linux server, MacOS client #597

Open ghost opened 3 years ago

ghost commented 3 years ago

This issue has been migrated from old Barrier Github repository https://github.com/debauchee/barrier/issues/597

Issue created on: 2020-03-25 by @Eddles Issue last updated on: 2021-09-02

Operating Systems

Server: Linux Mint 19.1 Tessa

Client: MacOS Catalina 10.15.4

Barrier Version

Server: 2.3.2-snapshot-9080ce45

Client: 2.3.2-Release-210C2b70

Steps to reproduce bug

  1. Start Barrier on Linux server - ip 192.168.1.135
  2. Start Barrier on MacOS client, set it to connect to 192.168.1.135
  3. Client shows "WARNING: failed to connect to sever: Timed out"
  4. I verified Barrier was running and listening on the right port:

kit@wanderer:~$ sudo netstat -tupan | grep barrier tcp6 0 0 :::24800 :::* LISTEN 31192/barriers tcp6 0 0 :::35785 :::* LISTEN 31068/barrier kit@wanderer:~$

  1. I verified that the MacOS client can ping the server on 192.168.1.135 just fine.
  2. I verified the Barrier client is set up to connect to port 24800.
  3. Using "Autoconfig" doesn't work.
  4. Both the Linux server and the MacOS client is on the same subnet.

Other info

Any advice would be greatly appreciated, thank you.

Commented on: 2020-03-25 by @Eddles

Update: I tried the following on the Linux server:

sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT

The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before.

One step forward, but still the same situation.

Commented on: 2020-03-25 by @Eddles

Problem fixed - found an orphan Barrier thread still running and blocking the port.

So there's 2 issues here:

1) Linux firewall blocking the port - it'd be good if Barrier can identify this and let the user know. 2) Multiple instances of Barrier - again, it'd be good if Barrier can identify this and let the user know.

Many thanks!

Commented on: 2020-09-27 by @github-actions[bot]

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

Commented on: 2021-01-19 by @sidouglas

For those coming from google: Set both screen names of the mac and linux machines to something plain and simple ( no punctuation )

Commented on: 2021-03-20 by @Rushi-0

sry for late answer, so i was trying to share my keyboard and mouse from win10 (pc) to kali linux (laptop) on first startup i got a successful connection between 2machines but on 2nd startup i got this same error 'Failed to connect to server : Timed out'. my client ip and host ip was also correct but still i was not getting a connection then i found that the windows firewall is blocking the connection and that the main reason of connection Timed out

SOLUTION :- go to windows firewall and go to windows firewall properties and go in privet profile section and allow Inbound Connection. andddd we are DONE!

Commented on: 2021-04-28 by @nazareka

Update: I tried the following on the Linux server:

sudo iptables -I INPUT -p tcp --dport 24800 --syn -j ACCEPT

The MacOS client popped up an SSL warning and asked me to accept it. I clicked on "accept" but it's back to connection timing out the same as before.

One step forward, but still the same situation.

thank you!

GASOLINE commented 2 years ago

If I add the iptables, barrier is working but my Samba is not anymore :(

seevee commented 11 months ago

I'm getting the exact same Connection refused behavior on input-leap 2.4.0-release-release-3e681454.

Server: EndeavourOS x86_64 6.6.2-arch1-1 (via AUR) Client: macOS 14.1.1 23B81 arm64 M2 (via macports)

Disabling SSL did not work, nor did the iptables invocation.

shymega commented 11 months ago

ARM64 builds of Input Leap are not supported officially yet.

What screen names are you using?

seevee commented 11 months ago

What screen names are you using?

server: ionian client: lydian

I have been connecting from the client to the server via IP, not hostname.

Behavior is as expected if the macOS device is the server. Only the linux server / macOS client configuration is causing issues as far as I can tell.

shymega commented 11 months ago

You should be able to enable DEBUG2 logging in the GUI.

Please reply with the logs from the problematic setup, at that log level, as an attachment.

seevee commented 11 months ago

Thanks for taking a look at this, here's the logs from both machines in the failing configuration:

input-leap-client.log input-leap-server.log

Some notes: