IPC connection timeout when GUI connects to Windows service

[Azzurite]

Project

Deskflow

Deskflow version number

v1.17.0+r1 (44bd69fd)

Build type

Deskflow package (downloaded from us)

Operating systems (OS)

• [X] Windows
• [ ] macOS
• [ ] Linux
• [ ] BSD-derived
• [ ] Other

OS versions/distros

Windows 10

Deskflow configuration

Fresh install

What steps will reproduce the problem?

1. Start Deskflow
2. Select either server or client
3. Press "Start"

Log output

[2024-10-05T11:10:17] INFO: starting core client process (service mode)
[2024-10-05T11:10:17] INFO: connecting to background service...
server status: not active
[2024-10-05T11:10:22] CRITICAL: ipc connection timeout

Additional information

Tried it on two different Windows 10 PCs, both can not connect to the background daemon. I see it running in the services/task manager screens but still timeout happens.

Related issues

• #7833
• #7804

[ZorroSvardendahl]

Same issue here. On Windows 11, fresh install of 1.17.0+r1

[nbolton]

Thanks for reporting this. I have noticed this too. It seems intermittent for me. Is it the same for you?

Does restarting the Windows Deskflow service help? If not, does restarting Windows resolve the issue?

If the above helps, does it stay fixed or does it keep occurring? I'm trying to figure out if this is a first install issue or a persistent issue.

Edit: Also, do you also have Synergy, Input Leap or Barrier installed? The service uses TCP IPC to talk with the GUI and the port could already be in use.

[ZorroSvardendahl]

I restarted and seems to work now. I'll post an update if it comes back.

Do not have Synergy, Input Leap or Barrier installed no.

[nbolton]

I restarted and seems to work now. I'll post an update if it comes back.

Do not have Synergy, Input Leap or Barrier installed no.

Thanks for confirming. In that case I'm leaning towards it being an intermittent first install bug.

[sanchuanhehe]

[2024-10-11T12:59:08] WARNING: IPC connection error, connection refused
[2024-10-11T12:59:09] CRITICAL: IPC connection timeout
[2024-10-11T12:59:09] INFO: Retrying connection to background service...
[2024-10-11T12:59:09] INFO: Connecting to background service...
[2024-10-11T12:59:13] WARNING: IPC connection error, connection refused
[2024-10-11T12:59:14] CRITICAL: IPC connection timeout
[2024-10-11T12:59:14] INFO: Retrying connection to background service...
[2024-10-11T12:59:14] INFO: Connecting to background service...
[2024-10-11T12:59:18] WARNING: IPC connection error, connection refused
[2024-10-11T12:59:19] CRITICAL: IPC connection timeout
[2024-10-11T12:59:19] INFO: Retrying connection to background service...
[2024-10-11T12:59:19] INFO: Connecting to background service...

I encountered the same issue, and it happens consistently. Restarting did not help. I had Barrier installed previously. I tried both versions 1.17 and 1.18, but the issue persists:

v1.18.0
IPC connection timeout

[sanchuanhehe]

Barrier has already been uninstalled.

[nbolton]

I believe this happens when the Windows API is holding on to the IPC TCP port, and when the service tries to bind to it, it silently fails. When the GUI connects to the IPC port, it is open and accepting connections but since Windows didn't allow the service to bind to it, it fails silently and times out. You won't see this in IL/Barrier because that doesn't have hello back implemented for IPC (so when this happens in IL/Barrier, it just sits there and does nothing, as it did in the older version of DF/Synergy). Seems like the only way to get Windows to release the port is to reboot, but if something goes wrong with the service first time it starts, like it crashes before telling Windows to release the port, you're back to square one. The long term solution is to use something smarter than TCP for IPC, like files or Unix sockets, but I'll do that when I rewrite the Windows daemon.

TL;DR: Did rebooting Windows solve the issue? If not, then the service might be crashing on start. There is a daemon log file in the binary directory (Program Files). Could you take a look for that? IIRC it's deskflow-daemon.log in the current version or deskflowd.log in older versions.

[silevilence]

TL;DR: Did rebooting Windows solve the issue? If not, then the service might be crashing on start. There is a daemon log file in the binary directory (Program Files). Could you take a look for that? IIRC it's deskflow-daemon.log in the current version or deskflowd.log in older versions.

@nbolton I have same issue and check my log, compare service with my another computer(run normally), this may cause by service deleted by some reason. Here is detail:

