unknown message type 80

[jbeichter]

I'm having a problem where noVNC/TurboVNC sessions are sometimes killed for no apparent reason, sometimes when working in the session and sometimes without doing anything to it. The output at that moment started with "Client gone". I thought it would be a network issue - and maybe it is.

To investigate it, I started more or less the same thing in my home network, just to test how stable the connection is. I let it run without interaction, basically checking if it's still running. It ran for almost one day and then it broke down in the moment I checked again. I entered the password for the client's screenlock, the browser showed but already with the "Connect" button of noVNC. So there was no interaction with noVNC. This might be a different problem than the one I wanted to investigate, as there are two lines more logged before "Client gone":

Jan 31 04:16:13 saturn smartd[842]: Device: /dev/sd...
Jan 31 07:15:16 saturn Xvnc[2931]: [1] rfbProcessClientNormalMessage: unknown message type 80
Jan 31 07:15:16 saturn Xvnc[2931]: [1]  ... closing connection
Jan 31 07:15:16 saturn Xvnc[2931]: [1] Client gone
Jan 31 07:15:16 saturn Xvnc[2931]: [1] Statistics:
Jan 31 07:15:16 saturn Xvnc[2931]: [1]   key events received 368, pointer events 9791
Jan 31 07:15:16 saturn Xvnc[2931]: [1]   framebuffer updates 19952, rectangles 350197, bytes 870850063
Jan 31 07:15:16 saturn Xvnc[2931]: [1]     LastRect markers 19212, bytes 230544
Jan 31 07:15:16 saturn Xvnc[2931]: [1]     cursor shape updates 447, bytes 1015164
Jan 31 07:15:16 saturn Xvnc[2931]: [1]     CopyRect rectangles 2, bytes 32
Jan 31 07:15:16 saturn Xvnc[2931]: [1]     Tight rectangles 330536, bytes 869604323
Jan 31 07:15:16 saturn Xvnc[2931]: [1]   raw equivalent 121503.574252 Mbytes, compression ratio 139.722827
Jan 31 07:15:16 saturn Xvnc[2931]: Number of connected clients: 0

Is this a known problem?

[dcommander]

It is definitely not a known issue. The error message in question means that the TurboVNC Server received an unsupported RFB client-to-server message from the VNC viewer (noVNC.) That can occur if a misbehaved client tries to use an RFB extension that the server hasn't advertised that it supports. However, as far as I can tell, noVNC doesn't support message type 80 either, so my best guess is some form of protocol mismatch or mis-implementation. (In other words, either noVNC is sending the wrong number of bytes with a particular RFB client-to-server message, or the TurboVNC Server is processing the wrong number of bytes.) Please send me the full logs from the failing machines in e-mail. Also, if you can consistently reproduce the issue, then please try patching the server as follows:

--- a/unix/Xvnc/programs/Xserver/hw/vnc/rfbserver.c
+++ b/unix/Xvnc/programs/Xserver/hw/vnc/rfbserver.c
@@ -936,6 +936,8 @@ static void rfbProcessClientNormalMessage(rfbClientPtr cl)
 
   READ_OR_CLOSE((char *)&msg, 1, return);
 
+  RFBLOGID("Received message type %d\n", msg.type);
+
   switch (msg.type) {
 
     case rfbSetPixelFormat:

If the issue is due to a protocol mismatch or mis-implementation, either on our end or noVNC's end, then that will help me determine which protocol message was received just prior to the error.

[dcommander]

I have had no luck reproducing this. Unfortunately there is very little I can do with intermittent issues unless a procedure can be found to make them less intermittent. The purpose of the patch I suggested above is to provide a record of the client-to-server message that was received just prior to the error. RFB is not a fault-tolerant protocol (which is why it requires TCP and can't use UDP.) It relies upon the client and server to send and receive exactly the number of bytes specified in an RFB message. If 80 were a valid client-to-server message type, then I would suspect that the client is attempting to use an RFB extension without verifying that the server supports it. However, since 80 is not a valid message type, I suspect that either the client is sending or the server is receiving the wrong number of bytes with the message immediately prior to the failure. If I know what message that is, then I can examine the client and server code for possible protocol mis-implementations. Otherwise, it would be like trying to find a needle in a haystack.

My strong suspicion is that this is a noVNC bug. v1.2.0 is a 5-year-old code base, so it's possible that the bug has been fixed in a later version. It may be a bug that I can work around, but I need to narrow it down first. That will require either more information from your end (e.g. the Xvnc log, with the aforementioned patch applied, from a failing session) or the ability to reliably reproduce the issue.