Wait for External SSH

[Parakleta]

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]

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]

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

[Parakleta]

The change is in the way external SSH process is launched from commit 125132d.

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 PowerShell/Win32-OpenSSH#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]

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]

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

turbovnc/java/com/turbovnc/vncviewer/Tunnel.java

Line 267 in f2b115f

if (p == null || p.waitFor() != 0)

hangs forever.

[Parakleta]

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