recovery from a lost/broken connection when -dontdisconnect and -nevershared are enabled.

[pvw]

Hello,

I am running Turbo VNC server, version 2.0.1, with options  -dontdisconnect and -nevershared.   My client accesses the server through a VPN tunnel with dynamically assigned IP address.

In the first VPN session the client address was 10.202.110.51.  The VPN connection failed due to some network glitch while I was using VNC and broke the client-server connection.

I established a new VPN session, but the second time the host was assigned a different IP address which was 10.202.110.53.   Attempts to reconnect to the VNC server with the new IP address produce this error.

05/02/2018 18:05:27 Got connection from client 10.202.110.53

05/02/2018 18:05:27   (other clients 10.202.110.51)

05/02/2018 18:05:27 Using protocol version 3.8

05/02/2018 18:05:27 Enabling TightVNC protocol extensions

05/02/2018 18:05:29 Full-control authentication enabled for 10.202.110.53

05/02/2018 18:05:29 -dontdisconnect: Not shared & existing client

05/02/2018 18:05:29   refusing new client 10.202.110.53

05/02/2018 18:05:29 Client 10.202.110.53 gone

05/02/2018 18:05:29 Statistics:

05/02/2018 18:05:29   framebuffer updates 0, rectangles 0, bytes 0

Evidently the server fails to recognize that the connection to 10.202.110.51 is no longer valid.   How can I reconnect to the existing session?  Is there a way to tell the server that 10.202.110.51 is gone, so that the VNC session can be continued?

Thanks

[DRC]

If you upgrade the server to the latest stable release (2.1.2), then you
can use a new server option that was introduced in 2.1.1 (-disconnect).
That should work around the issue. If you want to keep using 2.0.1,
then you can also edit /opt/TurboVNC/bin/vncserver and take out this line:

$cmd .= " -dontdisconnect";

which will produce the same behavior as passing -disconnect to the newer
server.

As far as why the server isn't disconnecting the existing client, I'm
wondering whether you are encountering another facet of this issue:

https://github.com/TurboVNC/turbovnc/issues/112

I have yet to reproduce that issue and thus haven't diagnosed its
underlying cause. I was suspicious that it might have something to do
with TLS encryption, but since the 2.0.1 server didn't have built-in
encryption, that can't be the underlying cause in your case. Maybe the
VPN is somehow keeping the connection open? Are you able to reproduce
this issue without the VPN?

DRC

[pvw]

I don't have the technical expertise to know if issue #112 is or is not related, and I do not have an easy way to test if this behavior can be reproduced without VPN.

This morning, I was able to connect to the same session.   The log shows 12 minutes elapsed until *.51 was recognized as gone.  The log continues as follows:

05/02/2018 18:17:22 rfbProcessClientNormalMessage: read: Connection timed out

05/02/2018 18:17:22 Client 10.202.110.51 gone

05/02/2018 18:17:22 Statistics:

05/02/2018 18:17:22   key events received 14801, pointer events 51149

05/02/2018 18:17:22   framebuffer updates 41397, rectangles 443340, bytes 714091488

05/02/2018 18:17:22     LastRect markers 15891, bytes 190692

05/02/2018 18:17:22     cursor shape updates 2053, bytes 2475659

05/02/2018 18:17:22     cursor position updates 6, bytes 72

05/02/2018 18:17:22     CopyRect rectangles 8322, bytes 133152

05/02/2018 18:17:22     Tight rectangles 417068, bytes 711291913

05/02/2018 18:17:22   raw equivalent 15672.299680 Mbytes, compression ratio 22.033569

06/02/2018 07:34:18 Got connection from client 10.202.110.53

06/02/2018 07:34:18 Using protocol version 3.8

06/02/2018 07:34:18 Enabling TightVNC protocol extensions

06/02/2018 07:34:19 Full-control authentication enabled for 10.202.110.53

...

[DRC]

That does sound like the same or a similar issue. :| Wish I could
figure out how to reproduce it. I did find this document, which
suggests that such problems might be the fault of the VPN:

https://support.realvnc.com/knowledgebase/article/View/286/12/notes-on-using-vnc-over-a-vpn-connection

However, it's unclear exactly why the problems affect VNC and not
anything else. If the TurboVNC Server fails to communicate with the
client, then it starts a 20-second timer. It will continue trying to
communicate with the client for that 20 seconds, and if it fails to do
so, the client will be disconnected. Something about the VPN is
apparently interfering with that timeout mechanism.

Hopefully the procedure I described in the previous message at least
works around the issue.

What VPN software are you using?

DRC

[pvw]

I have asked my network manager to look at this post, and I will post back to let you know what his findings are.  He corrected me by stating that the Cisco OEAP ("Office Extended Access Point"), which provides a network connection from my remote location into the internal corporate network, is "not a VPN".  My apologies for getting this aspect of the initial problem description wrong.

[DRC]

It might not strictly be a VPN, but regardless, it is changing the
nature of the network connection. However, it doesn't appear as if the
user who was experiencing #112 is using the same technology, so the
problems might be unrelated, or they might not be related to the network
at all. I am grasping at straws here.