[GH-ISSUE #885] MacOS idle client cannot reconnect with message "DINF" after period of time

gitea-mirror commented

2026-05-05 06:58:06 -06:00

Owner

Originally created by @ravenium on GitHub (Sep 26, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/885

Describe the bug
I have a windows 10 desktop (server) and a macbook (client) that I have setup for sharing. It works well most of the time (occasional clipboard issue that requires a server restart, but that's another thread)! However, I've noticed when I come back to my desk after a long period of time (overnight for example) I find barrier to be disconnected. On the server I get the following initial error:

[2020-09-25T22:41:04] ERROR: ssl error occurred (system call failure)
[2020-09-25T22:41:04] ERROR: eof violates ssl protocol
[2020-09-25T22:41:04] NOTE: client "macbook" has disconnected
[2020-09-25T22:41:25] INFO: OpenSSL 1.0.2l 25 May 2017
[2020-09-25T22:41:25] INFO: accepted secure socket
[2020-09-25T22:41:25] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2020-09-25T22:41:25] NOTE: accepted client connection
[2020-09-25T22:41:25] ERROR: invalid message from client "macbook": DINF
[2020-09-25T22:41:25] NOTE: new client disconnected

(the last 6 lines repeat repeatedly as the client thrashes trying to reconnect)

On the client-side I get the following (slightly redacted for good hygiene and paranoia) messages:

[2020-09-25T22:41:06] INFO: process exited normally
[2020-09-25T22:41:06] INFO: detected process not running, auto restarting

[2020-09-25T22:41:27] INFO: starting client
[2020-09-25T22:41:27] INFO: config file: /private/var/folders/fk/3hbckppj7jjd3lhpaa4t78440154gp/T/Barrier.rGWJlU
[2020-09-25T22:41:27] INFO: log level: INFO
[2020-09-25T22:41:27] INFO: drag and drop enabled
[2020-09-25T22:41:27] NOTE: started client
[2020-09-25T22:41:27] NOTE: connecting to '': :24800
[2020-09-25T22:41:27] INFO: OpenSSL 1.1.1g 21 Apr 2020
2020-09-25 22:41:27.710 barrierc[65280:432218] starting cocoa loop
[2020-09-25T22:41:27] NOTE: server fingerprint:
[2020-09-25T22:41:27] NOTE: trustedServersFilename: /Users/me/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt
[2020-09-25T22:41:27] NOTE: Opened trustedServersFilename: /Users/me/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt
[2020-09-25T22:41:27] NOTE: Fingerprint matches trusted fingerprint
[2020-09-25T22:41:27] INFO: connected to secure socket
[2020-09-25T22:41:27] INFO: server ssl certificate info: /CN=Barrier
[2020-09-25T22:41:27] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2020-09-25T22:41:27] NOTE: disconnected from server

(the last 13 lines repeat to infinity)

If I manually stop the barrier client on my macbook and restart it, it connects again just fine. If I manually stop and start the server, nothing changes. It looks like there's something happening with the macos client that only happens after a period of time.

To Reproduce

Steps to reproduce the behavior:

Use a Windows 10 Server, Mac Client (clipboard sharing enabled, drag and drop and other options off)
Let systems idle for at least a day or two (doesn't always happen overnight)
Error occurs and you'll notice client has disconnected and has hit logs with repeated reconnect messages.

Expected behavior
Clients should maintain connectivity, but if process exits it should gracefully restart and reconnect. Not sure what DINF is.

Screenshots
(see logs above)

Desktop (please complete the following information):

OS: MacOS 10.15.7 (Catalina) and Windows 10 version 2004
Barrier version 2.3.3

Additional context

Barrier interface is a secondary interface on the same network (e.g. I multihome both machines and have barrier over a second static IP interface) due to wireless performance. Macbook's secondary interface is a USB NIC.

I found a smattering of similar issues reported that suggests perhaps the macbook is powering down the device when idle to conserve power, not sure if this would impact or why it couldn't restart gracefully.

Originally created by @ravenium on GitHub (Sep 26, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/885 **Describe the bug** I have a windows 10 desktop (server) and a macbook (client) that I have setup for sharing. It works well most of the time (occasional clipboard issue that requires a server restart, but that's another thread)! However, I've noticed when I come back to my desk after a long period of time (overnight for example) I find barrier to be disconnected. On the server I get the following initial error: [2020-09-25T22:41:04] ERROR: ssl error occurred (system call failure) [2020-09-25T22:41:04] ERROR: eof violates ssl protocol [2020-09-25T22:41:04] NOTE: client "macbook" has disconnected [2020-09-25T22:41:25] INFO: OpenSSL 1.0.2l 25 May 2017 [2020-09-25T22:41:25] INFO: accepted secure socket [2020-09-25T22:41:25] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD [2020-09-25T22:41:25] NOTE: accepted client connection [2020-09-25T22:41:25] ERROR: invalid message from client "macbook": DINF [2020-09-25T22:41:25] NOTE: new client disconnected (the last 6 lines repeat repeatedly as the client thrashes trying to reconnect) On the client-side I get the following (slightly redacted for good hygiene and paranoia) messages: [2020-09-25T22:41:06] INFO: process exited normally [2020-09-25T22:41:06] INFO: detected process not running, auto restarting [2020-09-25T22:41:27] INFO: starting client [2020-09-25T22:41:27] INFO: config file: /private/var/folders/fk/3hbckppj7jjd3lhpaa4t78440154gp/T/Barrier.rGWJlU [2020-09-25T22:41:27] INFO: log level: INFO [2020-09-25T22:41:27] INFO: drag and drop enabled [2020-09-25T22:41:27] NOTE: started client [2020-09-25T22:41:27] NOTE: connecting to '<SERVER IP>': <SERVER IP>:24800 [2020-09-25T22:41:27] INFO: OpenSSL 1.1.1g 21 Apr 2020 2020-09-25 22:41:27.710 barrierc[65280:432218] starting cocoa loop [2020-09-25T22:41:27] NOTE: server fingerprint: <fingerprint in hex> [2020-09-25T22:41:27] NOTE: trustedServersFilename: /Users/me/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt [2020-09-25T22:41:27] NOTE: Opened trustedServersFilename: /Users/me/Library/Application Support/barrier/SSL/Fingerprints/TrustedServers.txt [2020-09-25T22:41:27] NOTE: Fingerprint matches trusted fingerprint [2020-09-25T22:41:27] INFO: connected to secure socket [2020-09-25T22:41:27] INFO: server ssl certificate info: /CN=Barrier [2020-09-25T22:41:27] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD [2020-09-25T22:41:27] NOTE: disconnected from server (the last 13 lines repeat to infinity) If I manually stop the barrier client on my macbook and restart it, it connects again just fine. If I manually stop and start the server, nothing changes. It looks like there's something happening with the macos client that only happens after a period of time. **To Reproduce** Steps to reproduce the behavior: 1. Use a Windows 10 Server, Mac Client (clipboard sharing enabled, drag and drop and other options off) 2. Let systems idle for at least a day or two (doesn't always happen overnight) 3. Error occurs and you'll notice client has disconnected and has hit logs with repeated reconnect messages. **Expected behavior** Clients should maintain connectivity, but if process exits it should gracefully restart and reconnect. Not sure what DINF is. **Screenshots** (see logs above) **Desktop (please complete the following information):** - OS: MacOS 10.15.7 (Catalina) and Windows 10 version 2004 - Barrier version 2.3.3 **Additional context** Barrier interface is a secondary interface on the same network (e.g. I multihome both machines and have barrier over a second static IP interface) due to wireless performance. Macbook's secondary interface is a USB NIC. I found a smattering of similar issues reported that suggests perhaps the macbook is powering down the device when idle to conserve power, not sure if this would impact or why it couldn't restart gracefully.

gitea-mirror commented

2026-05-05 06:58:09 -06:00

Author

Owner

@plajjan commented on GitHub (Oct 5, 2020):

I'm seeing this too. Linux server with mac client. Let it idle over the weekend and now seeing:

[2020-10-05T09:25:35] INFO: OpenSSL 1.1.1d  10 Sep 2019
[2020-10-05T09:25:35] INFO: accepted secure socket
[2020-10-05T09:25:35] INFO: TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD

[2020-10-05T09:25:35] NOTE: accepted client connection
[2020-10-05T09:25:35] ERROR: invalid message from client "mbp13": DINF
[2020-10-05T09:25:35] NOTE: new client disconnected

Unlike OP I do not have a secondary interface. Just my local network so shouldn't be any powering down of USB NIC. I am using the built-in wireless NIC.

A restart of barrier fixes it.

@plajjan commented on GitHub (Oct 5, 2020): I'm seeing this too. Linux server with mac client. Let it idle over the weekend and now seeing: ``` [2020-10-05T09:25:35] INFO: OpenSSL 1.1.1d 10 Sep 2019 [2020-10-05T09:25:35] INFO: accepted secure socket [2020-10-05T09:25:35] INFO: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD [2020-10-05T09:25:35] NOTE: accepted client connection [2020-10-05T09:25:35] ERROR: invalid message from client "mbp13": DINF [2020-10-05T09:25:35] NOTE: new client disconnected ``` Unlike OP I do not have a secondary interface. Just my local network so shouldn't be any powering down of USB NIC. I am using the built-in wireless NIC. A restart of barrier fixes it.

gitea-mirror commented

2026-05-05 06:58:10 -06:00

Author

Owner

@sgrienen commented on GitHub (Apr 27, 2021):

Same with Windows 10 1909 acting as a server and MacOS Big Sur 11.2.3 being the client, I see this repeatedly (ERROR: invalid message from client "": DINF) in the logs.

@sgrienen commented on GitHub (Apr 27, 2021): Same with Windows 10 1909 acting as a server and MacOS Big Sur 11.2.3 being the client, I see this repeatedly (ERROR: invalid message from client "<client>": DINF) in the logs.

gitea-mirror commented

2026-05-05 06:58:13 -06:00

Author

Owner

@zgxsin commented on GitHub (Apr 30, 2021):

I have the same issue here: Linux server with a Mac client

@zgxsin commented on GitHub (Apr 30, 2021): I have the same issue here: Linux server with a Mac client

gitea-mirror commented

2026-05-05 06:58:15 -06:00

Author

Owner

@aleksipirttimaa commented on GitHub (May 16, 2021):

I also have this issue.

For me this is easily reproduced by sleeping the Windows 10 server: the macOS client will then be unable to reconnect.

I work around this issue by restarting barrier.app on the client.

@aleksipirttimaa commented on GitHub (May 16, 2021): I also have this issue. For me this is easily reproduced by sleeping the Windows 10 server: the macOS client will then be unable to reconnect. I work around this issue by restarting barrier.app on the client.

gitea-mirror commented

2026-05-05 06:58:17 -06:00

Author

Owner

@Jan02 commented on GitHub (May 13, 2022):

This happens after the macOS client locked screen and idled for a while. The windows server can't reconnect if barrier was closed before the screen is "woken up" on macOS client. To get around this, start barrier on the server before "waking up" macOS.

@Jan02 commented on GitHub (May 13, 2022): This happens after the macOS client locked screen and idled for a while. The windows server can't reconnect if barrier was closed before the screen is "woken up" on macOS client. To get around this, start barrier on the server before "waking up" macOS.

gitea-mirror commented

2026-05-05 06:58:19 -06:00

Author

Owner

@tamsky commented on GitHub (Nov 15, 2022):

Found this happening today, I quit both server and client - and then started both again.
This fixed it.
Prior to that, I had tried restarting each side, one at a time, which did not fix it.
version: barrier 2.4.0-release

@tamsky commented on GitHub (Nov 15, 2022): Found this happening today, I quit both server and client - and then started both again. This fixed it. Prior to that, I had tried restarting each side, one at a time, which did not fix it. version: barrier 2.4.0-release

gitea-mirror commented

2026-05-05 06:58:21 -06:00

Author

Owner

@mahmoudimus commented on GitHub (Apr 11, 2023):

Can confirm this indeed fixes it.

Found this happening today, I quit both server and client - and then started both again.
This fixed it.
Prior to that, I had tried restarting each side, one at a time, which did not fix it.
version: barrier 2.4.0-release

@mahmoudimus commented on GitHub (Apr 11, 2023): Can confirm this indeed fixes it. > Found this happening today, I quit both server and client - and then started both again. > This fixed it. > Prior to that, I had tried restarting each side, one at a time, which did not fix it. > version: barrier 2.4.0-release

gitea-mirror commented

2026-05-05 06:58:23 -06:00

Author

Owner

@fordodone commented on GitHub (May 10, 2023):

I am encountering the same issue. Both Linux server and Mac client screens are turned off for some time. Server shows error log. Client is Macbook in clamshell mode with screen(s) turned off. Opening the Macbook out of clamshell mode turns on the screen and immediately the client connects successfully, and mouse/keyboard control starts working.

Linux server Barrier version 2.4.0-release-ac5a1bfd
MacOS Ventura 13.3.1 client Barrier version 2.4.0-release-3e0d758b

@fordodone commented on GitHub (May 10, 2023): I am encountering the same issue. Both Linux server and Mac client screens are turned off for some time. Server shows error log. Client is Macbook in clamshell mode with screen(s) turned off. Opening the Macbook out of clamshell mode turns on the screen and immediately the client connects successfully, and mouse/keyboard control starts working. Linux server Barrier version 2.4.0-release-ac5a1bfd MacOS Ventura 13.3.1 client Barrier version 2.4.0-release-3e0d758b

gitea-mirror commented

2026-05-05 06:58:25 -06:00

Author

Owner

@charel commented on GitHub (Jun 27, 2023):

Same here; linux host and macos client. In my case the mac went to sleep and I restarted the linux machine.

@charel commented on GitHub (Jun 27, 2023): Same here; linux host and macos client. In my case the mac went to sleep and I restarted the linux machine.

gitea-mirror commented

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

Author

Owner

@leafgray commented on GitHub (Sep 16, 2023):

Same here; mac server & client.... no lucky with restart barrier... version: 2.4.0-release-3e0d758b

Upated：run with --debug DEBUG2

DEBUG1: sending info shape=0,0 0x0 ===> it's the cause may be...... mac client current in locked login screen....

run client with:
barrierc -f --no-tray --debug DEBUG --name Lis-iMac.local --enable-drag-drop --disable-crypto 172.x.x.x

[2023-09-16T17:31:44] INFO: drag and drop enabled
[2023-09-16T17:31:44] DEBUG: starting watchSystemPowerThread
[2023-09-16T17:31:44] DEBUG: adopting new buffer
[2023-09-16T17:31:44] DEBUG: opened display
[2023-09-16T17:31:44] NOTE: started client
[2023-09-16T17:31:44] NOTE: connecting to '172.x.x.x': 172.x.x.x:24800
[2023-09-16T17:31:44] DEBUG: Opening new socket: 03F98470
[2023-09-16T17:31:44] DEBUG: started watchSystemPowerThread
[2023-09-16T17:31:44] DEBUG: waiting for event loop
[2023-09-16T17:31:44] DEBUG: waiting for carbon loop
[2023-09-16T17:31:44] DEBUG: event queue is ready
[2023-09-16T17:31:44] DEBUG: signalling carbon loop ready
[2023-09-16T17:31:44] DEBUG: starting carbon loop
[2023-09-16T17:31:44] DEBUG: carbon loop ready
[2023-09-16T17:31:44] DEBUG: Closing socket: 03F98470
[2023-09-16T17:31:44] NOTE: disconnected from server
[2023-09-16T17:31:44] DEBUG: retry in 1 seconds
2023-09-16 17:31:44.829 barrierc[73183:47549995] starting cocoa loop
[2023-09-16T17:31:45] NOTE: connecting to '172.x.x.x': 172.x.x.x:24800
[2023-09-16T17:31:45] DEBUG: Opening new socket: 03F94900
[2023-09-16T17:31:45] DEBUG: Closing socket: 03F94900
[2023-09-16T17:31:45] NOTE: disconnected from server
[2023-09-16T17:31:45] DEBUG: retry in 1 seconds

@leafgray commented on GitHub (Sep 16, 2023): Same here; mac server & client.... no lucky with restart barrier... version: 2.4.0-release-3e0d758b Upated：run with --debug DEBUG2 DEBUG1: sending info shape=0,0 0x0 ===> it's the cause may be...... **mac client current in locked login screen....** run client with: barrierc -f --no-tray --debug DEBUG --name Lis-iMac.local --enable-drag-drop --disable-crypto 172.x.x.x [2023-09-16T17:31:44] INFO: drag and drop enabled [2023-09-16T17:31:44] DEBUG: starting watchSystemPowerThread [2023-09-16T17:31:44] DEBUG: adopting new buffer [2023-09-16T17:31:44] DEBUG: opened display [2023-09-16T17:31:44] NOTE: started client [2023-09-16T17:31:44] NOTE: connecting to '172.x.x.x': 172.x.x.x:24800 [2023-09-16T17:31:44] DEBUG: Opening new socket: 03F98470 [2023-09-16T17:31:44] DEBUG: started watchSystemPowerThread [2023-09-16T17:31:44] DEBUG: waiting for event loop [2023-09-16T17:31:44] DEBUG: waiting for carbon loop [2023-09-16T17:31:44] DEBUG: event queue is ready [2023-09-16T17:31:44] DEBUG: signalling carbon loop ready [2023-09-16T17:31:44] DEBUG: starting carbon loop [2023-09-16T17:31:44] DEBUG: carbon loop ready [2023-09-16T17:31:44] DEBUG: Closing socket: 03F98470 [2023-09-16T17:31:44] NOTE: disconnected from server [2023-09-16T17:31:44] DEBUG: retry in 1 seconds 2023-09-16 17:31:44.829 barrierc[73183:47549995] starting cocoa loop [2023-09-16T17:31:45] NOTE: connecting to '172.x.x.x': 172.x.x.x:24800 [2023-09-16T17:31:45] DEBUG: Opening new socket: 03F94900 [2023-09-16T17:31:45] DEBUG: Closing socket: 03F94900 [2023-09-16T17:31:45] NOTE: disconnected from server [2023-09-16T17:31:45] DEBUG: retry in 1 seconds

gitea-mirror commented

2026-05-05 06:58:29 -06:00

Author

Owner

@MatthewMartinFD commented on GitHub (Oct 18, 2023):

Seeing this too, identical to the original poster.

@MatthewMartinFD commented on GitHub (Oct 18, 2023): Seeing this too, identical to the original poster.

gitea-mirror commented

2026-05-05 06:58:31 -06:00

Author

Owner

@scirelli commented on GitHub (Feb 12, 2024):

Just an FYI, I accidentally had two barrier servers running on my linux desktop, which caused the other clients to have this "DINF" error.

@scirelli commented on GitHub (Feb 12, 2024): Just an FYI, I accidentally had two barrier servers running on my linux desktop, which caused the other clients to have this "DINF" error.

gitea-mirror referenced this issue

2026-05-05 07:59:15 -06:00

[PR #703] [MERGED] Added toggleScreen function, using hot key to loop through all screens. #1678

Rows
Columns

[GH-ISSUE #885] MacOS idle client cannot reconnect with message "DINF" after period of time #703