debauchee / barrier

Open-source KVM software
Other
27.64k stars 1.51k forks source link

MacOS idle client cannot reconnect with message "DINF" after period of time #885

Open ravenium opened 4 years ago

ravenium commented 4 years ago

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:

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

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.

plajjan commented 4 years ago

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.

sgrienen commented 3 years ago

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.

zgxsin commented 3 years ago

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

aleksipirttimaa commented 3 years ago

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.

Jan02 commented 2 years ago

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.

tamsky commented 2 years ago

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 1 year ago

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

fordodone commented 1 year ago

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

charel commented 1 year ago

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

leafgray commented 1 year ago

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

MatthewMartinFD commented 1 year ago

Seeing this too, identical to the original poster.

scirelli commented 9 months ago

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