Connection lost on interface change

[LucasMontero]

When I'm working on my laptop connected to a dock station via Ethernet interface, and I undock it (switching to Wi-Fi interface), the remote desktop connection is terminated. A dialog box appears, prompting me to reconnect, and the desktop session is closed. This disrupts my workflow and forces me to reestablish the connection.

Could I avoid this behavior?

Platform: Windows, macOS
Version: 3.1.1

[dcommander]

To the best of my knowledge, no. Outbound TCP connections are specific to a network interface and can't switch interfaces. (SSH and other popular remote access software has the same issue.) Some software may be able to automatically re-establish a connection with a server, but VNC can't do that automatically because it has to authenticate with the server.

If you can find another piece of open source remote access software the behaves as you expect, then I can look at what they're doing.

[LucasMontero]

Thank you for the quick response! I missed to give you some of the info 😅 I didn't experience this behavior in a previous version (2.2.3) of the client. I only started noticing it after updating to 3.1.1.

[dcommander]

So it worked properly with both Windows and macOS clients running the TurboVNC 2.2.3 Viewer?

Did you previously use the native Windows TurboVNC 2.2.3 Viewer (as opposed to the Java TurboVNC Viewer, which was optional on Windows with TurboVNC 2.2.3)?

Did you change the way you are connecting when you switched to the TurboVNC 3.1.1 Viewer? (In other words, did you start using the TurboVNC Session Manager or one of the other optional connection methods introduced in 3.0.x and 3.1.x?)

Did you also upgrade the TurboVNC Server to 3.1.x when you upgraded the viewer?

[LucasMontero]

So it worked properly with both Windows and macOS clients running the TurboVNC 2.2.3 Viewer?

I tried today with the macOs client, the behavior is the same as the newest windows client (The java one), but it worked for the native windows one. Seems like something related with the java client.

Did you previously use the native Windows TurboVNC 2.2.3 Viewer (as opposed to the Java TurboVNC Viewer, which was optional on Windows with TurboVNC 2.2.3)?

Yes, I was using the native client (vncviewer.exe).

Did you change the way you are connecting when you switched to the TurboVNC 3.1.1 Viewer? (In other words, did you start using the TurboVNC Session Manager or one of the other optional connection methods introduced in 3.0.x and 3.1.x?)

No, I didn't start using the session manager after update.

Did you also upgrade the TurboVNC Server to 3.1.x when you upgraded the viewer?

I'm currently using version 2.2.6 as TurboVNC server on this end (Using Xvnc).

[dcommander]

Unfortunately I have no clue at the moment. The obvious stuff (like SOL_SOCKET options) appears to be the same between the two viewers. The best I can do in terms of simulating the undocking process is to disconnect the ethernet cable and immediately enable the wi-fi interface. The only way I can run Windows on a machine with a wi-fi adapter is to run it in Parallels on my Mac, and the issue isn't reproducible in that case. (In response to the simulated undocking, both the Java and native Windows TurboVNC Viewers temporarily freeze and then start working again.) That isn't really a valid test, however, because Parallels is emulating the network interface and presumably has some sort of fault tolerance code. In response to the same simulated undocking, the macOS TurboVNC Viewer freezes and eventually times out, but so does SSH and so do other VNC viewers.

Can you try a different Windows VNC viewer, such as TigerVNC's or UltraVNC's, and see how they behave? More data points will help me determine whether the correct behavior is attributable to something low-level (such as Winsock) or whether there is something that the application does to enable the correct behavior.

[dcommander]

@LucasMontero Have you had a chance to try a different Windows VNC viewer? I would really like to resolve this issue before the TurboVNC 3.1.2 release, but I need your help, since I can't reproduce the issue.

[LucasMontero]

Sorry for the delay @dcommander. I'm currently moving, so I didn't have so much time. I have issues similar to yours as my main OS is a Fedora but I'm looking for solutions. I will come with an answer as soon as possible.

[LucasMontero]

@dcommander I ran a test with TigerVNC and the behavior is similar, on network interface change the connection drops and prompts for a reconnection.

[dcommander]

Ugh. OK, that tells me that it probably only worked accidentally with the Windows TurboVNC 2.2.x Viewer. I need to do some more testing and try to reproduce the issue properly, since nothing in the old Windows TurboVNC Viewer code indicates why the behavior might be different.

[ocehugo]

Hi @dcommander ,

I have something similar that may be related:

When a connection is lost, the vncviewer software can only connect again to the server if I restart the application.

Typical case scenario is: ethernet connection is lost -> pop-up dialogue is shown -> hit ok -> ... -> re-establish eth connection -> select connect -> can't connect anymore until I restart the application.

I use the SSH Gateway option (but not the VNC server as a gateway) and have X.509 certificates.

[dcommander]

@ocehugo Unfortunately I cannot reproduce that issue either.