search

TurboVNC / turbovnc

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

Connection lost on interface change #418

Open LucasMontero opened 1 month ago

LucasMontero commented 1 month ago

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.

image

Could I avoid this behavior?

Platform: Windows, macOS Version: 3.1.1

dcommander commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 3 weeks ago

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 commented 2 weeks ago

@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 commented 2 weeks ago

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.