Server: Windows 10
Client: Mac OS High Sierra
2.1.0
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
[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.
Also opening the port used by Barrier on the Windows 10 Firewall manually did not help.
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
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.
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.
Most helpful comment
That means you need to focus on debugging the server to ensure
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 DetailedNote: 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 DetailedI 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.
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:
Here is the same test but with Barrierd running: