noVNC broken with Apples Remote Desktop/Screen Sharing (RFB 3.889)?

[joachimhs]

Hi, I am trying to run noVNC on a MacOS X box. I can get the application up and running, but when I try to connect (in the browser) I get:

"Invalid Server 003.889"

[kanaka]

Apparently Apple Remote Desktop/Screen Sharing is using a non-standard RFB (VNC) protocol version 3.889. The RFB standard only specifies 3.003, 3.007 and 3.008. noVNC also supports 3.006 which is a non-standard version reported by UltraVNC.

I also see some indication that Apple may be doing other non-standard things with the protocol and that it is breaking other clients also:

• https://bugs.launchpad.net/ubuntu/+source/vnc/+bug/138935
• http://ubuntuforums.org/showthread.php?t=901608
• http://www.gossamer-threads.com/lists/vnc/list/55888

I think this is solvable, however I don't have a Mac OS X system so we may need to do some back and forth debugging.

First, try the following patch and let me know what happens:

diff --git a/include/rfb.js b/include/rfb.js
index a743c1a..0517a68 100644
--- a/include/rfb.js
+++ b/include/rfb.js
@@ -609,6 +609,7 @@ init_msg = function() {
         switch (sversion) {
             case "003.003": rfb_version = 3.3; break;
             case "003.006": rfb_version = 3.3; break;  // UltraVNC
+            case "003.889": rfb_version = 3.3; break;  // Apple Remote Desktop
             case "003.007": rfb_version = 3.7; break;
             case "003.008": rfb_version = 3.8; break;
             default:

That will detect the non-standard protocol version and try and force the remote desktop to use protocol version 3.003. Also, if that doesn't work, you may need to send me javascript console debug output (see the troubleshooting guide) of the failure.

[primalmotion]

I confirm what kanaka says.

But may try to activate screen sharing instead of remote control. This one should work with standard VNC protocol

[rcarmo]

Actually, I did the above patch by myself last weekend, and it worked fine until I disconnected - which threw the Apple VNC server into a loop, effectively crashing. I had the same problem with TigerVNC on Linux, since there seems to be a need for some sort of "polite" disconnection rather than just killing the socket.

Mind you, the VNC servers on Leopard and Snow Leopard are slightly different, not just in terms of bugs but also in terms of authentication and encodings supported.

[rcarmo]

Oh, and regarding the links to other clients above, and if I recall the spec correctly, you should assume 3.x as a version, not the whole thing. The way the protocol was done ages ago was that 3.1xx clients would all comply to the 3.1 base protocol, and the extra digits were basically to denote compatibility with extensions.

Sadly, loads of people never got that memo. If you patch a Linux VNC client to ignore the remaining digits, it works fine.

[kanaka]

@rcarmo, do you have any further info about how to do a polite shutdown? Also, it wasn't clear to me that the 3.889 was actually compatible with 3.8 (based on some of the bug reports it sounded like 3.889 messes with the security types) so I choose 3.3. That is the mostly likely version to work in a questionable situation as long as the server hasn't explicitly disabled 3.3 support.

[rcarmo]

Making sure you close the socket cleanly after processing as many remaining updates should be enough, as the protocol is stateless. That way the server receives a disconnection event and not an error (which is what I suspect is the matter with TigerVNC - that and shared session handling). I've come across clients that work fine (Vino, for instance) and others that simply vanish as far as the server is concerned...

[kanaka]

@rcarmo, can you try the following change and see if this makes the Apple VNC server happy?

diff --git a/websockify b/websockify
index 34acecd..4d30353 100755
--- a/websockify
+++ b/websockify
@@ -161,6 +161,7 @@ Traffic Legend:
            self.do_proxy(tsock)
        except:
            if tsock:
+                tsock.shutdown(socket.SHUT_RDWR)
                tsock.close()
                self.vmsg("%s:%s: Target closed" %(
                    self.target_host, self.target_port))

[kanaka]

Closing since no response in 9 months. Until somebody can confirm a safe disconnect, I'm not going to pull in the 003.889 version change. I've already applied the shutdown change to websockify since it's generic.

If somebody has an update on testing results please post back here and I'll re-open.

[opichals]

I have just tested the 003.889 patch and it seems to work ok. I can connect and disconnect repetitively. OS X 10.6.8 Snow Leopard.

Thank you!

[kanaka]

Pushed in: f84504b

[opichals]

Thanks again! I have done some looking around and found that valence code comments state that Apple real RFB version is 'something closer to 3.7':
https://github.com/simmons/valence/blob/master/src/com/cafbit/valence/rfb/RFBConnection.java

I guess we will need more investigation here to get the best out of it.

[kanaka]

If you test with 3.889 mapped to 3.7 and you can verify that it works properly than I'm willing to bump it up.

[opichals]

I have just tested it working with version 3.8. I.e. the following patch:

index 2677a37..677c09f 100644
--- a/include/rfb.js
+++ b/include/rfb.js
@@ -674,6 +674,7 @@ init_msg = function() {
             case "003.006": rfb_version = 3.3; break;  // UltraVNC
             case "003.007": rfb_version = 3.7; break;
             case "003.008": rfb_version = 3.8; break;
+            case "003.889": rfb_version = 3.8; break;  // Apple Remote Desktop
             case "004.000": rfb_version = 3.8; break;  // Intel AMT KVM
             default:
                 return fail("Invalid server version " + sversion);

Just to clarify.

To allow noVNC to connect to a OS X Screen Sharing (available since OS X 10.5), in System Preferences » Sharing, click button "Computer Settings" and enable "VNC viewers may control screen with password [..]".

Configuration screenshot can be seen here:
http://old.nabble.com/Status%3A-Security-type-requested-tt28220004.html#a28365742

[kanaka]

@opichals, can you make sure that the right behavior happens when you use the wrong password? You should get a failure message from the server in the status line (something other than "Authentication failed" which is the standard 3.7 message). That is the main difference between 3.7 and 3.8.

You don't happen to have a version of OS X Leopoard to test as well?