[Note: in Apple's terminology, the remote screen is the 'client' and the local viewer is the 'server'; similarly to how xclients are clients of the X-server. In this instance, it's confusing because we normally refer to the VNC viewer as the client and the VNC server as the server; I will stick to the usual VNC terminology rather than Apple's. There are some references to RDC - the client side component of Apple's which corresponds to a VNC server, and ARD which is actually the name of Apple's server side which corresponds to a VNC client; I believe instances of ARD should be ignored and considered to read RDC because in all cases we're referring to Apple's implementation being connected to by a VNC viewer, and never to ARD connecting to a conforming non-apple VNC server].
> However, James also tells someone that 'Chicken of the VNC' > > is irrelevant because it's a client and people are asking > > about the server. However, for whatever reason, more people > > report success connecting from various versions of Chicken > > to Apple's RDC implementation than any other setup. > > The post to which I was responding involved connecting using a viewer > running on Windows XP to a server running Mac OS X - someone suggested > trying Chicken on the Mac, having misunderstood that the Mac was to be the > server, not the viewer. I think you mean the "viewer, not the server". It's true that in the other thread the person wanted to connect from linux to RDC and the responder seemed to ignore this and recommended the mac os viewer. However, it's also true that the Mac OS viewer that was recommended does successfully connect to the Mac OS implementation; an important point since most people trying to solve this problem can't figure out which viewers work. > Now, for me the big stumbling block was errors like: > > > > ReadFromRFBServer: rdr::EndOfStream (vncviewer 3.3.7 on linux) > > > > or > > > > no matching security types (vncviewer 4.0b4 from fink) > > > > or > > > > unrecognized authType 30 (chicken on the mac) > > > > Now, all of these are because of a very un-mac-like > > behaviour: when you change the preferences of the Apple > > Remote Desktop, you have to stop and restart the server > > for the changes to take effect. So these messages are the > > result of connecting to RDC without VNC being properly > > enabled on the server side > > These error messages all indicate that the server to which you are > connecting is not offering any authentication methods which the viewer can > use. There is not, and never has been, a security type of 30, so the > server > is definitely at fault in this instance. What these messages actually indicate is that although the user has checked the VNC support checkbox, they haven't yet restarted the VNC server. So it is not yet offering any authentication mechanism that works with a VNC client, but rather some proprietary authentication option meant for Apple's Remote Desktop. It shouldn't offer an RFB number when configured in this way; this is clearly a bug in the server pretending it'll speak RFB when it won't. In this case, the server is providing a protocol which is not the same as that supported by the client; it's fair enough that these components don't work together. >. If you stop and restart the server, authentication does in fact > > proceed. Then you might get: > > > > main: unknown message type (vncviewer 4.0b4 from fink) > > This indicates that the server sent a message with a message-type code > that > does not exist in the negotiated version of the RFB protocol. This is a > fault in the server implementation. It can't clearly be said that this is a server side fault. Either side could be at fault; we will not know without looking at the data stream in order to determine which end is misinterpreting it. It seems most likely to me that this is a problem in Apple's server but the error message certainly provides no evidence as to which side is wrong. The information you provide below suggests that the client has violated the specification and chosen an RFB protocol version greater than that offered by the server, which would account for this error. > I didn't solve this one. Some hints indicated that you had to > > run chicken, or had to run tight vnc, or what have you. > > I found that vncviewer > > 3.3.7worked (slowly), and that TightVNC, UltraVNC, and RealVNC > > 4.1.2 from windows all worked, as well as osx2x to just > > control the mouse and keyboard of the Mac. > > This goes back to the issue of the protocol version number. Protocol > version numbers aren't just there as a curiosity. The server's protocol > version tells the viewer how to communicate with it, and vice versa. > Apple's Remote Desktop has a bug and reports a non-existent protocol > version > that causes modern viewers to assume that it implements the highest > existing > protocol version, which in fact it doesn't. I'm not sure if you're seeking to educate me on how to implement clients and servers or aiming at some other purpose here. Let me reassure you that I happen to understand how to engineer protocols and that I agree that it's fair to say that Apple publishing software which speaks an undocumented protocol version is not cool. However, you place the blame on the wrong piece of software here. The RFB specification is explicit: "Handshaking begins by the server sending the client a ProtocolVersion message. This lets the client know which is the highest RFB protocol version number supported by the server. The client then replies with a similar message giving the version number of the protocol which should actually be used (which may be different to that quoted by the server). A client should never request a protocol version higher than that offered by the server." This means that 003.889 is a number, and the client is NOT within its rights to choose "the highest existing protocol version". The client must choose a protocol version which is less than the given one, which is 003.008. The RFB spec goes on to say how only the authors of the protocol may ever change the numbers and so on; all good for control of the protocol and appropriate for its standardisation, but not relevant to the question of which software incorrectly implements the specification. In this case it is clearly the client at fault. since they use RFB 3.3, which is what ARD is based on. If what you're saying here is that RDC doesn't support RFB 3.8, then the server is also at fault in the protocol negotiation. I have no easy way to test this. UltraVNC isn't VNC-compatible, but I'm told it may work with ARD in some > instances. It worked in my test case but I didn't capture the packets to see why. All VNC 4 series viewers support the "Always use protocol 3.3" option, > specifically to allow them to connect to broken servers such as ARD, and > VNC > Enterprise and Personal Edition viewers will automatically degrade > gracefully to protocol 3.3 when they encounter servers that report bad > version numbers. If you are going to insist that the server is broken, you must update the specification not to have a constraint on what version the client may choose. I think the specification is presently quite clear and sensible and that in the absence of the user configuring some workaround the VNC 4 client should be transmitting RFB 3.8 back to RDC. Then if it doesn't work, RDC is at fault and a workaround must be enabled. Alternatively, Mac OS X users can disable ARD and install VNC Server for Mac > OS X, of which a beta-release is currently available from > http://www.realvnc.com/products/beta. The user who follows this advice presently has until Sept 8th to enjoy this decision. If you mean to allow a longer trial to users who download this based on your message today, you'll need to post a key with a longer expiry. For myself, I can't be bothered to download and install software that will expire in 48 hours. alex _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
