VNC Issues - gnutls_record_send: The TLS connection was non-properly terminated

English Applications
#1

Hey all, I appear to be having an issue with my VNC connections from time to time. I connect to my server via VNC and use the vncsession-manager to make my session persistent. Sometimes my internet will **** out and when I go to connect back in, I can re-join my session. Other times when I click on the session, it just disconnects. When this happens, I cannot get back in, it keeps disconnecting me every time I try to connect back in. Here are the syslogs I get when this happens, but I cannot seem to make head nor tails of this. Hoping someone can help me out.

2019-04-17T10:04:35.924781-05:00 linux-qrnb with-vnc-key.sh[1227]: Accepted client 93883045096160.
2019-04-17T10:04:35.940836-05:00 linux-qrnb Xvnc[29574]: vncext: VNC extension running!
2019-04-17T10:04:35.941052-05:00 linux-qrnb Xvnc[29574]: vncext: inetd wait
2019-04-17T10:04:35.941190-05:00 linux-qrnb Xvnc[29574]: vncext: created VNC server for screen 0
2019-04-17T10:04:36.133211-05:00 linux-qrnb with-vnc-key.sh[1227]: Spawned Xvnc (id: #15, pid: 29574, display: 2)
2019-04-17T10:04:36.140216-05:00 linux-qrnb with-vnc-key.sh[1227]: Spawned greeter (pid: 29581, display: :2)
2019-04-17T10:04:36.140371-05:00 linux-qrnb with-vnc-key.sh[1227]: Opening connection to Xvnc #15
2019-04-17T10:04:36.141033-05:00 linux-qrnb Xvnc[29574]: Connections: accepted: ::0
2019-04-17T10:04:36.141166-05:00 linux-qrnb Xvnc[29574]: SConnection: Client needs protocol version 3.8
2019-04-17T10:04:36.141273-05:00 linux-qrnb Xvnc[29574]: SConnection: Client requests security type None(1)
2019-04-17T10:04:36.143974-05:00 linux-qrnb Xvnc[29574]: VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
2019-04-17T10:04:36.190219-05:00 linux-qrnb vncmanager-greeter[29581]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-vnc'
2019-04-17T10:04:38.456109-05:00 linux-qrnb Xvnc[29574]: VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888
2019-04-17T10:04:40.528939-05:00 linux-qrnb with-vnc-key.sh[1227]: Opening connection to Xvnc #9
2019-04-17T10:04:40.529172-05:00 linux-qrnb with-vnc-key.sh[1227]: Terminating greeter (pid: 29581)
2019-04-17T10:04:40.529277-05:00 linux-qrnb with-vnc-key.sh[1227]: Closing connection to Xvnc #15
2019-04-17T10:04:40.529787-05:00 linux-qrnb Xvnc[27801]: Connections: accepted: ::0
2019-04-17T10:04:40.529938-05:00 linux-qrnb Xvnc[27801]: SConnection: Client needs protocol version 3.8
2019-04-17T10:04:40.530060-05:00 linux-qrnb Xvnc[27801]: SConnection: Client requests security type None(1)
2019-04-17T10:04:40.530177-05:00 linux-qrnb Xvnc[27801]: VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
2019-04-17T10:04:40.530701-05:00 linux-qrnb Xvnc[29574]: Connections: closed: ::0 (Clean disconnection)
2019-04-17T10:04:40.530840-05:00 linux-qrnb Xvnc[29574]: EncodeManager: Framebuffer updates: 8
2019-04-17T10:04:40.530971-05:00 linux-qrnb Xvnc[29574]: EncodeManager:   Raw:
2019-04-17T10:04:40.531120-05:00 linux-qrnb Xvnc[29574]: EncodeManager:     Full Colour: 8 rects, 221.468 kpixels
2019-04-17T10:04:40.531299-05:00 linux-qrnb Xvnc[29574]: EncodeManager:                  865.203 KiB (1:1 ratio)
2019-04-17T10:04:40.531427-05:00 linux-qrnb Xvnc[29574]: EncodeManager:   RRE:
2019-04-17T10:04:40.531543-05:00 linux-qrnb Xvnc[29574]: EncodeManager:     Solid: 11 rects, 590.688 kpixels
2019-04-17T10:04:40.531861-05:00 linux-qrnb Xvnc[29574]: EncodeManager:            220 B (1:10740.4 ratio)
2019-04-17T10:04:40.532053-05:00 linux-qrnb Xvnc[29574]: EncodeManager:     Indexed RLE: 6 rects, 81.184 kpixels
2019-04-17T10:04:40.532237-05:00 linux-qrnb Xvnc[29574]: EncodeManager:                  5.40234 KiB (1:58.7144 ratio)
2019-04-17T10:04:40.532397-05:00 linux-qrnb Xvnc[29574]: EncodeManager:   Total: 25 rects, 893.34 kpixels
2019-04-17T10:04:40.532587-05:00 linux-qrnb Xvnc[29574]: EncodeManager:          870.82 KiB (1:4.0076 ratio)
2019-04-17T10:04:40.532730-05:00 linux-qrnb Xvnc[29574]: ComparingUpdateTracker: 908.028 kpixels in / 893.18 kpixels out
2019-04-17T10:04:40.532919-05:00 linux-qrnb Xvnc[29574]: ComparingUpdateTracker: (1:1.01662 ratio)
2019-04-17T10:04:40.658786-05:00 linux-qrnb with-vnc-key.sh[1227]: Exception in thread of client 93883045096160: gnutls_record_send: The TLS connection was non-properly terminated.
2019-04-17T10:04:40.659027-05:00 linux-qrnb with-vnc-key.sh[1227]: Disconnected client 93883045096160.
2019-04-17T10:04:40.659246-05:00 linux-qrnb with-vnc-key.sh[1227]: Closing connection to Xvnc #9
2019-04-17T10:04:40.659461-05:00 linux-qrnb Xvnc[27801]: Connections: closed: ::0 (read: Connection reset by peer (104))
2019-04-17T10:04:40.659649-05:00 linux-qrnb Xvnc[27801]: EncodeManager: Framebuffer updates: 1
2019-04-17T10:04:40.659826-05:00 linux-qrnb Xvnc[27801]: EncodeManager:   Raw:
2019-04-17T10:04:40.659991-05:00 linux-qrnb Xvnc[27801]: EncodeManager:     Full Colour: 29 rects, 1.74765 Mpixels
2019-04-17T10:04:40.660162-05:00 linux-qrnb Xvnc[27801]: EncodeManager:                  6.6671 MiB (1:1 ratio)
2019-04-17T10:04:40.660333-05:00 linux-qrnb Xvnc[27801]: EncodeManager:   RRE:
2019-04-17T10:04:40.660530-05:00 linux-qrnb Xvnc[27801]: EncodeManager:     Indexed RLE: 2 rects, 51.387 kpixels
2019-04-17T10:04:40.660722-05:00 linux-qrnb Xvnc[27801]: EncodeManager:                  9.19141 KiB (1:21.8415 ratio)
2019-04-17T10:04:40.660900-05:00 linux-qrnb Xvnc[27801]: EncodeManager:   Total: 31 rects, 1.79904 Mpixels
2019-04-17T10:04:40.661080-05:00 linux-qrnb Xvnc[27801]: EncodeManager:          6.67607 MiB (1:1.02802 ratio)
2019-04-17T10:04:40.661244-05:00 linux-qrnb Xvnc[27801]: ComparingUpdateTracker: 0 pixels in / 0 pixels out
2019-04-17T10:04:40.661401-05:00 linux-qrnb Xvnc[27801]: ComparingUpdateTracker: (1:-nan ratio)
2019-04-17T10:04:45.542377-05:00 linux-qrnb Xvnc[29574]: VNCServerST: MaxDisconnectionTime reached, exiting
#2

aIpm purely speculating,
But I’d expect that if you’re disconnected improperly, as long as that session is still alive you wouldn’t be able to re-connect (The TLS session would believe your reconnection is an intrusion attempt perhaps due to unexpected TCP packet id numbers). If this is wha is happening, then the network session has to terminated (perhaps by timeout) and then a new session can be created. This wouldn’t necessarily have any effect on the running logged in session running on the remote machine.

Recommend you troubleshoot your networking problems.
If your network problems are caused by interference due to congestion, RF or similar, you can try modifications I recommend in this paper I wrote long ago, they still apply to latest openSUSE as much as they were effective long ago.

https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection

Of course, if your problems are caused by faulty hardware or something similar, the above won’t help.

TSU

#3

I appreciate the suggestions. Unfortunately the network issues are not something I can resolve as it is due to poor WAN connectivity in a remote location that I am at. So, when the internet drops, so does the VPN.

The thing that perplexes me is that I CAN re-connect back in via VNC, and I am greeted with the sessionmanager, but when I try to select the session is when it kicks me. (maybe this is what you were trying to convey to me and I cant get it through my thick skull).

Is there anything I can SSH in and kill to allow me back in? The only thing I’ve found so far is kill the entire user session, but then I have to start fresh again whatever I was working on.

Thanks!

#4

The key to a solution likely requires that you imagine yourself as the VNC server,
Ordinarily a session is tracked and its integrity assured by always expecting what happens next
When you have an unexpected disconnection, then the Server is likely waiting for what it expects next and not receiving it.
If your machine attempts to re-connect to the existing session, by trying to re-establish the connection your machine isn’t likely providing that something which is expected next. Beyond that, I speculated that “expected secret” to be packet enumeration which is common and utilizes practically no overhead but this detail doesn’t have to be exactly what is happening, it’s only essential to know that you can’t provide what is required to make a re-connection to an existing network session.

Given that,
Then you should understand that the VNC server can’t understand whether your perceived inaction is because you’re simply idle (eg reading some text) or if something more serious happened like a network disconnection.

The VNC server will wait… and wait… for a set amount of time (idle timeout setting), then regardless if the inactivity is intentional or not, close the connection.
And then, when the VNC server no longer has a network connection to the running User session whether the User intended or not, It will be willing to accept a new connection because only then it won’t violate someone without original authorization trying to hack into an existing network connection.

This is mostly speculation on my part, but the bottom line is that you should configure your idle_timeout setting appropriately…long enough that your regular use won’t disconnect on its own but long enough that you won’t have to wait too long before trying to re-connect.

There are various ways to run TingerVNC Server, the exact way you modify this setting may depend on how your VNC server is set up,
The following is the MAN page with this setting for running XVNC server

https://tigervnc.org/doc/Xvnc.html

Or, I could be all wrong…

Last comment about my previous post, the mitigations described in my paper are expressly intended to address a wide variety of networking issues that can be largely be beyond your control… like network congestion, some mis-routing, some mis-configuration, RF interference, etc, anything that can cause delayed rather than dropped packets (or even if not too many dropped packets happen). If the endpoint your’e connecting to has faulty hardware, that’s completely different.

Hope this works for you,
TSU

#5

Also,
See the LEAP Documentation for setting up one time vs persistent sessions.
If you set up one time sessions, then the network connection is tightly integrated with the User session so when one terminates the other does, too. As the name implies, when you are configured for persistent sessions, then you can connect, disconnect and reconnect to a running session.

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.vnc.html

TSU

#6

Thanks for the elaboration.

After disconnect, I CAN connect back to the VNC server, so I do not think that is the issue. The issue is when I choose the session from session manager (The same session manager from the persistent VNC connection instructions that you referenced).