I have same problem like sanchuanhehe, and reboot windows doesn't solve the issue. After check the log I think the daemon process itself may not start.

Here is part of my log:

[2024-10-11T11:30:05] INFO: starting new process
[2024-10-11T11:30:06] NOTE: started server, waiting for clients


[2024-10-11T11:30:06] INFO: service status: active
[2024-10-11T11:30:06] INFO: accepted secure socket


[2024-10-11T11:30:06] INFO: network encryption protocol: TLSv1.3


[2024-10-11T11:30:06] NOTE: accepted client connection


[2024-10-11T11:30:06] INFO: local languages: zh, en


[2024-10-11T11:30:06] NOTE: client "SILSurface10" has connected


[2024-10-11T11:31:12] NOTE: client "SILSurface10" has disconnected


[2024-10-11T11:31:17] INFO: accepted secure socket


[2024-10-11T11:31:17] INFO: network encryption protocol: TLSv1.3

[2024-10-11T11:31:17] NOTE: accepted client connection


[2024-10-11T11:31:17] INFO: local languages: zh, en


[2024-10-11T11:31:17] NOTE: client "SILSurface10" has connected


[2024-10-11T11:52:18] INFO: got ipc shutdown message

After 11:52 there is no any log, and the program report that issue.

So I think this may be some problem that daemon service is down. And I check my another computer which have no this issue, find this computer(have problem) miss the Deskflow service. I manual add service back and start the service.

New-Service -Name DeskFlowDaemon -BinaryPathName "D:\Program Files\Deskflow\deskflow-daemon.exe"
Start-Service DeskFlowDaemon

Then program run normal. New log after run service:

[2024-10-12T08:07:04] INFO: using last known command: "D:/Program Files/Deskflow/deskflow-server.exe" -f --no-tray --debug INFO --name ybwzx --ipc --stop-on-desk-switch --enable-crypto --profile-dir C:/Users/ybwzx/AppData/Local --address :24800 -c C:/Users/ybwzx/AppData/Local/Deskflow/deskflow-server.conf --tls-cert C:/Users/ybwzx/AppData/Local/Deskflow/SSL/Deskflow.pem
[2024-10-12T08:07:04] INFO: service command updated
[2024-10-12T08:07:04] INFO: starting new process
[2024-10-12T08:07:04] INFO: activeDesktop:Default


[2024-10-12T08:07:05] INFO: starting new process
[2024-10-12T08:07:05] NOTE: started server, waiting for clients


[2024-10-12T08:07:05] INFO: service status: active

So the problem is why Deskflow service disappear?

[nbolton]

Hmm, struggling to follow your diagnostics. Give me some time to pour over this.

[JustSxm]

On my part I can confirm having the old build (Synergy community) running in the background was causing trouble, make sure nothing called "Synergy" is running in the task manager

[nbolton]

On my part I can confirm having the old build (Synergy community) running in the background was causing trouble, make sure nothing called "Synergy" is running in the task manager

Thanks, you reminded me to raise an issue:

• #7833

[Slient1802]

On my part I can confirm having the old build (Synergy community) running in the background was causing trouble, make sure nothing called "Synergy" is running in the task manager

Thanks, you reminded me to raise an issue:

• Detect installed Synergy, Input Leap, and Barrier #7833

I think you should add a button (or automatic scripts to kill other "Synergy" running in the background -task manager)

[nbolton]

kill other "Synergy" running in the background

I guess we could maybe run a command on button click: runas /user:Administrator "sc stop synergy & sc config synergy start=disabled"

[sithlord48]

I do not think deskflow needs to solve this user problem the same as we dont plan to have code to move your config files etc..

[Slient1802]

It seems that in 1.17.1.0 (a80cea3c) I still encounter this ipc connection timeout bug when connecting between computers Server Logs:

