[GH-ISSUE #537] Barrier Stops working on Macbook High Sierra - 10.13.6 after machines goes to sleep or restart #420

Open
opened 2026-05-05 06:20:43 -06:00 by gitea-mirror · 9 comments
Owner

Originally created by @kumar-j on GitHub (Jan 3, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/537

Operating Systems
Server: macOS 10.13.6 High Sierra
Client: Windows 10 - Version 1809

Barrier Versions
Server is 2.3.2 - Release-210c2b70
Client - 2.3.2

Steps to reproduce the bug
The bug happens when the server machine goes to sleep or re-started. The same happens when I start both machines every morning.
Also, even if the mouse pointer gets connected to the MacBook server, the mouse pointer becomes jittery. Clicking on the MacBook touchpad does not make any difference.

What Solves the bug (temporarily) -
I have to delete the server machine on the client barrier software. Then I have to quit the MacBook barrier. After that, I have to restart the barrier on the MacBook. It then sends the availability popup on the client machine (windows) and after I add it as a server, it starts working again.
But, sometimes, this solution does not work at all. I have to repeat it several times to work.

Originally created by @kumar-j on GitHub (Jan 3, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/537 **Operating Systems** Server: macOS 10.13.6 High Sierra Client: Windows 10 - Version 1809 **Barrier Versions** Server is 2.3.2 - Release-210c2b70 Client - 2.3.2 **Steps to reproduce the bug** The bug happens when the server machine goes to sleep or re-started. The same happens when I start both machines every morning. Also, even if the mouse pointer gets connected to the MacBook server, the mouse pointer becomes jittery. Clicking on the MacBook touchpad does not make any difference. **What Solves the bug (temporarily) -** I have to delete the server machine on the client barrier software. Then I have to quit the MacBook barrier. After that, I have to restart the barrier on the MacBook. It then sends the availability popup on the client machine (windows) and after I add it as a server, it starts working again. But, sometimes, this solution does not work at all. I have to repeat it several times to work.
Author
Owner

@Hack5190 commented on GitHub (Jan 6, 2020):

Note: Sleep related issues exist when both the server and client are running macOS.

Current setup (for both server & client) is Barrier v2.3.2-Release-210c2b70 running on macOS Mojave v10.14.6 (18G2022).

<!-- gh-comment-id:571208343 --> @Hack5190 commented on GitHub (Jan 6, 2020): Note: Sleep related issues exist when both the server and client are running macOS. Current setup (for both server & client) is Barrier v2.3.2-Release-210c2b70 running on macOS Mojave v10.14.6 (18G2022).
Author
Owner

@socketbox commented on GitHub (Jan 8, 2020):

I'll grant that this is inconvenient, but what exactly is expected/desired behavior here? Override the power management settings that the user themselves have configured?

I'm running a client on macOS 10.13.6 and a server on Linux Mint 19.3 (both v2.3.2-210c2b70). Here is an excerpt from the log on the client (at DEBUG level) showing that Barrier is aware of power management events:

[2020-01-07T18:32:26] INFO: leaving screen
[2020-01-07T18:32:26] DEBUG: hiding cursor
[2020-01-07T18:32:26] WARNING: cursor may not be visible
[2020-01-07T21:33:21] INFO: suspend
[2020-01-07T21:33:21] DEBUG: showing cursor
[2020-01-07T21:33:21] DEBUG: Closing socket: D8610850
[2020-01-07T21:33:21] DEBUG: system will sleep
[2020-01-07T21:33:21] NOTE: disconnected from server
[2020-01-07T21:33:21] DEBUG: retry in 1 seconds
[2020-01-08T06:48:22] WARNING: failed to connect to server: cannot connect socket: Network is unreachable
[2020-01-08T06:48:22] DEBUG: system wakeup
[2020-01-08T06:48:22] INFO: resume
[2020-01-08T06:48:22] NOTE: connecting to '192.168.1.100': 192.168.1.100:24800
[2020-01-08T06:48:22] DEBUG: Opening new socket: DA30A1D0
[2020-01-08T06:48:22] INFO: OpenSSL 1.0.2t  10 Sep 2019
[2020-01-08T06:48:22] DEBUG: Closing socket: DA30A1D0
[2020-01-08T06:48:22] DEBUG: retry in 1 seconds
[2020-01-08T06:48:23] DEBUG: screen shape: center=0,0 size=1080x2048 on 1 display
[2020-01-08T06:48:23] DEBUG: screen shape: center=0,0 size=1080x2048 on 1 display
[2020-01-08T06:48:23] DEBUG: screen shape: center=0,-2048 size=1680x3098 on 2 displays
[2020-01-08T06:48:23] DEBUG: screen shape: center=0,-2048 size=1680x3098 on 2 displays
[2020-01-08T06:48:23] NOTE: connecting to '192.168.1.100': 192.168.1.100:24800
[2020-01-08T06:48:23] DEBUG: Opening new socket: D8711DD0
[2020-01-08T06:48:23] INFO: OpenSSL 1.0.2t  10 Sep 2019
[2020-01-08T06:48:24] NOTE: server fingerprint: 1A:FF:07:74:2A:E8:F9:CF:6C:06:0B:C8:87:2C:AA:8F:D3:F3:83:7D
[2020-01-08T06:48:24] NOTE: trustedServersFilename: /Users/chb/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt
[2020-01-08T06:48:24] NOTE: Opened trustedServersFilename: /Users/chb/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt
[2020-01-08T06:48:24] NOTE: Fingerprint does not match trusted fingerprint
[2020-01-08T06:48:24] NOTE: Fingerprint matches trusted fingerprint
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
2020-01-08 06:48:24.245 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
[2020-01-08T06:48:24] WARNING: cursor may not be visible
[2020-01-08T06:48:24] INFO: connected to secure socket
[2020-01-08T06:48:24] INFO: server ssl certificate info: /CN=Barrier
[2020-01-08T06:48:24] INFO: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
[2020-01-08T06:48:24] DEBUG: hiding cursor
[2020-01-08T06:48:24] NOTE: connected to server
[2020-01-08T06:50:01] DEBUG: clipboard changed
[2020-01-08T06:50:01] DEBUG: opening clipboard
[2020-01-08T06:50:01] DEBUG: closing clipboard
[2020-01-08T06:50:01] DEBUG: sending clipboard 0 seqnum=0
[2020-01-08T06:50:01] DEBUG: sent clipboard size=17770
<!-- gh-comment-id:572016681 --> @socketbox commented on GitHub (Jan 8, 2020): I'll grant that this is inconvenient, but what exactly is expected/desired behavior here? Override the power management settings that the user themselves have configured? I'm running a client on macOS 10.13.6 and a server on Linux Mint 19.3 (both v2.3.2-210c2b70). Here is an excerpt from the log on the client (at DEBUG level) showing that Barrier is aware of power management events: ``` [2020-01-07T18:32:26] INFO: leaving screen [2020-01-07T18:32:26] DEBUG: hiding cursor [2020-01-07T18:32:26] WARNING: cursor may not be visible [2020-01-07T21:33:21] INFO: suspend [2020-01-07T21:33:21] DEBUG: showing cursor [2020-01-07T21:33:21] DEBUG: Closing socket: D8610850 [2020-01-07T21:33:21] DEBUG: system will sleep [2020-01-07T21:33:21] NOTE: disconnected from server [2020-01-07T21:33:21] DEBUG: retry in 1 seconds [2020-01-08T06:48:22] WARNING: failed to connect to server: cannot connect socket: Network is unreachable [2020-01-08T06:48:22] DEBUG: system wakeup [2020-01-08T06:48:22] INFO: resume [2020-01-08T06:48:22] NOTE: connecting to '192.168.1.100': 192.168.1.100:24800 [2020-01-08T06:48:22] DEBUG: Opening new socket: DA30A1D0 [2020-01-08T06:48:22] INFO: OpenSSL 1.0.2t 10 Sep 2019 [2020-01-08T06:48:22] DEBUG: Closing socket: DA30A1D0 [2020-01-08T06:48:22] DEBUG: retry in 1 seconds [2020-01-08T06:48:23] DEBUG: screen shape: center=0,0 size=1080x2048 on 1 display [2020-01-08T06:48:23] DEBUG: screen shape: center=0,0 size=1080x2048 on 1 display [2020-01-08T06:48:23] DEBUG: screen shape: center=0,-2048 size=1680x3098 on 2 displays [2020-01-08T06:48:23] DEBUG: screen shape: center=0,-2048 size=1680x3098 on 2 displays [2020-01-08T06:48:23] NOTE: connecting to '192.168.1.100': 192.168.1.100:24800 [2020-01-08T06:48:23] DEBUG: Opening new socket: D8711DD0 [2020-01-08T06:48:23] INFO: OpenSSL 1.0.2t 10 Sep 2019 [2020-01-08T06:48:24] NOTE: server fingerprint: 1A:FF:07:74:2A:E8:F9:CF:6C:06:0B:C8:87:2C:AA:8F:D3:F3:83:7D [2020-01-08T06:48:24] NOTE: trustedServersFilename: /Users/chb/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt [2020-01-08T06:48:24] NOTE: Opened trustedServersFilename: /Users/chb/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt [2020-01-08T06:48:24] NOTE: Fingerprint does not match trusted fingerprint [2020-01-08T06:48:24] NOTE: Fingerprint matches trusted fingerprint 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.243 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.244 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! 2020-01-08 06:48:24.245 barrierc[23334:760399] pid(23334)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!! [2020-01-08T06:48:24] WARNING: cursor may not be visible [2020-01-08T06:48:24] INFO: connected to secure socket [2020-01-08T06:48:24] INFO: server ssl certificate info: /CN=Barrier [2020-01-08T06:48:24] INFO: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD [2020-01-08T06:48:24] DEBUG: hiding cursor [2020-01-08T06:48:24] NOTE: connected to server [2020-01-08T06:50:01] DEBUG: clipboard changed [2020-01-08T06:50:01] DEBUG: opening clipboard [2020-01-08T06:50:01] DEBUG: closing clipboard [2020-01-08T06:50:01] DEBUG: sending clipboard 0 seqnum=0 [2020-01-08T06:50:01] DEBUG: sent clipboard size=17770 ```
Author
Owner

@Hack5190 commented on GitHub (Jan 14, 2020):

@socketbox, The expected/desired behavior is that when both machines wake they reconnect without any user intervention.

More times than not - reconnecting requires the user to apply random work around's that work inconsistently. Examples of previous work around's I have had to use include:

restarting barrier (on one or both) machines
removing the server or client from barrier
disabling SSL on server
nuke all configuration files (both server & client)

<!-- gh-comment-id:574202993 --> @Hack5190 commented on GitHub (Jan 14, 2020): @socketbox, The expected/desired behavior is that _**when both machines wake**_ they reconnect without any user intervention. More times than not - reconnecting requires the user to apply random work around's that work inconsistently. Examples of previous work around's I have had to use include: restarting barrier (on one or both) machines removing the server or client from barrier disabling SSL on server nuke all configuration files (both server & client)
Author
Owner

@kumar-j commented on GitHub (Jan 21, 2020):

@socketbox, The expected/desired behavior is that when both machines wake they reconnect without any user intervention.

More times than not - reconnecting requires the user to apply random work around's that work inconsistently. Examples of previous work around's I have had to use include:

restarting barrier (on one or both) machines
removing the server or client from barrier
disabling SSL on server
nuke all configuration files (both server & client)

Exactly, I have to perform different work around's listed above and one of them works randomly. This is very annoying.

<!-- gh-comment-id:576630208 --> @kumar-j commented on GitHub (Jan 21, 2020): > @socketbox, The expected/desired behavior is that _**when both machines wake**_ they reconnect without any user intervention. > > More times than not - reconnecting requires the user to apply random work around's that work inconsistently. Examples of previous work around's I have had to use include: > > restarting barrier (on one or both) machines > removing the server or client from barrier > disabling SSL on server > nuke all configuration files (both server & client) Exactly, I have to perform different work around's listed above and one of them works randomly. This is very annoying.
Author
Owner

@KapitanOczywisty commented on GitHub (Mar 3, 2020):

I have also this issue: barrier no longer works after hibernation/sleep. In my case win 7 - win 10, but restarting server seems to fix issue.

<!-- gh-comment-id:593880248 --> @KapitanOczywisty commented on GitHub (Mar 3, 2020): I have also this issue: barrier no longer works after hibernation/sleep. In my case win 7 - win 10, but restarting server seems to fix issue.
Author
Owner

@github-actions[bot] commented on GitHub (Oct 1, 2020):

Is this issue still an issue for you? Please do comment and let us know! Alternatively, you may close the issue yourself if it is no longer an problem

<!-- gh-comment-id:701709285 --> @github-actions[bot] commented on GitHub (Oct 1, 2020): Is this issue still an issue for you? Please do comment and let us know! Alternatively, you may close the issue yourself if it is no longer an problem
Author
Owner

@kumar-j commented on GitHub (Oct 1, 2020):

I am still facing this issue whenever my mac goes to sleep or hibernate mode. I have to do some random solutions such as reloading the barrier on windows, reloading on mac. And, if nothing works, then restarting both barrier softwares and lastly I have to delete the mac client and have to add it all over again.

<!-- gh-comment-id:702296287 --> @kumar-j commented on GitHub (Oct 1, 2020): I am still facing this issue whenever my mac goes to sleep or hibernate mode. I have to do some random solutions such as reloading the barrier on windows, reloading on mac. And, if nothing works, then restarting both barrier softwares and lastly I have to delete the mac client and have to add it all over again.
Author
Owner

@shaunchurch commented on GitHub (Oct 11, 2020):

I am also seeing similar issues, on macOS 10.15.6. After sleep/hibernate, the mouse will move over to the client machine, but the keyboard remains active only on the server.

The only thing that consistently fixes it is a reboot of both machines.

Any combination of: stopping the server, stopping the client (including closing Barrier on both machines), deleting the client and readding the client results in the same behaviour: Mouse moves over to the second machine. Keyboard does not.

<!-- gh-comment-id:706674782 --> @shaunchurch commented on GitHub (Oct 11, 2020): I am also seeing similar issues, on macOS 10.15.6. After sleep/hibernate, the mouse will move over to the client machine, but the keyboard remains active only on the server. The only thing that consistently fixes it is a reboot of both machines. Any combination of: stopping the server, stopping the client (including closing Barrier on both machines), deleting the client and readding the client results in the same behaviour: Mouse moves over to the second machine. Keyboard does not.
Author
Owner

@gaztec22 commented on GitHub (Mar 31, 2021):

I'm also experiencing this issue. I have a macos client and a windows server. Whenever the macos wakes from sleep barrier doesn't work. Furthermore I can restart or quit the app at all as its unresponsive.. The only action that works is to restart the macbook.. After restart it connects again to the windows server just fine..

It's actually quite disruptive to have to restart the macbook each time it wakes from sleep. It actually makes it fairly pointless for it to go to sleep at all...

<!-- gh-comment-id:810722467 --> @gaztec22 commented on GitHub (Mar 31, 2021): I'm also experiencing this issue. I have a macos client and a windows server. Whenever the macos wakes from sleep barrier doesn't work. Furthermore I can restart or quit the app at all as its unresponsive.. The only action that works is to restart the macbook.. After restart it connects again to the windows server just fine.. It's actually quite disruptive to have to restart the macbook each time it wakes from sleep. It actually makes it fairly pointless for it to go to sleep at all...
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#420
No description provided.