Alex, [snip]
> 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. No, I mean "the server, not the viewer". The other system (Linux/Windows) was to run VNC viewer, connecting to a server running on the Mac OS X system. > 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. Since the problem was with the server, the answer "try Chicken of the VNC" was not appropriate in this instance, and would serve only to confuse the original requester, hence my response. > 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. Nope, these messages indicate exactly that the server is not offering any authentication method that the viewer understands. In this particular instance, the cause of that is that Apple Remote Desktop is reporting a non-existent authentication type, because that's what it's been configured to do and your reconfiguration hasn't taken effect, but that's not what the messages tell you, that's one particular cause that you have encountered. [snip] > 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 the server reports that it supports RFB then it should support RFB. It is not "fair enough" for it to claim to support RFB but then to implement something else, since this leads to the compatibility problems that users are encountering. > >. 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. The server has sent a message number that the viewer doesn't understand, or more likely has sent malformed protocol data so that VNC Viewer is interpreting data as a message number that isn't actually a version number. This is definitely a problem with the server, caused by it not respecting the protocol version number scheme. > 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. You are wrong. The problem in this instance is that the server erroneously reports non-existent protocol version number 3.889, causing VNC viewer to (correctly, with respect to the protocol specification) select protocol version 3.8. ARD then appears to run a non-RFB protocol based on RFB 3.3, and so sends VNC viewer malformed protocol data wrt to RFB 3.8. [snip] > 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. Yes, that's correct, and that's exactly what the viewer does - it chooses the highest existing protocol version that the server claims it can support. In this case, the viewer chooses 3.8, because that's a lower version than the non-existent version 3.889. ARD then ignores the viewer's selection of protocol version, which is incorrect behaviour, and runs its own protocol, which appears to be based version 3.3 of the protocol. > 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. As I've explained above, you are wrong in this instance. > 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. If it supported protocol 3.8, it would work with viewers that request that version of the protocol, which it doesn't. > 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. Why? You appear to contradict this statement below. > 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. VNC Viewer Enterprise & Personal Editions include an automatic workaround for servers that report non-existent version numbers of this sort. > 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. VNC Server Enterprise Edition for Mac OS X is currently in beta-release, hence the trial license key available on-line, which is updated from time to time as the beta-release period continues. The full release, including 30-day trial, will be available shortly. Regards, Wez @ RealVNC Ltd. _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
