Barrier: Always getting Timeout while connecting

Created on 1 Dec 2018  路  6Comments  路  Source: debauchee/barrier

Operating Systems

Server: Windows 10

Client: Mac OS High Sierra

Barrier Version

2.1.0

Other info

  • I just set on my Barrier on Windows 10 to Server hit Start (It says Barrier is running)
    On my Mac I just set it to Client hit auto Config (It will never stop saying Barrier is starting)

  • The Logs say that they find each other

  • When looking at the Mac Log:

[2018-12-01T18:42:31] INFO: starting client [2018-12-01T18:42:31] INFO: config file: /var/folders/7t/dmpgl7w53f3644y2rxclrmlm0000gn/T/Barrier.fTwyiR [2018-12-01T18:42:31] INFO: log level: INFO [2018-12-01T18:42:31] INFO: drag and drop enabled [2018-12-01T18:42:31] NOTE: started client [2018-12-01T18:42:31] NOTE: connecting to '192.168.56.1': 192.168.56.1:24800 [2018-12-01T18:42:31] INFO: OpenSSL 1.0.2n 7 Dec 2017 2018-12-01 18:42:31.983 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:31.997 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:31.999 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.000 barrierc[877:35054] pid(877)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2018-12-01 18:42:32.004 barrierc[877:35026] starting cocoa loop [2018-12-01T18:42:46] WARNING: failed to connect to server: Timed out [2018-12-01T18:42:47] NOTE: connecting to '192.168.56.1': 192.168.56.1:24800 [2018-12-01T18:42:47] INFO: OpenSSL 1.0.2n 7 Dec 2017

-The last 3 lines will just repeat over and over again.

  • Is there a way to work around it? No.
  • Does this bug prevent you from using Barrier entirely? Yes

Also opening the port used by Barrier on the Windows 10 Firewall manually did not help.

Most helpful comment

That means you need to focus on debugging the server to ensure

  • barrierd is running
  • the port is listening
  • the firewall is open
  • you know the IP address of your workstation acting as the barrierd server

verify windows thinks barrierd is running on itself at port 24800

Using PowerShell on windows you can determine if your own box considers the 24800 port listening or not using:

Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed

Note: I'm using localhost in that test above. That would be a good first sanity check but what you really want to test is if Windows thinks that port is open on the LAN network interface, not the loopback interface.

Based on the IP you posted (see below) want to instead run:
Test-NetConnection -Port 24800 -ComputerName 192.168.56.1 -InformationLevel Detailed

I am a bit concerned though. Are you sure your Windows server IP is 192.168.56.1. The .1 IP is usually reserved for the gateway/route on a network and not a workstation.

You can get powershell to list out your IPV4 IP addresess.

Get-NetIPAddress | ?{ $_.AddressFamily -eq "IPv4"  -and 
   !($_.IPAddress -match "169") -and !($_.IPaddress -match "127") }

Scan that and verify/correct which 192.168.56.X ip address your windows box has.

Once you've verified the port is listening and you know your windows box LAN's IP address -- revisit that nc command on the Linux client.

Good luck on this next phase of debugging. Take notes and observations and report back here what pathway gets things working. I see others having this same issue regular having well documented debug and fixing steps would be great.

my own localhost based example:

Here is the result from me testing when Barrierd was not running:

PS C:\Users\dayne> Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed
WARNING: TCP connect to (::1 : 24800) failed
WARNING: TCP connect to (127.0.0.1 : 24800) failed


ComputerName            : localhost
RemoteAddress           : ::1
RemotePort              : 24800
NameResolutionResults   : ::1
                          127.0.0.1
MatchingIPsecRules      :
NetworkIsolationContext : Loopback
IsAdmin                 : False
InterfaceAlias          : Loopback Pseudo-Interface 1
SourceAddress           : ::1
NetRoute (NextHop)      : ::
PingSucceeded           : True
PingReplyDetails (RTT)  : 0 ms
TcpTestSucceeded        : False

Here is the same test but with Barrierd running:

PS C:\Users\dayne> Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed


ComputerName            : localhost
RemoteAddress           : ::1
RemotePort              : 24800
NameResolutionResults   : ::1
                          127.0.0.1
