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.