[2024-11-10T14:51:45] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:51:45] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:51:45] NOTE: accepted client connection
[2024-11-10T14:51:45] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:51:47] DEBUG: tls connection closed
[2024-11-10T14:51:47] NOTE: new client disconnected
[2024-11-10T14:51:48] DEBUG: opening new socket: 00077D30
[2024-11-10T14:51:48] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:51:48] INFO: accepted secure socket
[2024-11-10T14:51:48] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:51:48] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:51:48] NOTE: accepted client connection
[2024-11-10T14:51:48] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:51:50] DEBUG: tls connection closed
[2024-11-10T14:51:50] NOTE: new client disconnected
[2024-11-10T14:51:51] DEBUG: opening new socket: 0007FB30
[2024-11-10T14:51:51] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:51:51] INFO: accepted secure socket
[2024-11-10T14:51:51] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:51:51] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:51:51] NOTE: accepted client connection
[2024-11-10T14:51:51] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:51:53] DEBUG: tls connection closed
[2024-11-10T14:51:53] NOTE: new client disconnected
[2024-11-10T14:51:54] DEBUG: opening new socket: 00306910
[2024-11-10T14:51:54] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:51:54] INFO: accepted secure socket
[2024-11-10T14:51:54] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:51:54] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:51:54] NOTE: accepted client connection
[2024-11-10T14:51:54] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:51:56] DEBUG: tls connection closed
[2024-11-10T14:51:56] NOTE: new client disconnected
[2024-11-10T14:51:57] DEBUG: opening new socket: 0030C490
[2024-11-10T14:51:57] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:51:57] INFO: accepted secure socket
[2024-11-10T14:51:57] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:51:57] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:51:57] NOTE: accepted client connection
[2024-11-10T14:51:57] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:51:59] DEBUG: tls connection closed
[2024-11-10T14:51:59] NOTE: new client disconnected
[2024-11-10T14:52:00] DEBUG: opening new socket: 00313AB0
[2024-11-10T14:52:00] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:52:00] INFO: accepted secure socket
[2024-11-10T14:52:00] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:52:00] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:52:00] NOTE: accepted client connection
[2024-11-10T14:52:00] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:52:02] DEBUG: tls connection closed
[2024-11-10T14:52:02] NOTE: new client disconnected
[2024-11-10T14:52:03] DEBUG: opening new socket: 00319030
[2024-11-10T14:52:03] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:52:03] INFO: accepted secure socket
[2024-11-10T14:52:03] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:52:03] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:52:03] NOTE: accepted client connection
[2024-11-10T14:52:03] DEBUG: saying hello as Barrier, protocol v1.8
[2024-11-10T14:52:03] INFO: local languages: en, zh, en
[2024-11-10T14:52:03] DEBUG: received client "Ruan-Slients-PC" info shape=0,0 1920x1080 at 4,0
[2024-11-10T14:52:03] DEBUG: active sides: 2
[2024-11-10T14:52:03] NOTE: client "Ruan-Slients-PC" has connected
[2024-11-10T14:52:05] DEBUG: tls connection closed
[2024-11-10T14:52:05] NOTE: client "Ruan-Slients-PC" has disconnected
[2024-11-10T14:52:05] DEBUG: closing socket: 00319030
[2024-11-10T14:52:05] DEBUG: active sides: 2
[2024-11-10T14:52:06] DEBUG: opening new socket: 00320E90
[2024-11-10T14:52:06] DEBUG: openssl version: OpenSSL 3.3.1 4 Jun 2024
[2024-11-10T14:52:06] INFO: accepted secure socket
[2024-11-10T14:52:06] DEBUG: openssl cipher: TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
[2024-11-10T14:52:06] INFO: network encryption protocol: TLSv1.3
[2024-11-10T14:52:06] NOTE: accepted client connection

Capture bug Picture:

[sithlord48]

@Slient1802 it seams the client connecting is saying hello in Synergy format. your sever is not [2024-11-10T14:52:03] DEBUG: saying hello as Barrier, protocol v1.8 change that in setting or use a newer version of deskflow on the client.

[nbolton]

The IPC connection timeout issue is a different problem. It happens when you install Synergy, Barrier, or Input Leap and then install Deskflow without uninstalling the other apps. This is because they all use the same TCP IPC port, and a resource conflict ensues.

The solution is to uninstall other apps such as Synergy, Barrier, or Input Leap and then reboot. If this doesn't fix it, please let me know.

The long term solution for this will be #7833 and/or using an alternative to TCP IPC such as Unix-file sockets, etc: #7804

[mgomersbach]

Just for anyone who stumbles over this as well, a restart helped for me, as just uninstalling apparently left some things in place for the other apps. I did check services list after uninstalling each, but even when they're gone, it can still conflict somehow.

[Param-P]

an easy solution I found for this was to just start the Deskflow service from Services myself.

[benmordecai]

I had this problem when I had both Barrier and Deskflow installed on Windows (I was working on migrating an old installation of Barrier to Deskflow). I was closing out of Barrier but the Windows service was still running and was set to auto start. When I disabled this, the deskflow error went away.

[nbolton]

We'll fix this in: #7804