[GH-ISSUE #190] Always getting Timeout while connecting

gitea-mirror commented

2026-05-05 05:26:21 -06:00

Owner

Originally created by @TwentyFourMinutes on GitHub (Dec 1, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/190

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.

Originally created by @TwentyFourMinutes on GitHub (Dec 1, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/190 ### 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.

gitea-mirror closed this issue

2026-05-05 05:26:23 -06:00

gitea-mirror commented

2026-05-05 05:26:25 -06:00

Author

Owner

@dayne commented on GitHub (Dec 4, 2018):

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.

@dayne commented on GitHub (Dec 4, 2018): 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.

gitea-mirror commented

2026-05-05 05:26:26 -06:00

Author

Owner

@TwentyFourMinutes commented on GitHub (Dec 9, 2018):

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.

@TwentyFourMinutes commented on GitHub (Dec 9, 2018): 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.

gitea-mirror commented

2026-05-05 05:26:28 -06:00

Author

Owner

@dayne commented on GitHub (Dec 9, 2018):

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

@dayne commented on GitHub (Dec 9, 2018): 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. ```Powershell 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 ```

gitea-mirror commented

2026-05-05 05:26:29 -06:00

Author

Owner

@TwentyFourMinutes commented on GitHub (Dec 10, 2018):

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 :)

@TwentyFourMinutes commented on GitHub (Dec 10, 2018): 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 :)

gitea-mirror commented

2026-05-05 05:26:31 -06:00

Author

Owner

@TwentyFourMinutes commented on GitHub (Dec 10, 2018):

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

@TwentyFourMinutes commented on GitHub (Dec 10, 2018): Thanks a lot for your help, it does indeed work now.

gitea-mirror commented

2026-05-05 05:26:33 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Dec 12, 2018):

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

@AdrianKoshka commented on GitHub (Dec 12, 2018): Thanks a bunch @dayne for helping people open the port on the firewall. This issue should be fixed whenever 2.2 comes out.

gitea-mirror commented

2026-05-05 05:26:36 -06:00

Author

Owner

@YitzHandel commented on GitHub (Jan 13, 2021):

Do you have VirtualBox installed? In my case, I do, and that port was preferred, and the server was trying to connect on that port (while VBox was not running) and it couldn't connect. Change the metric or disable the adapter permanently or temporarily.

@YitzHandel commented on GitHub (Jan 13, 2021): Do you have VirtualBox installed? In my case, I do, and that port was preferred, and the server was trying to connect on that port (while VBox was not running) and it couldn't connect. Change the metric or disable the adapter permanently or temporarily.

gitea-mirror commented

2026-05-05 05:26:38 -06:00

Author

Owner

@AustinBoath commented on GitHub (Jan 26, 2021):

I like pineapples on pizza

@AustinBoath commented on GitHub (Jan 26, 2021): I like pineapples on pizza

gitea-mirror commented

2026-05-05 05:26:40 -06:00

Author

Owner

@knaos commented on GitHub (Apr 23, 2021):

I can confirm that usually VirtualBox is the issue.

@knaos commented on GitHub (Apr 23, 2021): I can confirm that usually VirtualBox is the issue.

gitea-mirror commented

2026-05-05 05:26:42 -06:00

Author

Owner

@badvision commented on GitHub (Jun 17, 2021):

I have the same issue but intermittently. I run 2.3.3 on both Windows (as server) and MacOS (as client.)

Are there other ways I can rule out network-related issues?

@badvision commented on GitHub (Jun 17, 2021): I have the same issue but intermittently. I run 2.3.3 on both Windows (as server) and MacOS (as client.) Are there other ways I can rule out network-related issues?

gitea-mirror commented

2026-05-05 05:26:46 -06:00

Author

Owner

@LaughDonor commented on GitHub (Jan 14, 2022):

My network was configured as a Public Network, so I had stricter policies that blocked everything. To check this, I saw which network was connected when entering control firewall.cpl in the W11 (works in previous Windows too) Run... dialog.

Then I pasted the following (subbing the name of the network) in Powershell (non-admin worked):

Set-NetConnectionProfile -Name "My Network Name" -NetworkCategory Private

@LaughDonor commented on GitHub (Jan 14, 2022): My network was configured as a Public Network, so I had stricter policies that blocked everything. To check this, I saw which network was connected when entering `control firewall.cpl` in the W11 (works in previous Windows too) Run... dialog. Then I pasted the following (subbing the name of the network) in Powershell (non-admin worked): ```powershell Set-NetConnectionProfile -Name "My Network Name" -NetworkCategory Private ```

gitea-mirror commented

2026-05-05 05:26:48 -06:00

Author

Owner

@jebasinghsunderson commented on GitHub (Jun 16, 2022):

Just leaving this here in case anyone couldn't fix it after this.. I did everything mentioned above still it didn't connect. Then I restarted Barrier from Windows services (services.msc). And it worked immediately.

@jebasinghsunderson commented on GitHub (Jun 16, 2022): Just leaving this here in case anyone couldn't fix it after this.. I did everything mentioned above still it didn't connect. Then I restarted Barrier from Windows services (services.msc). And it worked immediately.

gitea-mirror commented

2026-05-05 05:26:51 -06:00

Author

Owner

@dondell commented on GitHub (Oct 10, 2022):

Just make sure that in windows, port should be the same as in the other computer.

@dondell commented on GitHub (Oct 10, 2022): ![image](https://user-images.githubusercontent.com/4174860/194787388-6d6df1ea-49b6-47de-8029-418c9ada2073.png) Just make sure that in windows, port should be the same as in the other computer.

gitea-mirror commented

2026-05-05 05:26:54 -06:00

Author

Owner

@snowe2010 commented on GitHub (Aug 4, 2023):

@jebasinghsunderson your comment was the only thing that has worked for me. I have this occur almost every day, where my windows client will not connect to my mac server. I have tried quite a lot but the restart of the Barrier service immediately fixed it.

@snowe2010 commented on GitHub (Aug 4, 2023): @jebasinghsunderson your comment was the only thing that has worked for me. I have this occur almost every day, where my windows client will not connect to my mac server. I have tried quite a lot but the restart of the Barrier service immediately fixed it.

gitea-mirror commented

2026-05-05 05:26:56 -06:00

Author

Owner

@jabeztadesse commented on GitHub (Dec 2, 2023):

When I use PC1 as the server and PC2 as a client, it doesn't work. The other way around it works. I tried all the above things ...

@jabeztadesse commented on GitHub (Dec 2, 2023): When I use PC1 as the server and PC2 as a client, it doesn't work. The other way around it works. I tried all the above things ...

Rows
Columns

[GH-ISSUE #190] Always getting Timeout while connecting #156

Operating Systems

Barrier Version

Other info

verify windows thinks barrierd is running on itself at port 24800

my own localhost based example: