Viewer freezing since updating server to 1.7.1

[Jernej Simončič]

I recently updated TigerVNC server (which I run as a standalone server
on Gentoo Linux) to 1.7.1 (-r2), and since doing that, VNC viewer
often freezes (I'm normally using TigerVNC viewer on Windows, which I
upgraded to 1.7.1, and when that didn't resolve the freezes, I also
tried with UltraVNC viewer, but it's experiencing same problems).

The freezes don't start immediately - the first day or so when the
server is running, everything appears to work normally, then the
following things happen:

- if I leave viewer connected (but don't interact with it), the
display stops updating (but it appears that at least some keypresses
still make it to the server)

- if I try connecting with another viewer (either while a viewer is
already connected, or after I disconnected one that has frozen), the
viewer freezes before showing password prompt (with TigerVNC viewer,
this means there's nothing on screen, while UltraVNC viewer is
showing it's connection dialog with Status: Connecting ...)

I tried recompiling the server with different USE flags
(enabling/disabling different compile-time options), however it makes
no difference as far as I can see.

I don't see anything useful in the server's log either:

,-----
| Xvnc TigerVNC 1.7.1 - built Apr 27 2017 10:58:30
| Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt)
| See http://www.tigervnc.org for information on TigerVNC.
| Underlying X server release 11901000, The X.Org Foundation
|
|
| Thu Apr 27 11:49:57 2017
| vncext: VNC extension running!
| vncext: Listening for VNC connections on all interface(s), port 5901
| vncext: created VNC server for screen 0
| ** Message: main.vala:110: Session is LXDE
| ** Message: main.vala:111: DE is LXDE
| ** Message: main.vala:142: log directory: /home/p2p/.cache/lxsession/LXDE
| ** Message: main.vala:143: log path: /home/p2p/.cache/lxsession/LXDE/run.log
|
[...]
|
| Fri Apr 28 22:02:14 2017
| Connections: accepted: 192.168.0.5::9313
| SConnection: Client needs protocol version 3.8
| SConnection: Client requests security type VncAuth(2)
| VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
| Connections: closed: 192.168.0.5::9287 (Non-shared connection requested)
| EncodeManager: Framebuffer updates: 0
| EncodeManager: Total: 0 rects, 0 pixels
| EncodeManager: 0 B (1:-nan ratio)
| Connections: closed: 192.168.0.5::9171 (Non-shared connection requested)
| EncodeManager: Framebuffer updates: 0
| EncodeManager: Total: 0 rects, 0 pixels
| EncodeManager: 0 B (1:-nan ratio)
| VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888
|
| Fri Apr 28 23:40:21 2017
| Connections: closed: 192.168.0.5::9313 (Clean disconnection)
| EncodeManager: Framebuffer updates: 38089
| EncodeManager: CopyRect:
| EncodeManager: Copies: 4.239 krects, 370.826 Mpixels
| EncodeManager: 66.2344 KiB (1:21870.6 ratio)
| EncodeManager: Hextile:
| EncodeManager: Bitmap RLE: 579 rects, 189.794 kpixels
| EncodeManager: 20.0342 KiB (1:37.3446 ratio)
| EncodeManager: Indexed RLE: 46.671 krects, 113.275 Mpixels
| EncodeManager: 28.7346 MiB (1:15.0566 ratio)
| EncodeManager: Full Colour: 15.507 krects, 109.386 Mpixels
| EncodeManager: 112.42 MiB (1:3.71332 ratio)
| EncodeManager: Tight:
| EncodeManager: Solid: 14.596 krects, 71.098 Mpixels
| EncodeManager: 228.062 KiB (1:1218.52 ratio)
| EncodeManager: Total: 81.592 krects, 664.775 Mpixels
| EncodeManager: 141.461 MiB (1:17.9332 ratio)
|
| Fri Apr 28 23:40:33 2017
| Connections: accepted: 192.168.0.5::11697
|
| Fri Apr 28 23:45:40 2017
| Connections: accepted: 192.168.0.5::11728
|
| Fri Apr 28 23:48:00 2017
| Connections: accepted: 192.168.0.5::11744
| SConnection: Client needs protocol version 3.8
| SConnection: Client requests security type VncAuth(2)
| VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
| Connections: closed: 192.168.0.5::11728 (Non-shared connection requested)
| EncodeManager: Framebuffer updates: 0
| EncodeManager: Total: 0 rects, 0 pixels
| EncodeManager: 0 B (1:-nan ratio)
| Connections: closed: 192.168.0.5::11697 (Non-shared connection requested)
| EncodeManager: Framebuffer updates: 0
| EncodeManager: Total: 0 rects, 0 pixels
| EncodeManager: 0 B (1:-nan ratio)
|
| Fri Apr 28 23:48:01 2017
| VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888
|
| Fri Apr 28 23:50:34 2017
| Connections: accepted: 192.168.0.5::11753
`-----

In this case, the viewer froze at 23:17 (according to the clock in
taskbar), and I noticed that around 23:40, when I closed the viewer,
and then tried connecting several times before a connection succeeded.

Any ideas what's causing this? Other than having a hard time
establishing a connection to the server, the server itself seems to be
working just fine.

--
< Jernej Simončič ><><><><><><><><><><><>< https://eternallybored.org/ >

Because 10 billion years' time is so fragile, so ephemeral...
it arouses such a bittersweet, almost heartbreaking fondness.

[Pierre Ossman]

On 29/04/17 00:04, Jernej Simončič wrote:
>
> Any ideas what's causing this? Other than having a hard time
> establishing a connection to the server, the server itself seems to be
> working just fine.
>

Looks like some kind of network issue. Do you have a firewall or home
router or such in the way that could be misbehaving?

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 https://plus.google.com/+CendioThinLinc

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

[Jernej Simončič]

On 2. maj 2017, 15:00:12, Pierre Ossman wrote:


>> Any ideas what's causing this? Other than having a hard time
>> establishing a connection to the server, the server itself seems to be
>> working just fine.

No, this happened both on my LAN (just switches between computers),
and when I was connecting from work through IPSec VPN. However, the
issue seems to have gone away in the mean time, without me doing
anything special (I was away over the weekend, since when I got back,
I haven't had any problems yet).

I'll investigate with tcpdump/wireshark if the issue comes back.

[Jernej Simončič]

On Tuesday, May 2, 2017, 15:29:32, Jernej Simončič wrote:

> I'll investigate with tcpdump/wireshark if the issue comes back.

It's happening again. I captured the traffic on both client and
server, and I can see them establish a connection, send the protocol
version, then the connection simply hangs (I can provide the captures
if needed).

Another thing I just noticed: if I connect with IPv6 address (instead
of IPv4), the connection succeedds, even though IPv4 connections are
still hanging.

Is there any way to get more detailed logs from vncserver?

--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

The shortest distance between two points is under construction.
-- McGregor's Revised Maxim

[Pierre Ossman]

On 07/05/17 17:55, Jernej Simončič wrote:
> On Tuesday, May 2, 2017, 15:29:32, Jernej Simončič wrote:
>
>> I'll investigate with tcpdump/wireshark if the issue comes back.
>
> It's happening again. I captured the traffic on both client and
> server, and I can see them establish a connection, send the protocol
> version, then the connection simply hangs (I can provide the captures
> if needed).
>

The captures would be helpful, yes.

> Another thing I just noticed: if I connect with IPv6 address (instead
> of IPv4), the connection succeedds, even though IPv4 connections are
> still hanging.
>

Which further supports that this is a network issue rather than
something in the client or server.

> Is there any way to get more detailed logs from vncserver?
>

You can give it the argument -Log *:stderr:100

[Jernej Simončič]

On Tuesday, May 9, 2017, 14:55:58, Pierre Ossman wrote:

> The captures would be helpful, yes.

The captures are here:
<https://eternallybored.org/misc/vnc/vnc-client.pcapng>
<https://eternallybored.org/misc/vnc/vnc-server.cap>

>> Another thing I just noticed: if I connect with IPv6 address (instead
>> of IPv4), the connection succeedds, even though IPv4 connections are
>> still hanging.
> Which further supports that this is a network issue rather than
> something in the client or server.

Looks like this was just temporary - later connection attempts
resulted in the same symptoms. Note that other services on the same
server do not exhibit these problems.

>> Is there any way to get more detailed logs from vncserver?
> You can give it the argument -Log *:stderr:100

I restarted vncserver with this parameter - is this supposed to result
in more verbose logging in ~/.vnc/<host>:<display>.log, or should I
also add the -fg parameter?

--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

All inanimate objects can move just enough to get in your way.
-- Law of Inanimate Mobility

[Pierre Ossman]

On 09/05/17 22:55, Jernej Simončič wrote:
> On Tuesday, May 9, 2017, 14:55:58, Pierre Ossman wrote:
>
>> The captures would be helpful, yes.
>
> The captures are here:
> <https://eternallybored.org/misc/vnc/vnc-client.pcapng>
> <https://eternallybored.org/misc/vnc/vnc-server.cap>
>

These look fine and don't show any dropped packets. Were these captured
directly on the client and server respectively, or some intermediate
machine?

>>> Is there any way to get more detailed logs from vncserver?
>> You can give it the argument -Log *:stderr:100
>
> I restarted vncserver with this parameter - is this supposed to result
> in more verbose logging in ~/.vnc/<host>:<display>.log, or should I
> also add the -fg parameter?
>

It should show up in that log file, yes. And no, you don't need -fg.

Check with ps that the arguments actually made it all the way to Xvnc.


One more theory. Are you using TigerVNC with an Xorg 1.19 base? If so
then you might have built with Fedora's buggy patch which could explain
this. Please try the beta instead.

[Jernej Simončič]

On Friday, May 12, 2017, 10:15:46, Pierre Ossman wrote:

> These look fine and don't show any dropped packets. Were these captured
> directly on the client and server respectively, or some intermediate
> machine?

Yes, they were done directly on the machines (tcpdump on Linux,
Wireshark on Windows).

I also tried tunneling the connection through SSH, and have the same
hangs.

> It should show up in that log file, yes. And no, you don't need -fg.

I didn't notice this at first, but the parameter did work, and my log
is now full of keystrokes. Unfortunately, it still doesn't give any
more info when connections are hanging.

> One more theory. Are you using TigerVNC with an Xorg 1.19 base? If so
> then you might have built with Fedora's buggy patch which could explain
> this. Please try the beta instead.

It would appear that way - the ebuild has XSERVER_VERSION="1.19.1"
set, and also applies two "119" patches:

Ebuild:
<https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/tigervnc/tigervnc-1.7.1-r2.ebuild>

Patches:
<https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/tigervnc/files/tigervnc-1.7.1-xserver119-compat.patch>
<https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/tigervnc/files/xserver119.patch>

--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

Secret sources are more credible.
-- Nessen's Law

[Jernej Simončič]

On Friday, May 12, 2017, 10:15:46, Pierre Ossman wrote:

> One more theory. Are you using TigerVNC with an Xorg 1.19 base? If so
> then you might have built with Fedora's buggy patch which could explain
> this. Please try the beta instead.

I updated to 1.7.90 today, and will report if the connection freezes
continue.

--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

Once a job is fouled up, anything done to improve it only makes it worse.
-- Finagle's Fourth Law