We have been testing MacX in a DECwindows, VMS/Multinet environment and were never able to get it to work successfully.
We have been working with TGV technical support to find out why MacX is unable to start up remote applications on VAX systems running MultiNet. We were able to get DECwindows applications to display on the MacX server using TCP/IP transport (no DECnet transport, since we don't have that connection tool on my Macintosh), only if we started the application manually on the VAX. We were unable to use the MacX "Remote" menu to start the applications from the Macintosh. The problem was traced to a problem in the rexec server on the VAX.
MultiNet is based on the UC Berkeley implementation of TCP/IP. This is a fairly robust implementation of TCP, since it has been around since about 1982 and has been tuned significantly over the years. However, the Berkeley people added the notion of "privileged ports" to their implementation of TCP.
A TCP port number is a 16-bit integer which identifies individual applications on the same host. In the UCB world, port numbers 1-1023 are considered "privileged," and only the superuser is allowed to access them. The UCB rshell and rlogin protocols use this concept to do remote authentication without sending passwords over the network. The basic idea is that if a request comes in from a privileged port on the remote host, then it must be the superuser making the request, so the server "trusts" the requester. The authentication procedure then proceeds without the use of passwords (I'll not bore you with the details). If the requester is not using a privileged port, then the request is denied (i.e. the server closes the connection). (Aside: if the host on which the requester resides does not have the concept of a privileged port, then it could conceivably allow anyone to open a port in the range 1-1023 and thus spoof the UCB rshell/rlogin servers. This makes the privileged port concept a bad idea.)
MacX does not use the rshell protocol; it uses the rexec protocol instead. Rexec does not use the privileged port authentication scheme, but instead relies on the username and password being sent over the network. The MultiNet rexec server erroneously checks to make sure that the requester is using a privileged port and closes the connection if it is not. This behavior is incorrect. Rexec does not use the privileged port number scheme, so it should not do this check. The rexec server distributed with UCB-based UNIX systems (like Ultrix and SunOS) is implemented properly, so it does not do the check. That is why MacX interoperates well with UNIX, but not with VMS/MultiNet. I do not know if other TCP/IP implementations for VMS have this problem or not. Oh yeah, since A/UX contains the UCB networking code, including the r-utilities, it works fine as well.
Please note that the problem is not in VMS DECwindows, nor is it in the interaction between DECwindows and the TCP/IP transport provided by MultiNet. We know this because we were able to start up DECwindows clients from the VAX and that worked properly. The problem is only with the MultiNet rexec server erroneously checking for a privileged port from the requester, and TGV has indicated to me that the problem will be fixed in MultiNet V2.2. This problem will not affect using MacX with the DECnet connection tool, since DECnet obviously doesn't use the rexec protocol. It will also not have any affect on other implementations of TCP/IP for VMS, unless they have the same problem.
Article Change History:
30 Jan 1995 - Reviewed for technical accuracy.
Support Information Services