TigerVNC Viewer Freezes

[E B]

Hello TigerVNC experts,

When I VNC into a remote server, everything works fine for a while, then unpredictably the screen locks up. First, the remote window stops accepting my input, then about two seconds later the curser (e.g. in gedit) stops flashing. The terminal I was using for an ssh tunnel also freezes up (but it never freezes when I'm using regular SSH). It never comes back, but vncserver is still running - I can kill the terminal and TigerVNC window, reconnect, and everything's still there.

This seems to happen more often when bandwidth is being used (it never happens when the screen is staring at a blank desktop while I'm getting lunch, and happens most often when a window is displaying quickly changing content, even if that content is mostly covered by another window). This didn't happen when I used realvnc's client (which lacks features I need).

Has anyone encountered this behavior before? It's starting to happen frequently enough that it is becoming difficult to get work done. Any advice would be greatly appreciated!

I'm using TigerVNC Viewer 64-bit v1.11.0 on Win10. I connect via ssh tunnel (in Ubuntu 20.04 via WSL 2), through a VPN, to a CentOS 7 server running, I believe, "Xvnc TigerVNC 1.8.0".

The server log from connection through freezing up looks like:

Thu Jan 28 11:20:44 2021

 Connections: accepted: 127.0.0.1::48076

 SConnection: Client needs protocol version 3.8

 SConnection: Client requests security type VeNCrypt(19)

 SVeNCrypt:   Client requests security type TLSVnc (258)

Thu Jan 28 11:20:47 2021

 VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888

 VNCSConnST:  Client pixel format depth 8 (8bpp) rgb332

Only *after* I close my frozen terminal and vnc window does the below get added to the bottom of the log:

Thu Jan 28 11:24:39 2021

 Connections: closed: 127.0.0.1::48076 (Clean disconnection)

 EncodeManager: Framebuffer updates: 1120

 EncodeManager:   Tight:

 EncodeManager:     Solid: 11.722 krects, 173.533 Mpixels

 EncodeManager:            160.262 KiB (1:1058.29 ratio)

 EncodeManager:     Bitmap RLE: 180 rects, 539.418 kpixels

 EncodeManager:                 5.60352 KiB (1:94.3845 ratio)

 EncodeManager:     Indexed RLE: 18.021 krects, 115.655 Mpixels

 EncodeManager:                  9.70161 MiB (1:11.3902 ratio)

 EncodeManager:     Full Colour: 406 rects, 38.216 kpixels

 EncodeManager:                  14.2812 KiB (1:2.94639 ratio)

 EncodeManager:   Total: 30.329 krects, 289.766 Mpixels

 EncodeManager:          9.87754 MiB (1:28.012 ratio)

 TLS:         TLS session wasn't terminated gracefully

 ComparingUpdateTracker: 1.9206 Gpixels in / 286.17 Mpixels out

 ComparingUpdateTracker: (1:6.71141 ratio)

[Pierre Ossman]

On 28/01/2021 17:48, E B wrote:
> Hello TigerVNC experts,
>
> When I VNC into a remote server, everything works fine for a while, then
> unpredictably the screen locks up. First, the remote window stops accepting
> my input, then about two seconds later the curser (e.g. in gedit) stops
> flashing. The terminal I was using for an ssh tunnel also freezes up (but
> it never freezes when I'm using regular SSH). It never comes back, but
> vncserver is still running - I can kill the terminal and TigerVNC window,
> reconnect, and everything's still there.
>
> This seems to happen more often when bandwidth is being used (it never
> happens when the screen is staring at a blank desktop while I'm getting
> lunch, and happens most often when a window is displaying quickly changing
> content, even if that content is mostly covered by another window). This
> didn't happen when I used realvnc's client (which lacks features I need).
>
> Has anyone encountered this behavior before? It's starting to happen
> frequently enough that it is becoming difficult to get work done. Any
> advice would be greatly appreciated!
>

Sounds like a network issue unfortunately. TigerVNC has no way of
interfering with your ssh terminal (assuming we're not triggering some
bug in OpenSSH).

Your symptoms sound very much like a misconfigured MTU on the network.
In such a scenario everything works fine until you try to send a large
packet, at which point everything permanently locks up.

I think the same thing can also happen with IPv6 with blocked ICMP messages.

Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Eli Bowen]

Thank you Pierre for responding with these ideas! Debugging packet
issues is beyond my ability, but I wanted to give an update in case it
helps others or narrows in on a compatibility issue.

This freeze only occurs when using tigervnc viewer over an ssh tunnel
created with WSL2 (ubuntu). It does not occur when using realvnc viewer
over WSL2, or tigervnc viewer over putty.

For now, I'll just use putty.

FYI, my WSL2 command:
ssh -c aes12...@openssh.com,aes128-ctr,aes128-cbc -Y -C -L
5900:localhost:5902 <username>@<server>

[Eli Bowen]

Finally solved! For anyone else who encounters this issue in the future:

TigerVNC uses some large packets, tunneled over ssh. This is apparently
a well established but unfixed WSL2 ssh issue involving incompatible
maximum packet sizes across firewalls and vpns. There are some
workarounds on here: https://github.com/microsoft/WSL/issues/4690

Explanation here: http://www.snailbook.com/faq/mtu-mismatch.auto.html