MatchingIPsecRules      :
NetworkIsolationContext : Loopback
IsAdmin                 : False
InterfaceAlias          : Loopback Pseudo-Interface 1
SourceAddress           : ::1
NetRoute (NextHop)      : ::
TcpTestSucceeded        : True

All 6 comments

The core issue is client is failing to connect to server and is timing out. You need to double check server is running, the port is open, and the client is able to connect to the port.

On the mac verify you can connect to port 24800 on the windows box using nc:

nc -vz 192.168.56.1 24800

Correct output would be: Connection to 192.168.56.1 24800 port [tcp/*] succeeded!

If that doesn't work then you need to keep debugging the server/port/network.

Well it just says "nc: connectx to 192.168.56.1 port 24800 (tcp) failed: Network is unreachable" Even disabling the Windows Defender Firewall didn't help.

That means you need to focus on debugging the server to ensure

  • barrierd is running
  • the port is listening
  • the firewall is open
  • you know the IP address of your workstation acting as the barrierd server

verify windows thinks barrierd is running on itself at port 24800

Using PowerShell on windows you can determine if your own box considers the 24800 port listening or not using:

Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed

Note: I'm using localhost in that test above. That would be a good first sanity check but what you really want to test is if Windows thinks that port is open on the LAN network interface, not the loopback interface.

Based on the IP you posted (see below) want to instead run:
Test-NetConnection -Port 24800 -ComputerName 192.168.56.1 -InformationLevel Detailed

I am a bit concerned though. Are you sure your Windows server IP is 192.168.56.1. The .1 IP is usually reserved for the gateway/route on a network and not a workstation.

You can get powershell to list out your IPV4 IP addresess.

Get-NetIPAddress | ?{ $_.AddressFamily -eq "IPv4"  -and 
   !($_.IPAddress -match "169") -and !($_.IPaddress -match "127") }

Scan that and verify/correct which 192.168.56.X ip address your windows box has.

Once you've verified the port is listening and you know your windows box LAN's IP address -- revisit that nc command on the Linux client.

Good luck on this next phase of debugging. Take notes and observations and report back here what pathway gets things working. I see others having this same issue regular having well documented debug and fixing steps would be great.

my own localhost based example:

Here is the result from me testing when Barrierd was not running:

PS C:\Users\dayne> Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed
WARNING: TCP connect to (::1 : 24800) failed
WARNING: TCP connect to (127.0.0.1 : 24800) failed


ComputerName            : localhost
RemoteAddress           : ::1
RemotePort              : 24800
NameResolutionResults   : ::1
                          127.0.0.1
MatchingIPsecRules      :
NetworkIsolationContext : Loopback
IsAdmin                 : False
InterfaceAlias          : Loopback Pseudo-Interface 1
SourceAddress           : ::1
NetRoute (NextHop)      : ::
PingSucceeded           : True
PingReplyDetails (RTT)  : 0 ms
TcpTestSucceeded        : False

Here is the same test but with Barrierd running:

PS C:\Users\dayne> Test-NetConnection -Port 24800 -ComputerName localhost -InformationLevel Detailed


ComputerName            : localhost
RemoteAddress           : ::1
RemotePort              : 24800
NameResolutionResults   : ::1
                          127.0.0.1
MatchingIPsecRules      :
NetworkIsolationContext : Loopback
IsAdmin                 : False
InterfaceAlias          : Loopback Pseudo-Interface 1
SourceAddress           : ::1
NetRoute (NextHop)      : ::
TcpTestSucceeded        : True

Okay It seems that my firewall created an Fake IP Address which being 192.168.56.1 and this fails in the test Test-NetConnection -Port 24800 -ComputerName 192.168.56.1 -InformationLevel Detailed With the other IP listed it works just fine. Thanks for the advice I will test it later with barrier on my Mac thanks so far :)

Thanks a lot for your help, it does indeed work now.

Thanks a bunch @dayne for helping people open the port on the firewall. This issue should be fixed whenever 2.2 comes out.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Ayanmullick picture Ayanmullick  路  23Comments

AdrianKoshka picture AdrianKoshka  路  22Comments

xMyran picture xMyran  路  27Comments

BananaAcid picture BananaAcid  路  25Comments

domparry picture domparry  路  16Comments