search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
747 stars 137 forks source link

Wait for External SSH #322

Closed Parakleta closed 2 years ago

Parakleta commented 2 years ago

This hasn't been a problem before but with the most recent development version of the VNCViewer it seems to be able to attempt to use a tunnel faster than my external ssh program can establish it. Because the external ssh program needs to daemonise to allow the process to continue there is a race condition if the ssh program daemonises before the tunnel is fully established.

I have wrapped the ssh program in a script with a sleep of 500ms and this seems to fix it, but I was wondering if it might be possible for you to add a retry with a delay when trying to establish a link through a tunnel using the external SSH option?

Thanks.

dcommander commented 2 years ago

The default tunneling command line, which can be overridden with the VNC_TUNNEL_CMD environment variable or the turbovnc.tunnel system property, hasn't changed since TurboVNC 2.2.x, so I'm not sure why this is suddenly an issue with TurboVNC 3.0. The default tunneling command line only sleeps for 20 ms, so changing that command line via VNC_TUNNEL_CMD is the best approach for increasing the sleep time.

dcommander commented 2 years ago

Note that such a retry might be undesirable for some users, so I think it's better to give users the ultimate control.

Parakleta commented 2 years ago

The change is in the way external SSH process is launched from commit https://github.com/TurboVNC/turbovnc/commit/125132d01c83ec0cc5860e2437ecc5ecf9108ee9.

The main issue was that the error message was very opaque, and it was really only that I was able to compare logs on the server and client that I even figured out what was wrong. For others searching for the issue, if the error is "Could not connect: Connection refused: no further information" you might want to add a delay after starting the tunnel.

The problem is that windows doesn't have a proper way to daemonise applications, so the whole SSH -f option doesn't ever return (see https://github.com/PowerShell/Win32-OpenSSH/issues/999) so instead we need to manually daemonise and return but this means that we miss out on the synchronisation effect of waiting for the tunnels to be established which is available on *nix systems.

Parakleta commented 2 years ago

Actually, I've just realised that your change there may remove the need for me to manually daemonise the ssh call through a script and thus solve the problem... I'll check and get back to you.

Parakleta commented 2 years ago

I cannot get the tunnel to establish using your DEFAULT_TUNNEL_CMD on windows. The -f switch doesn't function as required on windows and so the following https://github.com/TurboVNC/turbovnc/blob/f2b115f207739a1dd2bedcb5a246179e943ee1d6/java/com/turbovnc/vncviewer/Tunnel.java#L267 hangs forever.

Parakleta commented 2 years ago

Sorry I just realised that I already raised this ssh -f issue before in #264. Don't mind me, sorry for the noise.