Article 4588 of vmsnet.networks.tcp-ip.cmu-tek: Path: nntpd.lkg.dec.com!pa.dec.com!decwrl!genmagic!sgigate.sgi.com!swrinde!tank.news.pipex.net!pipex!news.mathworks.com!mvb.saic.com!cmu-openvms-ip From: System Manager Newsgroups: vmsnet.networks.tcp-ip.cmu-tek Subject: CMU Frequently Asked Questions List OCT 1995 Message-ID: <00997344.A198D26A.22@bay.cc.kcl.ac.uk> Date: Sun, 01 Oct 1995 05:10:04 +0000 (GMT) Organization: Cmu-Openvms-Ip<==>Vmsnet.Networks.Tcp-Ip.Cmu-Tek Gateway X-Gateway-Source-Info: Mailing List Lines: 3070 CMU OpenVMS TCP/IP Frequently Asked Questions Last Update: 12-SEP-1995 FAQ Maintainer: Andy Harper A.Harper @ kcl.ac.uk -------------------------------------------------------------------------------- This document is a set of Frequently Asked Questions (FAQ) About the CMU OpenVMS TCP/IP (hereinafter referred to as OpenCMU) package originally developed for VMS by Carnegie Mellon University and Tektronix. It is updated on an irregular basis, as new FAQs arise, and is posted on a monthly basis to the OpenCMU mailing list. The updated version may be obtained through anonymous FTP from `FTP.KCL.AC.UK' in directory [.CMU-TCPIP] as file CMU.FAQ. Each FAQ section begins with >>>> followed by the title of the section and the source of the answer, where known. Use of SEARCH on this document allows FAQ titles to be located. Please notify the maintainer of any omissions, out-of-date or incorrect information. -------------------------------------------------------------------------------- DISCLAIMER The Author of this FAQ is in no way connected with the development of the OpenCMU software and does not offer support on it. The information has been collected from various postings to newsgroups and from personal experiences of using the software. Any questions regarding the software should be posted to the appropriate mailing list or news group, or by contacting the authors directly. No responsibility can be taken for any problems arising from the use of any information in this FAQ. All information is provided on a best efforts basis and accuracy cannot be guaranteed. Except where otherwise acknowledged, the information in this FAQ is (C) Copyright Andy Harper, Kings College London, 1994,1995 While it may be freely distributed and used, it may not be sold or republished for profit without the permission of the author. -------------------------------------------------------------------------------- Changes Since SEP 1995 Edition. ------------------------------- 20-SEP-1995 Add disclaimer 13-SEP-1995 Correct command to add rights identifiers 12-SEP-1995 Clarify contents of DEVICE_INIT device dependent field 12-SEP-1995 Clarify interaction with DECnet Changes Since AUG 1995 Edition. ------------------------------- 24-AUG-1995 Note on upgrading to OpenVMS 6.2 22-AUG-1995 Change references to CMU into OpenCMU, where applicable 22-AUG-1995 Add details on OpenCMU port allocation bug. 17-AUG-1995 Even more information on working with OpenVMS 6.1 16-AUG-1995 Additional information on working with OpenVMS 6.1 15-AUG-1995 Modify intro in setting up IP over DECnet Changes Since JUL 1995 Edition. ------------------------------- 27-JUL-1995 More minor typos corrected. 24-JUL-1995 Added requirment for DECthreads to HTTP_SERVER application 24-JUL-1995 Added requirement for DECwindows/Motif to MOSAIC application 24-JUL-1995 Clarify status of dial-in and dial-out SLIP support 21-JUL-1995 Clarify LIBCMU status; development no longer continuing 21-JUL-1995 Change to section 4 title; clarify status of software 18-JUL-1995 Rewrite socket libraries introduction 18-JUL-1995 Different layout for software locations; use URLs everywhere 18-JUL-1995 Add brief description of products in 'known problems' section 18-JUL-1995 Update MAXBUF quota recommendation 17-JUL-1995 Updated DECwindows setup to include DECW$TRANSPORT_xxx logical 17-JUL-1995 More typos corrected 14-JUL-1995 New section on TCP tuning 14-JUL-1995 New section on OpenCMU security options 13-JUL-1995 Re-ordered the known problems section by facility 13-JUL-1995 New section on setting up gateway definitions 13-JUL-1995 New section on setting up X.25 links 13-JUL-1995 New section on setting up DECnet links 13-JUL-1995 New section on setting up SLIP links 13-JUL-1995 Update details on LYNX to cover SOCKETSHR compatible version 12-JUL-1995 Various small typos corrected 12-JUL-1995 More updates to the DEVICE_INIT description 12-JUL-1995 Updated OpenCMU introduction 12-JUL-1995 Add information on Hung NAMRES process and how to fix 10-JUL-1995 Add information on the DEVICE_INIT configuration record 10-JUL-1995 Updated details on new SOCKETSHR compatible MOSAIC 5-JUL-1995 Updated info on fixing BACKUP savesets corrupted by the transfer process. Changes Since APR 1995 Edition. ------------------------------- 28-APR-1995 Added details of RLOGIN software and Compressed Slip driver 28-APR-1995 Miscellaneous typos corrected 28-APR-1995 Added note about NFS support Changes Since MAR 1995 Edition. ------------------------------- 31-MAR-1995 Miscellaneous typos corrected 31-MAR-1995 Clean up section on obtaining software 31-MAR-1995 Update current versions section with OpenVMS 6.x kit availability 31-MAR-1995 Update C-kermit details for current release 30-MAR-1995 Add details giving availability of older openCMU versions 28-MAR-1995 Added section on posting questions to the newsgroup 20-MAR-1995 Improve documentation on IPACP BYTLM requirements 15-MAR-1995 Changed address of mailing list Changes Since JAN 1995 Edition. ------------------------------- 20-JAN-1995 Add note on FTP password hashing problem and new FTP_SERVER 20-JAN-1995 Add note on TELNET pause bug for OpenVMS 6.1 19-JAN-1995 Add details of VMS 6.x patch kits 9-JAN-1995 Correct spelling of listserver sitename Changes Since DEC 1994 Edition. ------------------------------- 19-DEC-1994 Add details of NETwork TIME set/display utility 19-DEC-1994 Add details of automated listserv subscription mechanism Changes Since OCT 1994 Edition. ------------------------------- 27-OCT-1994 Add details of the FSP client/server software 11-OCT-1994 Rewrite section on telnet hanging 11-OCT-1994 Rewrite OpenCMU prerequisites section 11-OCT-1994 Change layout on all sections 10-OCT-1994 All relevant references to CMU changed to OpenCMU ! 10-OCT-1994 Add note on OpenCMU under OpenVMS 6.1 10-OCT-1994 Reorganize software details by function; rewrite some entries 10-OCT-1994 Add details of SOCKIT - a general socket library for OpenVMS 3-OCT-1994 Add details of SOCKETSHR - socket interface to NETLIB Changes Since AUG 1994 Edition. ------------------------------- 10-AUG-1994 Add hint on location of NETERROR.OBJ file 3-AUG-1994 Fix minor typos 2-AUG-1994 MX now at revision 4.1; updated filenames aaccordingly Changes Since JUL 1994 Edition. ------------------------------- 1-AUG-1994 Add more info on SLIP connections 11-JUL-1994 Correct instructions for use under OpenVMS 6.x 5-JUL-1994 Corrected use of CONVERT/FDL to modify BACKUP saveset format Changes Since JUN 1994 Edition. ------------------------------- 4-JUL-1994 Updated locations for WWW HTTP server 15-JUN-1994 Making OpenCMU work with OpenVMS 6.0 15-JUN-1994 Add details of ARCHIE software for OpenCMU 15-JUN-1994 Add details of IPADDR software for OpenCMU 3-JUN-1994 Correct typo in MGFTP description 3-JUN-1994 MGFTP is freeware, not public domain Changes Since MAY 1994 Edition. ------------------------------- 24-MAY-1994 Add details of LYNX package 16-MAY-1994 Rewrite GOPHER details. 16-MAY-1994 Update details of FTP patch kit 16-MAY-1994 Update OpenCMU overview LPD/LPRSYMB description 16-MAY-1994 How to print OpenCMU IP Error message texts 16-MAY-1994 Info on IPACP BYTLM quotas 11-MAY-1994 Tidy up software availability tables 11-MAY-1994 Add details of MGFTP - MadGoat FTP - product 6-MAY-1994 Add details of MG_FINGER - MadGoat Finger - product Changes Since APRIL 1994 Edition. --------------------------------- 14-APR-1994 Update Anonymous FTP address of UK mirror site 12-APR-1994 Correct directory of spanish mirror site -------------------------------------------------------------------------------- C O N T E N T S 1.0 GENERAL INFORMATION . . . . . . . . . . . . . . . . 1.1 What is OpenCMU . . . . . . . . . . . . . . . . 1.2 Obtaining OpenCMU . . . . . . . . . . . . . . . 1.3 PreRequisites . . . . . . . . . . . . . . . . . 1.4 How does OpenCMU Affect DECnet . . . . . . . . 1.5 Current Versions . . . . . . . . . . . . . . . 1.6 The OpenCMU Mailing List/Newsgroup . . . . . . 1.7 Getting Technical Help from the Newsgroup . . . 2.0 COMMON SETUP AND CONFIGURATION INFORMATION . . . . 2.1 Setting up the Network Interface . . . . . . . 2.2 Notes on setting up a serial Line connection . 2.3 Notes on setting up a DECnet connection . . . . 2.4 Notes on setting up an X.25 connection . . . . 2.5 More on setting up SLIP . . . . . . . . . . . . 2.6 Setting up a gateway . . . . . . . . . . . . . 2.7 Setting Up DECwindows over OpenCMU IP . . . . . 2.8 Setting up an Anonymous FTP server . . . . . . 2.9 Setting up OpenCMU on OpenVMS 6.0 and 6.1 . . . 2.10 How to setup restrictions on network access . 2.11 Notes on TCP Tuning . . . . . . . . . . . . . 3.0 KNOWN PROBLEMS . . . . . . . . . . . . . . . . . . 3.1 IPACP . . . . . . . . . . . . . . . . . . . . . 3.1.1 IPACP Issues status codes to OPCOM . . . 3.1.2 IPACP crash due to quota exceeded . . . . 3.1.3 IPACP crashes with divide by zero error . 3.2 NAMRES . . . . . . . . . . . . . . . . . . . . 3.2.1 'Referral limit exceeded' . . . . . . . . 3.2.2 NAMRES hangs in RWAST . . . . . . . . . . 3.3 NFS . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Why doesn't the NFS server work . . . . . 3.4 FTP . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Why is FTP so slow . . . . . . . . . . . 3.4.2 Why does FTP crash with `exceeded quota'. 3.4.3 FTP of BACKUP savesets gives CRC errors . 3.4.4 Server login fails after 6.0 upgrade . . 3.5 TELNET . . . . . . . . . . . . . . . . . . . . 3.5.1 Why does TELNET sometimes hang in `RWAST' 3.5.2 Why does TELNETing into OpenCMU hang . . 3.6 MISCELLANEOUS . . . . . . . . . . . . . . . . . 3.6.1 Port number allocation bug . . . . . . . 4.0 FREE AND PUBLIC DOMAIN SOFTWARE SUPPORTING OPENCMU 4.1 TCP/IP Transport Interface Libraries . . . . . 4.1.1 NETLIB . . . . . . . . . . . . . . . . . 4.1.2 SOCKETSHR . . . . . . . . . . . . . . . . 4.1.3 LIBCMU . . . . . . . . . . . . . . . . . 4.1.4 SOCKIT . . . . . . . . . . . . . . . . . 4.2 Mail Applications . . . . . . . . . . . . . . . 4.2.1 MX . . . . . . . . . . . . . . . . . . . 4.2.2 POP3 Server . . . . . . . . . . . . . . . 4.3 News Applications . . . . . . . . . . . . . . . 4.3.1 ANU NEWS . . . . . . . . . . . . . . . . 4.3.2 NEWSRDR . . . . . . . . . . . . . . . . . 4.3.3 FNEWS . . . . . . . . . . . . . . . . . . 4.4 World Wide Web Applications . . . . . . . . . . 4.4.1 MOSAIC . . . . . . . . . . . . . . . . . 4.4.2 LYNX . . . . . . . . . . . . . . . . . . 4.4.3 HTTP_SERVER . . . . . . . . . . . . . . . 4.5 File Transfer Applications . . . . . . . . . . 4.5.1 MADGOAT FTP . . . . . . . . . . . . . . . 4.5.2 C-KERMIT . . . . . . . . . . . . . . . . 4.5.3 FSP . . . . . . . . . . . . . . . . . . . 4.6 Network Archive Search Applications . . . . . . 4.6.1 ARCHIE . . . . . . . . . . . . . . . . . 4.7 Gopher Applications . . . . . . . . . . . . . . 4.7.1 GOPHER . . . . . . . . . . . . . . . . . 4.8 Finger Applications . . . . . . . . . . . . . . 4.8.1 MADGOAT FINGER . . . . . . . . . . . . . 4.9 Domain Name Server Applications . . . . . . . . 4.9.1 NSQUERY . . . . . . . . . . . . . . . . . 4.9.2 IPADDR . . . . . . . . . . . . . . . . . 4.10 Miscelleneous Applications . . . . . . . . . 4.10.1 NETTIME . . . . . . . . . . . . . . . . 4.10.2 RLOGIN . . . . . . . . . . . . . . . . . 4.10.3 CSDRV . . . . . . . . . . . . . . . . . -------------------------------------------------------------------------------- 1.0 GENERAL INFORMATION --------------------------- 1.1 >>>> WHAT IS OPENCMU [12-JUL-1995] ------------------------ The OpenCMU software provides a full TCP/IP network transport for VAX systems running the VMS operating system. This allows a VMS system to participate in the world wide Internet network and take advantage of the wealth of information and software available on it. Support for various network interfaces is given in this table: +---------------------------------------------------------------------+ I Network Interface SUPPORTED ? I +---------------------------------------------------------------------+ I I I IP over Ethernet YES I I IP over Serial Line (SLIP) YES [1] I I IP over DECnet YES I I IP over Compressed SLIP YES, via 3rd party driver I I IP over X25 YES, via 3rd party driver I I I I IP over Serial Line (PPP) NO I I I +---------------------------------------------------------------------+ [1] SLIP is supported for statically connected links only; there is no dial-out support, and dial-in is supported only partially. Support for various standard TCP services is given in this table: +---------------------------------------------------------------------+ I Application Client Server I +---------------------------------------------------------------------+ I I I TELNET YES YES I I FTP [1] YES YES I I LPD YES YES I I FINGER YES YES I I TALK YES YES I I X windows YES YES I I MAIL [2] YES (3rd party s'ware) YES (3rd party s'ware) I I NFS [3] NO NO (broke with 6.6-5) I I RLOGIN [4] YES (3rd party s'ware) NO I I REXEC NO NO I I RSH NO NO I I XDM -- NO I I I +---------------------------------------------------------------------+ [1] Although FTP is included with OpenCMU, a much improved client and server is available as freeware - MadGoat FTP. See the applications section later. [2] MAIL is supported through the freeware MX package. See the applications section later. [3] An NFS server was supported up to Version 6.6-4. It broke with Version 6.6-5. [4] An RLOGIN client is available through a third party; see the applications section later. Also Available: o IPNCP for monitoring and controlling the TCP/IP system o UNIXSHR - A TCP/IP socket library Also Supported: o Domain Name Service is supported through the freeware DOMAIN package by Bruce Orchard. Usually available from the same sites as OpenCMU. Note: o Electronic mail support is also provided by the chargeable PMDF package available from Innosoft. Contact them for details. -------------------------------------------------------------------------------- 1.2 >>>> OBTAINING THE OPENCMU SOFTWARE [30-MAR-1995] --------------------------------------- The OpenCMU software is entirely free of charge and may be obtained through your local DECUS representative. The last relevant symposium tape that contains the OpenCMU software is the Fall 1992 tape, in directory [VAX92B.CMU] and on DECUS CDROM #12. A number of sites on the Internet maintain up to date anonymous FTP directories containing the OpenCMU software. These can be accessed using the FTP program or a mail server such as FTPMAIL that can transfer files from an anonymous FTP account back to the requestor via e-mail. The following URLs point to where the latest versions of software may be obtained: * Master Site: ftp://sacusr.mp.usbr.gov/cmuip/ (Henry Miller ) ftp://sacusr.mp.usbr.gov/tekip/ftp/ ( " ) ftp://sacusr.mp.usbr.gov/telnet/ ( " ) * Mirrors ftp://ftp.kcl.ac.uk/cmu-tcpip/ (Andy Harper ) ftp://ftp.csus.edu/pub/cmuip/ ( ?? ) ftp://dmc.com/vms/cmuip/ (Dick Munroe ) ftp://marduk.iib.uam.es/pub/VMS/cmutek-ip/ (J.R.Valverde ) There are versions of OpenCMU available that run on earlier versions of VMS available from a number of sources: DECUS Fall 92 tape, directory [VAX92B.CMU] DECUS CDROM VS0152, directory [LT92B.CMU] ftp://flash.acornsw.com, directory VS0152:[LT92B.CMU] ftp://ftp.kcl.ac.uk/cmu-tcpip/oldversion/ The first time you obtain OpenCMU, you will very likely not have an existing network facility and hence will be unable to obtain the software across the network. In this case, you should contact your local DECUS representative for a copy of the software on a suitable media. Subsequently, you can pick up new versions and patches using the network from many of the sites listed above. Announcements about these are made to the OpenCMU mailing list. -------------------------------------------------------------------------------- 1.3 >>>> PREREQUISITES [30-MAR-1995] ---------------------- Before installing OpenCMU on your system, take note of the following requirements. Hardware Requirements: A Digital VAX system. NOTE: Digital ALPHA systems are NOT currently supported. A Network interface. OpenCMU supports the following types of network interface: * Ethernet * Serial line (using SLIP) * X.25 Synchronous interface * DECnet link A network link to the outside world. The network interface must be connected to a network with at least one other network aware system connected to it. Consult your local site management or network service providers for details of how to connect to the rest of the IP world (the `Internet'). Each interface to the network MUST be allocated its own unique IP address (your service provider will supply this) and a subnet mask. Although optional, it is highly likely that access to an IP router and a Domain Name Server will be required. Ask your service provider for the IP addresses of each of these. Minimum VMS: The latest version of OpenCMU requires VMS 5.2 and upwards. -------------------------------------------------------------------------------- 1.4 >>>> HOW DOES OPENCMU AFFECT DECNET? [12-SEP-1995] ---------------------------------------- The short answer - it doesn't. OpenCMU and DECnet are completely independent. You can run either by itself or both together. The same applies to LAT, X25 over LLC2, PathWorks and all the other network protocols supported by OpenVMS. The only thing necessary is to start DECnet first if both are used. This is because DECnet needs to modify the ethernet address and hence be the only user of the network while it does that. -------------------------------------------------------------------------------- 1.5 >>>> CURRENT VERSIONS OF OPENCMU [31-MAR-1995] ------------------------------------ Base Version: OpenCMU 6.6-5 Kit: CMUIP066.% { % = A,B,C,D } Update Kits: OpenCMU 6.6-5A Kit: TEKIP0665A.SAVE Telnet 5.0-1 Kit: TELNETU1050.A FTP 2.12 Kit: FTPU0212.A VMS Version Specific Update Kits: Drivers for OpenVMS 6.x Kit: V6DRIVER.SAVE FTP_SERVER for VMS 6.x Kit: FTP_SERVER.SAVE IPACP for OpenVMS 6.1 Kit: IPACP.EXE Additional Kits: Compressed Slip driver CSDRV.BCK X25 driver X25DRV.BCK Domain name service kit DOMAIN-%.BCK (% = A,B,C) -------------------------------------------------------------------------------- 1.6 >>>> THE OPENCMU MAILING LIST/NEWSGROUP [11-OCT-1994] ------------------------------------------- An electronic mailing list and news group exists for exchanging information about the OpenCMU software. This is the preferred way to exchange information about problems, and their solutions, and to announce updates to the software. By subscribing, you gain access to a wealth of practical information from other users and the relevant OpenCMU experts. The address of the electronic mailing list, to which all enquiries or announcements are directed, is: CMU-OpenVMS-IP@sacto.mp.usbr.gov Subscribe by sending a message containing the single line `subscribe' to: CMU-OpenVMS-IP-Request@sacto.mp.usbr.gov For those with access to USENET, the world-wide electronic NEWS system, this mailing list is automatically gatewayed to the newsgroup: vmsnet.networks.tcp-ip.cmu-tek You are recommended to subscribe to the newsgroup wherever possible, in preference to the electronic mailing list. Details of some suitable news readers can be found elsewhere in this document. -------------------------------------------------------------------------------- 1.7 >>>> GETTING TECHNICAL HELP FROM THE NEWSGROUP [28-MAR-1995] -------------------------------------------------- Much of the information flow on the OpenCMU mailing list and newsgroup are questions such as `I can't make OpenCMU work...' or some derivative thereof. There are two fast ways you can get information that may help to solve your problem and it's worth trying these before trying the newsgroup: o Look in the manual. There is extensive info in the manual about most aspects of the OpenCMU package. o Look in the FAQ. Some things that aren't documented in the manual are in the FAQ. Your question may be a common one and, if so, the answer could well be there. It is also useful to: o Check the configuration. Most problems arise through a failure to correctly configure some aspect of the OpenCMU software; often because of a misunderstanding of the various items involved. o Check system/user quotas and system parameters. The software is sensitive to quotas and some system parameters. The manual and the FAQ both contain information on the key ones. Don't assume that the `out of the box' software' will run on your system without some tuning. If you have checked everything above, and still feel the need to get advice from other users, make sure that you give sufficient information to convey the problem to others by enclosing these details: A. A description of the problem; Be as specific as possible, since vague statements are not helpful. B. Details of your configuration. Here, it's probably best to enclose a copy of the various configuration files IN THEIR ENTIRETY (I.E. don't edit them to include only the relevant bits because you don't necessarily know what the relevant bits are yet). Files to include are: INTERNET.CONFIG NAMRES.CONFIG IP_STARTUP.COM C. A sample transcript of the session, if possible, which includes all the error messages. Enclose the whole transcript, not just the portion that shows the error. Something that happened earlier might just affect what you're doing. A transcript can be created in a number of ways, perhaps the easiest is to use the "SET HOST 0/LOG" command. This creates a new session (and you need to login again), recording everything that appears on your terminal in a file called "SETHOST.LOG". This logfile is closed once you logoff the new session. With thanks to: Harry Meier -------------------------------------------------------------------------------- 2.0 COMMON SETUP AND CONFIGURATION INFORMATION -------------------------------------------------- 2.1 >>>> SETTING UP THE NETWORK INTERFACE [12-JUL-1994] ------------------------------------------ The INET$CONFIG file contains a single 'Device_Init' line for each network interface to be used for OpenCMU IP. The general format is this: DEVICE_INIT:driver:devicename:device-specific-info:IP-address:net-mask Where: DEVICE_INIT Is the required keyword driver is the name of the interface driver to be used. devicename is the VMS devicename of the interface, or DECnet node device-specific-info is device dependent IP-address is the IP address (a.b.c.d) of this interface net-mask is the subnet mask of the network behind the interface Examples: [Unless otherwise stated, all example sitenames and IP addresses are ficticious] Ethernet: DEVICE_INIT:ETHER:ESA0:00-00-00-00-00-00:128.2.232.69:255.255.0.0 * Defines an interface that connects to the ethernet via device ESA0. Serial Line: DEVICE_INIT:SLDRV:TXB3:REMHOST.CC.CMU.EDU:128.2.232.69:255.255.255.252 * Defines an interface that connects over the TXB3 serial line to a remote host using the SLIP protocol. IP over DECnet: DEVICE_INIT:DNDRV:KETTLE:IP_DECNET:128.2.232.69:255.255.255.252 * Defines an interface that connects via DECnet to the remote node KETTLE. IP over X25: DEVICE_INIT:X25DRV:NWA0:T300;S45050180021;L4505018004-0:128.2.232.69:255.255.255.252 * Defines an interface that connects via X25 to the remote node on X.25 address 45050180021. Notes: [1] The OpenCMU manual refers to an XEDRV ethernet driver. This should NOT be used. The name ETHER is a special internal driver that is faster and more bug-free. [2] All drivers should be in the CMUIP_ROOT:[SYSLIB] directory. Currently, these are: SLDRV - The Serial Line, or SLIP, driver DNDRV - The DECnet driver X25DRV - The IP-over-X25 driver (third party) CSDRV - The Compressed-SLIP driver (Third party) [3] If multiple interfaces are configured, then you should also set: VARIABLE:IP_FORWARDING:1 in the INET$CONFIG file if you want packets routed between them. [4] OpenCMU does not support any of the standard routing information protocols, such as RIP. Thus, all gateways must be explicitly specified. If multiple interfaces are configured on the OpenCMU host with IP_FORWARDING set, then all other hosts on the local subnet(s) must specify the OpenCMU host as the gateway for all the other subnets to which it connects. [5] The device dependent field is ignored for the ethernet driver. [A.Harper@kcl.ac.uk] -------------------------------------------------------------------------------- 2.2 >>>> NOTES ON SETTING UP A SERIAL LINE (SLIP) CONNECTION [13-JUL-1995] ------------------------------------------------------------ The SLDRV driver implements SLIP over a statically connected serial line; it does not handle dial-in or dial-out connections, although such connections can be established manually. Basic Setup: * Define the DEVICE_INIT record, similar to this: DEVICE_INIT:SLDRV:TXB3:NONE:128.2.232.69:255.255.255.252 Note that the subnet mask MUST allow for at least 4 distinct addresses, the IP address of the interface itself, the IP address of the remote end of the link, and the reserved network and broadcast addresses at the low and high end of the range. * Set the Terminal device characteristics to allow 8-bit transparency: $ SET TERMINAL term /PERM /SPEED=nnn /EIGHTBIT /NOTTSYNC /NOHOSTSYNC - /ALTYPAHD /NOECHO /NOBROADCAST /NOLINE /NOWRAP - /LOWERCASE This command should be placed in the system startup file BEFORE the IP software is started. * The system at the remote end of the link should be configured with similar serial port characteristics. In particular, ensure that the speeds match and that flow control (XON/XOFF) is disabled. The SLIP protocol handles flow control itself. * The precise cabling requirements between the two ends of the link are dependent on the equipment used. * If the local OpenCMU host is acting as an IP router, so that data from the serial line can be passed to another interface, then an additional line should be added to the INET$CONFIG file: VARIABLE:IP_FORWARDING:1 Using LAT Terminals: If the remote system connects via a serial line into a DECserver port, then there are some additional steps: * On the DECserver, set the port characteristics to allow 8-bit transparency and disable flow control etc. Issue these commands as a privileged user from another port: Local> CHANGE PORT port AUTOPROMPT DISABLED Local> CHANGE PORT port SPEED xxx ! Set the comms speed Local> CHANGE PORT port BROADCAST DISABLED Local> CHANGE PORT port INPUT FLOW DISABLED Local> CHANGE PORT port OUTPUT FLOW DISABLED Local> CHANGE PORT port LOSS NOTIFICATION DISABLED Local> CHANGE PORT port VERIFICATION DISABLED NOTE that some DECservers may not support all of these commands. Other characteristics may need modification if their default values are not suitable. The above is suitable for a DECserver 700, provided that other port characteristics have not been changed away from their default values. * On the OpenCMU host, use the LAT control program to create the LTAnnn terminal device and map it to the appropriate port on the DECserver: $ MC LATCP CREATE PORT LTAnnnn /DEDICATED ! This becomes the 'hardwired' line SET PORT LTAnnnn /SERVER=server /PORT=port 'nnnn' is an arbitrary unused LAT terminal number, 'server' is the name of the DECserver, 'port' is the name of the port used on the DECserver for the SLIP link. Use the terminal name 'LTAnnnn' in the DEVICE_CONFIG record. These commands should be placed in the system startup procedure BEFORE the IP startup and BEFORE the SET TERMINAL command used to set the device characteristics. Further Notes: Each SLIP line should be allocated it's own unique subnet; that is, one where the range of addresses does not overlap that possible on another subnet. The device-dependent field of the DEVICE_INIT record is ignored. Consider updating relevant SYSGEN parameters. TTY_ALTYPSIZ can be increased to allow for large packets. Around 2000 is a recommended value. Although OpenCMU has no facility to automatically dial-out over a modem to establish a connection, it is possible for the connection to be manually established before the SLIP port is used. Dial-in, via a modem, to a SLIP port is possible except that the OpenCMU software will not notice if the connection is dropped (having no facility for monitoring the line status). If this is required, information about it can be found in the article entitled "MORE ON SETTING UP SLIP" later in this document. Some DECservers can support SLIP directly (that is, action the SLIP protocol on the port directly and route it onwards using 'real' TCP/IP over ethernet). If so, it is considerably more convenient to configure the DECserver to deal with it itself and not bother with SLIP support on the OpenCMU host. -------------------------------------------------------------------------------- 2.3 >>>> NOTES ON SETTING UP AN IP OVER DECNET CONNECTION [15-AUG-1995] --------------------------------------------------------- The DNDRV driver allows the TCP/IP protocol to be used over an existing DECnet link to a remote node. In this instance, DECnet is used merely as a low level carrier of the data. Basic Setup: * Define the DEVICE_INIT record, similar to this: DEVICE_INIT:DNDRV:KETTLE:IP_DECNET:128.2.232.69:255.255.255.252 Note that the subnet mask MUST allow for at least 4 distinct addresses, the IP address of the interface itself, the IP address of the remote end of the link, and the reserved network and broadcast addresses at the low and high end of the range. The device name portion of the record is the name of the remote DECnet node with whom the link is formed. General Notes: The remote node must define a DEVICE_INIT record in similar fashion, but giving its own IP address and the DECnet name of this node. The documentation does not say anything about what DECnet objects are defined, or whether the name IP_DECNET in the device dependent information field of the DEVICE_INIT record is meaningful. Therefore, it is difficult to say whether this will work in conjunction with a DECnet node that runs a transport other than OpenCMU IP. However, it is known to work when the remote node is running MULTINET TCP/IP, as follows: * In the DEVICE_INIT record, the device-specific-info field must be set to the local DECnet nodename prefixed by "IP_". * Multinet's 'gated' has to be configured to achieve the desired announcement and routing. With thanks to: -------------------------------------------------------------------------------- 2.4 >>>> NOTES ON SETTING UP AN X25 CONNECTION [13-JUL-1995] ----------------------------------------------- The X25DRV driver, which is third party software, allows an IP connection to be set up over an X25 circuit. This requires the VAX PSI or DECnet/OSI products to be installed and running. Basic Setup: * Define the DEVICE_INIT record, similar to this: DEVICE_INIT:X25DRV:NWA0:T300;S45050180021;L4505018004-0:128.2.232.69:255.255.255.252 Note that the subnet mask MUST allow for at least 4 distinct addresses, the IP address of the interface itself, the IP address of the remote end of the link, and the reserved network and broadcast addresses at the low and high end of the range. * The device dependent information part defines the DTE addresses to be used, as a set of ; separated values, as follows: Tnnn Time in seconds after which the connection is dropped if there is no activity. S[R]ssssssssssss[-ss] DTE address [and optional subaddress] of the remote node to which the connection is to be established. Connections initiated from this end will place an outgoing X25 call specifiying this DTE address [and subaddress]. Specifying the optional [R] will place the call with reverse charging. R[R]rrrrrrrrrrrr[-rr] DTE address [and optional subaddress] of the remote site allowed to call us. Calls from other addresses will be refused. If omitted, the DTE address specified by the S parameter is used. Specifying the optional [R] will allow us to accept incoming reverse charge calls. Llllllllllll[-ll] DTE address [and optional subaddress] of this node. This is placed into the outgoing call and may be required if the network does not insert it automatically. General Notes: The X25DRV driver is third party software, and not part of the standard OpenCMU distribution. It is however freely available. -------------------------------------------------------------------------------- 2.5 >>>> MORE ON SETTING UP SLIP [11-OCT-1994] -------------------------------- The information below has been culled mostly from personal experience (i.e., it works for me). All IP addresses have been changed. The reason for this is that OpenCMU SLIP doesn't require a password -- if you know the IP address of the SLIP interface, and the phone number to dial, you can get in. Also, any explanations given below are not necessarily completely correct; I've tried to put everything in simple terms that I understand. Those caveats given, here goes... First, in INET$CONFIG, you need to have *two* separate interfaces: one that talks to the SLIP "network", and one that talks to the Ethernet "network". These two interfaces each have their own addresses. If they "overlap" (this will be defined later), the interface to the more general network must come *last*. Example: in my configuration (remember: *all* ip addresses have been changed; OpenCMU SLIP doesn't bother to ask for a password for connection purposes, so anyone who knows the phone number of your modem and the IP address of your SLIP interface can connect through your system), I have a VAX with an Ethernet interface at IP address 128.97.101.101. We use subnetting here at UCLA, and our network mask is 255.255.255.0. This means that my VAX can directly connect to any computer whose address is 128.97.101.x, where x is in the range 0-255 (although I believe the first and last are off limits). To get to any computer with an address not in this range, I need to go through a gateway. In my case, the gateway is at 128.97.101.105. Note that I can directly connect to this computer. This is, of course, important. So, I need a line in INET$CONFIG that says something like Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0 and further down, one that reads Gateway:GATEWAY.PHYSICS.UCLA.EDU:128.97.101.105:0.0.0.0:0.0.0.0: Now, I want to start a SLIP interface with a modem attached to the device TTA2. I am assigned the address range 128.97.101.120 through 128.97.101.127. This is a total of eight addresses, but again, the first and last are not usable for reasons I don't understand (I think the operative terms are "network address" for the .0 one and "broadcast address" for the .127 one). At this point, the six remaining addresses belong to *me*, and are mine to assign as I wish. I choose to assign the first one to the SLIP interface itself: slip.physics.ucla.edu = 128.97.101.121 I have a computer at home (say it's a PC). I choose to assign this the next address: mypc.physics.ucla.edu = 128.97.101.122 These names must be established with the network administrator, but I am free to dole out the addresses to whomever I choose. Note that by the rules above, the ethernet connection can speak directly to mypc. This is incorrect, since that must go through the SLIP interface. This is what I have called overlap above. The range of SLIP addresses (.120 - .127) lies within that of Ethernet addresses (.0-.255). We therefore need a way to tell OpenCMU to use the SLIP interface for the addresses .120-.127, and the Ethernet interface for all the others. We do this simply by placing the SLIP device definition first, so that the Device_Init lines now look like: Device_Init:SLDRV:TTA2:slip.physics.ucla.edu:128.97.101.121:255.255.255.248 Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0 The only new thing here is the mask on the SLIP interface. That mask has all bits set to 1 except the last three. This means that there are eight addresses (2^3) that the SLIP interface can access, which work out to .120-.127. If OpenCMU wants to connect to one of these addresses, it does it through the SLIP interface. If it wants to talk to anything else with an address of 128.97.101.x, it does it through the Ethernet interface. Any other address is contacted via the gateway (which itself is contacted via the Ethernet interface). The only other thing to do is to set the IP_Forwarding flag. This allows OpenCMUI to transmit packets from one interface to the other. without this, you couldn't use SLIP to get to the outside world: Variable:IP_Forwarding:1 That should be it. Restart OpenCMU, and all should be well. One other thing: many SLIP packages on the PC/Mac side expect to give the system some kind of password upon connection, and will fail if they don't receive a response from the VAX. This needs to be turned off, since the VAX won't do a thing other than just sit there. -------------------------------------------------------------------------------- 2.6 >>>> SETTING UP A GATEWAY [13-JUL-1995] ----------------------------- Packets originating from the local node can only be sent DIRECTLY to a host on the same subnet. Packets addressed to a host on a different subnet must be directed at a gateway or router. A host is on the same subnet as the local system if the following holds true: ( Local-IP-Address .AND. net-mask ) = ( Remote-IP-Address .AND. net-mask ) where '.AND.' represents a bitwise logical AND of the two values. Gateway Record: The GATEWAY record of the INET$CONFIG file defines the address of a router connecting the current subnetwork to another. It has this general form: GATEWAY:gateway-name:gateway-address:gateway-net:mask where: gateway-name is the name of the gateway gateway-address is the IP address of the gateway gateway-net is the network on the other side of the gateway mask is a subnet mask that determines which subset of the 'gateway-net' address can be reached through the gateway. Note that 'mask' is NOT the same as the local subnet mask. Examples: GATEWAY:router1.mysite.edu:123.45.3.30:145.23.0.0:255.255.0.0 Says that addresses 145.23.0.0 thru 145.23.255.255 are accessible via the gateway on address 124.45.3.30. GATEWAY:router2.mysite.edu:124.45.3.31:140.0.0.0:255.0.0.0 Says that addresses 140.0.0.0 thru 140.255.255.255 are accessible via the gateway on address 124.45.3.31. GATEWAY:world.mysite.edu:124.45.3.40:0.0.0.0:0.0.0.0 Says that all (non-local) addresses are accessible through the gateway on address 124.45.3.40 (Apply the algorithm below to see why this is so). In effect, this is a 'default' router to the rest of the networking world. Selecting the Gateway: If the address is non-local (I.E. does not match the subnet mask), a gateway will be selected by testing each gateway record in turn, in order of definition in the configuration file. The first one found that matches will be used. The following algorithm is used to determine whether a particular address is reachable through a gateway: ( remote-address .AND. mask ) = ( gateway-net .AND. mask ) In other words, if the network portion of the address ('remote-address'.AND. 'mask') matches the network portion of the far network ('gateway-net'.AND. mask), packets will be sent to the 'gateway-address'. TIP: Think of the 0 in the mask as a 'wildcard' allowing all values in the range at that point. General Notes: Each gateway MUST be directly reachable. That is, it MUST be on the same subnet as the local host. The 'default' router, if one exists, should be defined as the last gateway in the configuration file. If a site has multiple gateways out to a particular subnet, to provide failover in case of problems, OpenCMU will never use the second and subsequent ones even if the first fails to respond. This is a design limitation. -------------------------------------------------------------------------------- 2.7 >>>> SETTING UP DEC WINDOWS OVER OPENCMU [11-OCT-1994] -------------------------------------------- NOTE: This summary applies to the LATEST version of OpenCMU. There may be minor differences applying it to earlier versions. +===========================================================================+ | Example of the installation of dec$transport_cmu of OpenCMU V6.6-5A | +===========================================================================+ 1. Copy DECW$TRANSPORT_CMU.exe to sys$common:[syslib]decw$transport_cmu.exe ( Note: Although the change of $ to _ is required (see 5.3 upgrade and installation procedures section 10.4, p.10-)7, I didn't do so. But it works) 2. Set protections on the file as -- S:rwed,O:rwed,g:rwed,w:re 3. Add the following record in IP_STARTUP.COM if it is not already there: $ install create sys$share:decw$transport_cmu.exe /open/share/header/prot 4. Customize decw$private_server_setup.com to have the following line: $ decw$server_transports == "DECNET,LOCAL,LAT,CMU" Eg. Copy decw$private_server_setup.template to *.com in Sys$common:[sysmgr] directory and add one record as follows; $do_default: >>> $ decw$server_transports == "DECNET,LOCAL,LAT,CMU" $ exit 5. Reboot workstation. If IP is already setup and running, it should be sufficient to merely restart DECwindows via the following command: $ @sys$manager:decw$startup restart 6. Security Entry on VAX/VMS+CMU If you are using VAX/Station(VMS+CMU) and you want to create a window on the VAX/Station (i.e. you want to use it as a "server"), it is required to customize security by adding as "authorized user" the OpenCMU transport for the users and machines desired. (Select security in the setup menubar of VAX/Station and add following entry NODE: IP-address or domain-name (Eg. 134.160.1.1) USER nam ? or * (Eg. *) Transport: CMU (Eg. CMU) If you want use your VAX only as a client or your VAX is not workstation, it is not necessary to define the security entry. 6.1 Security entry on UNIX workstation (eg. SUN + X11 Release 4) If you want to communicate with a UNIX workstation running X11R4, it is also required to define the security entry of the hostname on the UNIX. There are two ways to define the security entry (1) Write hostname in /etc/X*.hosts file. (* is display number) (2) Define hostname by "xhost" command. (this works only in the local terminal. This does not work on the telneted terminal) You can get more information by "man X" and "man xhost" command in UNIX. X11 Release 4 entire kit and its patch are available for anonymous ftp from expo.lcs.mit.edu in pub/R4 directory 7. Then you can create a X-window from UNIX or on UNIX Eg. 1 (create a X-terminal on VAX/Station from SUN [SUN OS 4.0.3+X11R4] ) (% xhost hostname (authorize hostname, see 6.1)) % setenv DISPLAY hostname:0 (define display) % xterm & (Create a X-terminal of sun on VAX/VMS) Eg. 2 (create a DEC-terminal on SUN from VAX/Station) $ set disp/cre/node="hostname"/tran=CMU $ cre/term/det Checking the X server is running: (This applies only where the VAX is being used as an X-server. For example, a VAXstation). After you bring up the transport with DECWindows, do a NETSTAT to see if the transport was initialized to wait for incoming connections. You should see a TCP port at port 6000 in the LISTEN state. If not, you've done something wrong. Example $ IPNCP IPNCP> netstat 1 TCP connection found IDX Address Local Host Port Foreign Host Port State 2 0004C188 0.0.0.0 23.112 0.0.0.0 0.0 LISTEN 0 UDP connections found Standardising The SET DISPLAY Command: Because there are many different TCP/IP transports available for OpenVMS, of which OpenCMU is just one (Multinet, UCX, Wollongong etc. ), there are a number of different possibilities for the SET DISPLAY command, since it requires that the transport be explicitly specified. For UCX, you would require: $ SET DISPLAY /TRANSPORT=TCPIP Whereas OpenCMU would require: $ SET DISPLAY /TRANSPORT=CMU Thus, writing portable command procedures which set the display is made more complex than necessary due to having to determine which of the underlying transports is being used before issuing the SET DISPLAY command. This can be circumvented very simply, by using a logical name to map a standard transport name into the underlying transport compatible one: $ DEFINE /SYSTEM /EXEC DECW$TRANSPORT_TCPIP DECW$TRANSPORT_CMU This allows the user to issue SET DISPLAY /TRANSPORT=TCPIP and have it mapped to the OpenCMU transport. Defining this logical appropriately at system startup means that procedures only ever need to know the standard transport name of 'TCPIP'. Adding the above line to the IP_STARTUP file is recommended. -------------------------------------------------------------------------------- 2.8 >>>> HOW TO SET UP ANONYMOUS FTP [11-OCT-1994] ------------------------------------ Note: following information taken from the FTP client release notes, with minor editing to add additional info. 2.4.1 RPI Modifications 2.4.1.1 V2.7-5, 20-JUN-1989, Madison > All FTP_ANON logical names should now be placed in the logical name table FTP_NAME_TABLE, to get them out of the system name table. To do this, add the following lines to your IP_STARTUP.COM: $ CREATE/NAME_TABLE/EXEC/PROT=(S:RWED,O:RWED,G:R,W:R)- /PARENT=LNM$SYSTEM_DIRECTORY FTP_NAME_TABLE $ FTPDEF := DEFINE/TABLE=FTP_NAME_TABLE/EXEC/NOLOG then use FTPDEF to define the FTP_ANON... logical names, for example: $ FTPDEF FTP_ANONYMOUS_DIRS USER$:[ANONYMOUS...] $ FTPDEF FTP_ANON_LOAD_THRESHOLD "0.5" $ FTPDEF FTP_ANON_PRIME_DAYS "2,3,4" ! Tuesday, Wednesday, Thursday > Added system load checking on anonymous logins if LAV0 device is available. To enable, define the following logical names in FTP_NAME_TABLE: FTP_ANON_LOAD_THRESHOLD some floating-point number between 0.0 and 1.0. FTP_ANON_PRIME_DAYS day-numbers -- indicate "prime time" days FTP_ANON_PRIMETIME_START time-of-day -- indicates start of "prime time" FTP_ANON_PRIMETIME_END time-of-day -- indicates end of "prime time" FTP_ANON_TIME_ZONE any character string indicating local time zone The only required logical is FTP_ANON_LOAD_THRESHOLD. If that logical name exists and the LAV0 device exists, the load checking code is used. The code does the following: If FTP_ANON_PRIME_DAYS is defined, it is translated. The comma-separated list of numbers (where 1=Monday, 2=Tuesday, etc.) is used to identify the days in which "prime time" is effective. If it does not exist, "prime time" is assumed to be in effect Monday through Friday. Note: Use ONLY numbers 1 through 7, and NO SPACES in the string. Surround the string with quotation marks when defining! If FTP_ANON_PRIMETIME_START is defined, it is translated and converted into a system date-time value using LIB$CONVERT_DATE_STRING. If not, then 09:00 is used as the start of "prime time". If FTP_ANON_PRIMETIME_END is defined, it is translated and converted into a system date-time value using LIB$CONVERT_DATE_STRING. If not, then 17:00 is used as the end of "prime time". If the current time is between the prime-time start and end times, then the current load averages are read from the LAV device. The current load is computed using the following formula: load = M15 * (P15 / 4.0) where M15 is the average load over the last 15 minutes, and P15 is the average priority over the last 15 minutes. Thus, the average load is normalized against typical interactive priority to guard against low-priority batch jobs preventing guest login access. If the load is greater than or equal to the LOAD_THRESHOLD value, then the guest login is denied with a reason of "system too busy". If the threshold is not exceeded, then the guest login is accepted, but the user is warned to minimize access during prime time (with the start and end times displayed along with the time zone information [if FTP_ANON_TIME_ZONE is defined]). If the current time does not fall within prime time, no load checking is performed. 2.4.1.2 V2.7-4, 09-JUN-1989, Madison > Added special messages to FTP server during guest (anonymous) login. Modified the logging of anonymous sessions slightly. 2.4.1.3 V2.7-2, 03-APR-1989, Madison > The FTP server presents a somewhat more informative banner on connection-- includes system name and version of FTP. > The code that handled directory changes was really ugly, even though it had been modified to fix the infinite-loop problem from V2.6. I replaced the code with some which makes use of available VMS system services, simply to satisfy my own sense of aesthetics. > Enhanced the Anonymous FTP support provided by OpenCMU. The enhancements include: * ANONYMOUS is never allowed privileges regardless of the contents of its UAF record. * All ANONYMOUS FTP sessions create logs. Each session creates a file SYS$MANAGER:ANON_FTP_LOG.LOG. You can put them elsewhere by defining ANON_FTP_LOG system-wide to a different location. The password given to ANONYMOUS is logged along with the remote host's name and address, as well as RETR, LIST, NLST, CWD, and CDUP commands. The log files need not be accessible to the ANONYMOUS userid (and probably should not be). NOTE: It appears that the anonymous log file is ONLY created in SYS$MANAGER if the ANON_FTP_LOG logical name is explicitly defined. By default, no log file gets created. Use: $ define/system ANON_FTP_LOG sys$manager:ANON_FTP_LOG.LOG * You can restrict the directories to which ANONYMOUS has access by defining the system-wide logical name FTP_ANONYMOUS_DIRS to a search list of device/directory specifications. Any RETR, LIST, or NLST will check against this list before going through normal system access checks. This prevents ANONYMOUS from gaining access to people's files via WORLD access. If you do not define FTP_ANONYMOUS_DIRS, the extra access checks do not take place. You can use [directory...] notation to allow access to the entire subdirectory tree below the specified directory. The steps needed to set up a controlled Anonymous FTP are: 1. Create a UAF record for ANONYMOUS. Set it /NOINTER/NOBATCH/NONETWORK to prevent logins or DECnet use. Set /FLAG=DISMAIL to prevent mail from reaching it. Assign it a UIC that is unique and outside any existing group. Give it a default device and directory. Example: UAF> ADD ANONYMOUS/PASS=JUNK/NOINTERACTIVE/NOBATCH/NONETWORK- /FLAG=DISMAIL/UIC=[666,666]/DEV=USER$DISK/DIR=[PUBLIC] 2. Put the definition of FTP_ANONYMOUS_DIRS in your system startup sequence. Make sure it is defined before allowing Anonymous access. Make sure that the default device/directory in the UAF is accessible (not strictly necessary, but easier on the users). Example: $ DEFINE/SYSTEM FTP_ANONYMOUS_DIRS - USER$DISK:[PUBLIC...],- ! public files USER$DISK:[NEWS...],- ! news archives USER$DISK:[MAIL] ! mail archives 3. Create the directories to which ANONYMOUS will have access. Do not permit ANONYMOUS to own any of the files or be in the same group as the owner of the files. Set WORLD:R protection on all files and directories to be accessible, or use an ACL to grant access specifically to ANONYMOUS. While these modifications were meant to enhance the security of Anonymous FTP, neither the author nor his employer (nor anyone else for that matter) guarantees that the software is secure. Availability: ftp://ftp.kcl.ac.uk/default/lavdriver.* -------------------------------------------------------------------------------- 2.9 >>>> SETTING UP OPENCMU WITH OPENVMS 6.x [24-AUG-1995] -------------------------------------------- If OpenCMU is already installed and you are upgrading from OpenVMS 5.x to OpenVMS 6.x, or OpenCMU is being installed for the first time onto an OpenVMS 6.x system, then some special steps need to be taken after the installation of the base OpenCMU kit in order that it will run correctly: OpenCMU works with OpenVMS 6.0, 6.1 and 6.2. * Register OpenCMU images: OpenVMS 6.1 allows pre-version 6 drivers to run if the new image registration utility is used on them. Failure to register will result in the network failing to start with messages like 'System version level mismatch'. The following commands may be used: $ register == "@sys$update:register_privileged_image register" $ register cmuip_root:[sys$ldr]ipdriver.exe $ register cmuip_root:[sysexe]ipacp.exe $ register cmuip_root:[sysexe]lpd.exe * Install OpenVMS 6.x patch kit: Under OpenVMS 6.x, a new password hashing scheme was introduced. The FTP_SERVER image does not understand the new method so that users who change their password under OpenVMS 6.x cannot subsequently login to the FTP server. The FTP_SERVER replacement fixes this. Some Version 6 specific drivers are also available: FTP_SERVER.SAVE OpenVMS 6 version, with fixed password hashing V6DRIVER.SAVE OpenVMS 6 versions of IPDRIVER, PNDRIVER, TZDRIVER * Install OpenVMS 6.1 patch kit: IPACP.EXE New version (6.7) linked against OpenVMS 6.1 This version appears to be troublesome on some systems. If it causes problems then fall back to the version supplied in the TEKIP0665.A patch kit. Do not install this if running OpenVMS 6.0; it is for OpenVMS 6.1 and above only. * Reboot system: Once all appropriate patches have been applied, the system MUST be rebooted in order that the new drivers can be loaded. Failure to do this will result in the old drivers remaining loaded and the patches not taking effect. These patch kits are available via ftp from the sources named elsewhere in this document. -------------------------------------------------------------------------------- 2.10 >>>> HOW TO SET UP RESTRICTIONS ON NETWORK ACCESS [14-JUL-1995] ----------------------------------------------------- Security Options The OpenCMU software provides a number of mechanisms for restricting access to the network from the local host. These restrictions apply to ANY type of outgoing connection: * NETMBX privilege for access to the network * PHY_IO privilege [optionally] required to open local well known ports * INTERNET_ACCESS identifier [optionally] required to connect to any network host * ARPANET_ACCESS identifier [optionally] required to connect to any non-local network host. Which hosts are considered 'local' can be separately defined. NETMBX Privilege Being a network product, naturally OpenCMU requires that users have the NETMBX privilege to use it. This is normally granted to users as it is typically not dangerous (some sites may disagree though). Alternatively, it is possible to INSTALL selected applications with NETMBX privilege and allow all users to run selected applications. Configuration of Optional Security Mechanisms The INET$CONFIG file defines further access restrictions that can be used. Of these the first, and most important, is the ACCESS_FLAGS variable, defined thus: VARIABLE:ACCESS_FLAGS:nnnn where 'nnn' is a bitmask expressed as an integer value. Different security measures are assigned to each bit. To determine the value, add together the appropriate numbers from this list: 1 If you require users to have PHY_IO privilege to open local well known ports. This option prevents non privileged users from setting up listeners on standard ports, such as FTP, TELNET or SMTP, and subverting such services. 2 If you require users to possess the identifier ARPANET_ACCESS to talk to non-local hosts (see the LOCAL_HOST definition below). May be useful if you are charged for off-site access 4 If you require users to possess the identifier INTERNET_ACCESS to talk to any host on the network. Examples: VARIABLE:ACCESS_FLAGS:1 Require PHY_IO privilege for well known ports; no other restrictions placed on where users can connect. This is the usual value for a site placing no major restrictions on users. VARIABLE:ACCESS_FLAGS:3 As above, but also requires user to possess the ARPANET_ACCESS identifier when connecting to a non-local host (see LOCAL_HOST definition below) This is the usual value for a site that doesn't mind users accessing other internal systems but does not want uncontrolled access to the whole of the internet (which may incur costs). VARIABLE:ACCESS_FLAGS:7 As above, but also requires user to possess the INTERNET_ACCESS identifier in order to connect to ANY host. Local Hosts With the appropriate value of ACCESS_FLAGS, access to non-local hosts can be restricted to those possessing the ARPANET_ACCESS identifier. But what is a 'Local Host'? Hosts can be defined as 'local' (and hence accessible WITHOUT possession of the ARPANET_ACCESS identifier) using the LOCAL_HOST configuration record in INET$CONFIG: General form is: LOCAL_HOST:address:address-mask where: LOCAL_HOST is the required keyword address is the address of the networks/hosts to be local address-mask is the mask to determine which subset of 'address' is to be local Examples: LOCAL_HOST:123.45.0.0:255.255.0.0 * Defines addresses 123.45.0.0 through 123.45.255.255 as local, and accessible without possession of ARPANET_ACCESS LOCAL_HOST:120.67.3.1:255.255.255.255 * Defines the specific address 120.67.3.1 as local, and accessible without possession of ARPANET_ACCESS. LOCAL_HOST:0.0.0.0:0.0.0.0 * Defines all addresses as local There can be as many LOCAL_HOST definitions as required. Note that they are only relevant if the ACCESS_FLAGS variable contains the appropriate setting. Creating and Granting Identifiers If flags 2 or 4 are set, then the corresponding identifiers MUST exist. If they do not, a warning will be issued when the IP network is started and the corresponding flag settings will be ignored. To create them: $ set def sys$system: $ mc authorize add/identifier INTERNET_ACCESS add/identifier ARPANET_ACCESS To grant the identifiers to a user (actually to a UIC): $ set def sys$system: $ mc authorize grant/identifier INTERNET_ACCESS username grant/identifier ARPANET_ACCESS username To remove the identifiers from a user: $ set def sys$system: $ mc authorize revoke/identifier INTERNET_ACCESS username revoke/identifier ARPANET_ACCESS username -------------------------------------------------------------------------------- 2.11 >>>> NOTES ON TCP TUNING [14-JUL-1995] ----------------------------- For optimum performance, the OpenCMU software should be 'tuned' to match the settings of the network to which it is connected. This article is taking from the 'alt.winsock' newsgroup and relates primarily to the configuration of PCs. However the information applies to other systems too, OpenCMU included. For MTU, substitute the OpenCMU configuration variable MAX_TCP_DATASIZE. For MSS, substitute the OpenCMU configuration variable DEFAULT_MSS. For RWIN, there is no configurable setting in OpenCMU (at least, not a documented one). MTU, MSS and RWIN settings: The size of packets which a particular Internet access provider's network likes to use can vary greatly. Ideally, in direct downloads, your Maximum (data) Segment Size should match the network to which you are connected through your PPP or SLIP dial-up connection. The size of header added to the "datagram" is usually 40 bytes (20 bytes for TCP and 20 bytes for IP), yielding a Maximum Transmission Unit of MSS+40. One of my providers (UltraNet) gives me access via PPP to an EtherNet- based network, which likes MTU=1500 (i.e. MSS=1460). The other (NetCom) gives me access via Compressed SLIP (CSLIP) to a system which likes MSS=512 (i.e MTU=552). However, most of us like to get downloads from machines on other networks, which we reach through several intermediate networks along the Internet. If I request a 1500 byte packet (or stream of them) from a remote Ethernet, chances are the 1500-byte packets will have to be relayed through one of these intermediaries. In my case, most of the time when I enable Trumpet WinSock's TCP Trace, I will see my MTU=1500 PPP provider sending me a stream of 536-byte data segments in one of these long-distance downloads. (This is a kind of default size which all TCP/IP servers are supposed to be able to use, regardless of whatever other size they offer.) These same downloads through my CSLIP provider come (unsurprisingly) as 512-byte streams through his 512-byte "funnel". Obviously, I use MSS=512 (MTU=552) with NetCom on CSLIP, because they can't send me anything bigger. (If I insist, I'll get each 536-byte data segment broken into two packet fragments - 512 and 24, each with its own 40-byte header and "acknowledge" signal back from my machine - not very fast.) However, I use MSS=536 (MTU=576) with UltraNet on PPP, because most of the time I'm not getting downloads *from* them (MTU=1500), but just *through* them. If I request a 1460-byte data segment, UltraNet will happily pass-on my request. Usually, it results in two 536-byte segments and a 388-byte segment, each transmitted with a 40-byte header after awaiting my machine's "acknowledgement of receipt" of the last one. (Sometimes, two 512's and a 436; and there are old machines out there on the 'net which like even smaller datagrams!) This is an old problem. In the days of ARPANet, the maximum packet size was only two-thirds the size of the Ethernet maximum. With the diversity of networks now populating the Internet, it's gotten even worse. (I believe, for instance, that NetBIOS-based systems like MSSs that are multiples of 32 bytes.) So, in summary, your "optimum" MSS/MTU settings depend on your IP (can't be bigger than his) and on *the smallest MTU* of all the machines on the particular path through the Internet taken by the particular down- load you request. (Big help, right?) RWIN ("Receive WINdow") is nothing more than the buffer your machine waits to fill before attending to whatever other TCP/IP transactions (like mail) are occurring on other "threads" through the multiple logical "sockets" your WinSock has open while your download is in progress. Since your download packets may be coming a long (electrical) distance, that trip-delay should be less than your RWIN-filling time at the speed the packets are coming in, or you won't "keep the pipe full" for maximum throughput. If RWIN is too large, however, the latency time your other threads experience may be intollerable. (This is especially true if you have 2 or 3 windows open in Netscape and have multiple downloads occuring in the background while you're "surfing" -your "surfing" may show annoyingly long response times.) Most people seem to find RWIN of 3-to-4 MSSs a good compromise. If all you do is large file downloads, RWINs of 8 or even 10 times MSS will yield slightly better throughput, but slightly poorer response delays if you try to ask anything else from the 'net while the download is in progress. After all this, if you want a good (but not "optimal") set of numbers, I'd suggest either: (1) MSS=536/MTU=576 and RWIN=2144 or 4288; or, if your Internet Provider has MSS=512, (2) MSS=512/MTU=552 and RWIN=2048 or 4096. [If your IP's MSS is even smaller, use it and MTU=MSS+40, with RWIN=4*MSS - I'd change providers, if possible.] IN SUMMARY: Use TCP Trace to tune your settings for the size datagrams that appear in the downloads from the sites you access most often. (The path they follow will vary, of course, but this is generally as close as you can come to an "optimum" setting to avoid fragmentation of your requested packet sizes into sizes that intermediaries on the 'net can handle.) I've generally found that if your provider can handle MTU=576/MSS=536, most transfers will move right along without the slow-down effects of packet fragmentation. If he can only handle 552/512, that's still pretty good. For example, my 28.8Kbps modem connections run at 3.2Kbytes/sec with MSS=536 PPP, and 3.1Kbytes/sec with MSS=512 CSLIP for binary or compressed files. (The fastest *direct* downloads from an Ethernet host will occur with MTU=1500, of course.) (Note:If you're downloading over transoceanic telephone links, you may be limited by their throughput. For this reason, my downloads from Australia and, especially Scandanavia, are much slower than those from within North America, where I'm located). Your mileage may vary ;-) With thanks to: "Albert P. Belle Isle" -------------------------------------------------------------------------------- 3.0 KNOWN PROBLEMS ------------------ This section lists known problems with the current base release that are either outstanding or fixed by one or more of the patch kits. -------------------------------------------------------------------------------- 3.1 >>>> IPACP [13-JUL-1995] -------------- The IPACP process coordinates all IP traffic. It also includes a built in ethernet driver and telnet server. 3.1.1 >>>> IPACP ISSUES STATUS CODES TO OPCOM [11-OCT-1994] When the IPACP process (which coordinates the IP traffic) has problems, it can issue system status codes to OPCOM. Here is a typical sequence: %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.75 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE status error. Status = 00000A00 %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.83 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE retried 5 times. %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.89 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE $QIO read error (dev_inact), RC=000020D4 To determine the exact problem, it is first necessary to translate the status codes (00000A00 and 000020D4) into the more usual text form. The DCL lexical function F$MESSAGE will translate them for you. Here is a little command file to make it easier: $! SHOWMSG.COM $! Usage: @SHOWMSG 20D4 $ WRITE SYS$OUTPUT F$MESSAGE(%X'P1') Typically, the messages are indicative of a problem with the ethernet itself or with the ethernet controller; the status messages may help to determine the root cause. The message texts from OpenCMU are not part of the standard system message files. For a translation of the error code into the text to be possible, the user must have issued a SET MESSAGE command on the file NETERROR.EXE. The installation of OpenCMU should have placed this in the SYS$MESSAGE directory. If not, locate the file called NETERROR.OBJ in the CMUIP_ROOT:[*...] tree and relink it to form the NETERROR.EXE, using this command: $ LINK/SHARE=SYS$COMMON:[SYSMSG]NETERROR NETERROR.OBJ Following this, the message texts can be made available to F$MESSAGE using: $ SET MESSAGE SYS$MESSAGE:NETERROR [Note: if, for any reason, NETERROR.OBJ does not exist in the directory tree, it can be found in the second saveset of the OpenCMU kit - CMUIP066.B] 3.1.2 >>>> IPACP CRASH DUE TO QUOTA EXCEEDED [20-MAR-1995] For systems with a high IP load, IPACP may occasionally crash with a quota exceeded. This does not refer to disk quota, but to one of the process quota limits. Usually, the quota in question is BYTLM. The default BYTLM provided for IPACP (65536) is sufficient for only about 20 connections. IPACP takes about 32000 for itself and each connection takes about 1872 bytes. This requirement is NOT currently documented. To increase the BYTLM for the IPACP, modify the IP_STARTUP.COM procedure and change the value of the /BUFFER_LIMIT qualifier on the RUN command that starts the IPACP process. Then shut down and restart IPACP. At the current time, there also appears to be a memory leak in IPACP which has the effect of gradually reducing the available BYTLM over time. When this gets close to zero, IPACP will hang (as it retries) and then crash soon afterwards. It is therefore desirable to give IPACP more BYTLM than the typical load might suggest. If this sort of crash is experienced, increase the BYTLM by 50% and restart it. 3.1.3 >>>> IPACP CRASHES WITH DIVIDE BY ZERO ERROR [15-AUG-1995] On some systems, the IPACP supplied in the V6DRIVER.SAVE patch kit can cause divide by zero problems when running OpenCMU on OpenVMS 6.1. If this happens, return to the IPACP.EXE image supplied in the TEKIP0665A.SAVE patch kit. The erroneous version identifies itself as version 6.7. -------------------------------------------------------------------------------- 3.2 >>>> NAMRES [13-JUL-1995] --------------- NAMRES is the DNS Name Resolver, responsible for translating system names into IP addresses, and vice versa. If not running, use of domain names is not possible though use of IP addresses ought to continue to work. 3.2.1 >>>> NAMRES GIVES DOMAIN REFERRAL EXCEEDED MESSAGES [11-OCT-1994] The name resolver can produce the message `Maximum domain referral limit exceeded' and fail to resolve a name into its address. This is often indicative of incorrect configuration of the name resolver. Ensure that the following lines are included in the NAMRES$CONFIG file: Variable:TIMEOUT:5 Variable:REFMAX:10 Variable:RECURSE:1 You might also want to add: Variable:NS_RETRANS:2 (NOTE: in table 3-8 of the last official manual, the last variable, labelled TIMEOUT, should be labelled RECURSE. TIMEOUT is given correctly as the second entry in the table). Restart the name resolver if necessary: $ IPNCP IPNCP> NAMRES EXIT .... IPNCP> STARTUP /NAMRES 3.2.2 >>>> NAMRES HANGS IN RWAST [12-JUL-1995] After some time, the NAMRES process can hang in an RWAST state, preventing further name resolutions from taking place. This is a bug in the current version and no fix is currently available. Processes in an RWAST state cannot be killed so stopping and restarting the NAMRES process is not possible by standard means. However, a number of workarounds may be possible: * Change the process name and restart NAMRES $ SET PROCESS/ID=xxxx/NAME=OLDNAMRES $ IPNCP STARTUP/NAMRES * Start up NAMRES under a privileged username different from that normally used. * Reboot the system. The last is the only recommended way to completely clear a hung 'RWAST' process. -------------------------------------------------------------------------------- 3.3 >>>> NFS [13-JUL-1995] ------------ The NFS server allows directory hierarchies to be made accessible over the network, such that they can be 'mounted' as a disk on another system. There is no NFS client to allow local mounting of remote disks. 3.3.1 >>>> WHY DOESN'T THE NFS SERVER WORK [11-OCT-1994] The NFS server broke with version 6.6-5 of OpenCMU. At this time, there is no workable solution. IF NFS is a requirement, version 6.6-4 is the last version in which NFS works. -------------------------------------------------------------------------------- 3.4 >>>> FTP [13-JUL-1995] ------------ FTP provides file tranfer capabilities. The FTP server allows remote users to connect and transfer files. The FTP client allows local users to access remote systems. 3.4.1 >>>> WHY IS FTP SO SLOW [11-OCT-1994] The version of FTP supplied with the master 6.6-5 kit suffers from a number of bugs. One of these causes excessive error rates and retransmissions resulting in a low throughput rate. It is STRONGLY recommended that the 6.6-5A patch kit be applied. This greatly improves the performance. See also the freeware MGFTP software (described in more detail in the `Software' section elsewhere). 3.4.2 >>>> WHY DOES FTP CRASH WITH `EXCEEDED QUOTA' [11-OCT-1994] FTP (client or server) can fall over with an `exceeded quota' message if the SYSGEN parameter `MAXBUF' is not set correctly. The latest recommendation is for the minimum value to be 8192. Note that transferring files with large records, exceeding MAXBUF, may still cause problems. 3.4.3 >>>> FTP OF BACKUP SAVESETS GIVES CRC ERRORS [11-OCT-1994] One major use of FTP is in transferring BACKUP savesets to/from other systems. Often this leads to the recipient having difficulties unpacking that saveset; in particular, using BACKUP to list or unpack it results in a stream of messages similar to `CRC error' to the user's terminal and to OPCOM. This article summarizes why the error occurs and how to correct it. When BACKUP creates a saveset, it writes the file with a fixed length record format - the length being that specified with BACKUP's /BLOCK qualifier. For example: BACKUP/BLOCK=8192 * s.bck/save Creates a file with fixed length records of 8192. When FTP is used, in binary mode, the data is sent correctly but the record structure changes; typically, it is created with 512 byte records. Thus, when BACKUP is used to list or unpack the file contents, it finds that the record length of the file does not match the size used originally (this value is stored in the BACKUP saveset header as well as in the file header). If both ends of the FTP session support the special STRUC VMS mode of transfer, then it should be used and the file will transfer correctly. If this structure is not supported, the record structure becomes corrupted and must be manually `fixed up' before BACKUP can be used. There are three ways in which this can be done. Note that, in each case, the technique will work ONLY if the file has been transferred in binary mode ftp. If the file format has been corrupted by ANY other means (such as kermit, or a pathworks file copy) then the techniques will need to be modified appropriately. 1. Use the VMS CONVERT utility to alter the record structure: $ CONVERT/FDL=SYS$INPUT file.bck file.bck RECORD FORMAT FIXED SIZE nnnn ^Z Where 'nnn' is the record size used on the original BACKUP command. NOTE: a new copy of the file is made. 2. Use the public domain utility called FILE (courtesy of Joe Meadows): $ FILE/RECORD_SIZE=nnn file.bck Where 'nnn' is the record size used on the original BACKUP command. NOTE: this utility does NOT make a copy of the file; instead it patches the file header directly. It is wise to make a backup copy before using this technique!!! 3. Use the public domain utility called FIX_SAVESET (author unknown): $ FIX_SAVESET file.bck This utility scans the file, on the assumption that it is a backup saveset; picks out the original record length from the backup saveset header stored in the file; and finally, patches the file header record size back to this length. A new copy of the file is not made. Summary: To summarize the correct method of transferring a BACKUP saveset using FTP: 1. If both ends support STRUC VMS, then a. ftp> SET STRUC VMS b. ftp> GET file File will be stored locally with the correct attributes. 2. If STRUC VMS is not supported by one or both ends, then a. ftp> BINARY b. ftp> GET file Once file arrives on the VMS system: c. FIX_SAVESET file Availability: ftp://ftp.kcl.ac.uk/default/fix_saveset.* ftP://ftp.kcl.ac.uk/joemeadows/file.* NOTE: These items are available in source form only and require a C compiler. 3.4.4 >>>> CANNOT LOGIN TO FTP SERVER AFTER UPGRADE TO OPENVMS 6.0 [20-JAN-1995] Following an upgrade to OpenVMS 6.0, users cannot log in to the FTP server once they have changed their password!. This is because the password hashing algorithm is updated in OpenVMS 6.0 and all new passwords use the new hashing algorithm. The existing FTP_SERVER does not know about the new one and consequently cannot hash correctly, causing a password mismatch. An updated FTP_SERVER is available. This will run on all version of VMS from 5.4 upwards. Alternatively, install MadGoat FTP (see software section elsewhere in this document). -------------------------------------------------------------------------------- 3.5 >>>> TELNET [13-JUL-1995] --------------- TELNET allows interactive use. The telnet server, built into the IPACP, allows remote users to access the local system. The telnet client allows local users to access remote systems interactively. 3.5.1 >>>> WHY DOES TELNET SOMETIMES HANG IN `RWAST' [11-OCT-1994] TELNET clients prior to version 5.0 could, under certain conditions, lock up a process in an RWAST state. All users are strongly recommended to upgrade to Version 5.0-1 of TELNET in which this problem, and others, are solved. 3.5.2 >>>> WHY DOES TELNETTING INTO OPENCMU HANG [11-OCT-1994] When telnetting into a OpenCMU host, the system does not prompt for a username until an extra carriage return appears. There are three known, unrelated, causes for this problem. First, a bug in earlier versions of the OpenCMU telnet software is known to cause unexpected hangs. To fix this, All users should install the latest patches to OpenCMU (6.6-5A) and the telnet client. Second, some PC telnet clients are known to contain problems that prevent them successfully interworking with OpenCMU TELNET. PC-NFS telnet versions 4.x and 5.x suffer from this problem. To fix, avoid these clients - there are plenty of reasonable alternative telnet clients around. Finally, it may be the case that some PC telnet's do not correctly negotiate the telnet options when the call is connected. One or other end can wait indefinitely for the opposite end to continue. At this time, no clear solution is known but the problem can sometimes be alleviated by adding the following to the OpenCMU INET$CONFIG file: Variable:TELNET_NEG_TIMEOUT:0 This causes telnet not to wait for negotiations to timeout, and can speed up those logins which appear to hang for a long time. Note: Under OpenVMS 6.1, the telnet pause bug appears again and there is no current solution to this. -------------------------------------------------------------------------------- >>>> 3.6 MISCELLANEOUS [ 22-AUG-1995 ] ---------------------- This section notes various unrelated items and known bugs that may affect several applications. 3.6.1 PORT NUMBER ALLOCATION BUG [ 22-AUG-1995 ] There is a bug in the low level IP software in OpenCMU 6.6-5 and up, that can result in bad port numbers being returned to an application. The details are as follows: * Client requests that a free port be allocated and set up for listening. * OpenCMU allocates and sets up the port correctly but returns ZERO back to the caller instead of the port number. * Subsequent references to the port then fail. NOTE: If the client requests an explicit port number, rather than letting Open CMU select it, the port number is returned correctly. Here is an example of the problem with FTP: * FTP client has a control connection opened to port 20 on the remote FTP server and wants to download a file. * FTP client requests OpenCMU to allocate a free port and set it up for listening, the idea being that the remote FTP server will make an outgoing call to this port and send the file to it. The OpenCMU bug causes ZERO to be returned for the randomly allocated port. * FTP client sends the returned port number to the FTP server in a PORT command, thus: PORT 123,45,1,2,0,0 * FTP server tries to open the data connection back to this port on the client system. This fails because port zero does not exist. This problem is corrected in the forthcoming 6.7 release. This bug is known to affect WWW clients, such as Lynx and Mosaic, where they are linked with an OpenCMU compatible socket library. The effect is to cause FTP transfers to fail unexpectedly while other protocols work fine. Note that the OpenCMU FTP client gets around the problem by randomly allocating the port itself, based on some function of the date/time, and asking OpenCMU to allocate that specific port. This causes the port number to be returned correctly but risks clashing with a port allocated by another application on the same system. The risk is small but can cause random failures of FTP. The same technique can be used by user written applications. -------------------------------------------------------------------------------- 4.0 >>>> FREE AND PUBLIC DOMAIN SOFTWARE SUPPORTING OPENCMU ----------------------------------------------------------- In this section is described a number of network applications which are known to work with the OpenCMU transport. All are available freely (I.E. without charge) though some authors have chosen to retain copyright (freeware rather than public domain). The locations of these software items are given via URLs. The presence of a '*' wildcard does not imply that the URL can be used 'as is' to fetch the whole package, but merely that there are several files which make up the item. Volunteers are always required to port other network applications to the latest OpenCMU release. If you port anything, please notify the FAQ maintainer and the OpenCMU mailing list. Also, please try to persuade the original author of any ported application to include your OpenCMU changes in the official release. This will greatly reduce the amount of work needed to track the latest releases of software. -------------------------------------------------------------------------------- 4.1 >>>> TCP/IP TRANSPORT INTERFACE LIBRARIES [10-OCT-1994] --------------------------------------------- There are a number of different free and commercial TCP/IP transports available for OpenVMS, including UCX, Multinet, OpenCMU, Pathway and TCPware. Each has a slightly different programming interface, making it somewhat difficult to write portable network applications. A universal, though not exclusive, de-facto standard for interfacing applications to the network is the Berkeley (BSD) 'sockets' interface. By writing applications conforming to this standard, it should be a relatively simple matter to link with the transport specific socket library. Unfortunately, there are other considerations that make this difficult; non-standard or transport-specific header files for one. The software here provides a selection of socket libraries that interface an application, written to the sockets standard, to the OpenCMU networking software. Some libraries also interface to two or more different network transports. For maximum portability, applications should be written in terms of these multi-transport interfaces. The recommended one is the SOCKETSHR library on top of the NETLIB library. Some of the applications described in this section require a specific socket library interface, so it may be necessary to install two or more of them on a given system to get all the applications to run. 4.1.1 >>>> NETLIB [10-OCT-1994] ----------------- Summary: A vendor independent TCP/IP programming interface. Description: NETLIB solves the problem by providing a vendor-independent programming interface that sits between the application and the particular version of TCP/IP installed on the system. Thus, applications can be written in terms of NETLIB routines and will run over any transport supported by NETLIB. Transports Supported: NETLIB supports OpenCMU; also, Multinet, TCPware, UCX and TWG's Win/TCP and Pathway Access. Interface Type: Similar to BSD sockets in concept but not in syntax. See SOCKETSHR package. Author: Matt Madison Pre-Requisites: NONE, except for one of the supported TCP/IP transports listed above. Availability: ftp://ftp.spc.edu/macro32/savesets/netlibNNN.zip ftp://ftp.wku.edu/madgoat/netlibNNN.zip ftp://ftp.kcl.ac.uk/madgoat/netlib.* [ NNN = version number ] 4.1.2 >>>> SOCKETSHR [10-OCT-1994] -------------------- Summary: A BSD sockets interface to NETLIB Description: SOCKETSHR provides a complete BSD compatible socket library that allows applications to be written with complete independence of the underlying network transport. It is written to interface to the NETLIB software, which provides an interface to all the available TCP/IP transports for VMS. A recommended package for all users who are writing or porting network applications. Transports Supported: All those supported by NETLIB Interface Type: BSD sockets compatible Author: Thanks go to Eckart Meyer for making this package available, and to Mike O'Malley, on whose LIBCMU package this is based. Pre-Requisites: To use SOCKETSHR, the NETLIB package is a pre-requisite; to use SOCKETSHR with UDP applications requires NETLIB version 1.7 as a minimum! Availability: ftp://ftp.ifn.ing.tu-bs.de/vms/socketshr/socketshr_bin_NNN.zip ftp://ftp.ifn.ing.tu-bs.de/vms/socketshr/socketshr_src_NNN.zip ftp://ftp.kcl.ac.uk/default/SOCKETSHR.* [ NNN = version number ] 4.1.3 >>>> SOCKIT [10-OCT-1994] ----------------- Summary: A socket library interface for VMS network applications Description: SOCKIT provides an emulation of the BSD socket routines for VMS. The interesting thing about this package is that it will interface to several of the commonly available TCP/IP transports, OpenCMU included. Transports Supported: OpenCMU Wollongong UCX (thus works with Multinet if UCX emulation on!) X.25 Interface Type: BSD sockets compatible Author: Peter Kay Pre-Requisites: NONE. The code to interface to each transport is built-in. Availability: ftp://ftp.kcl.ac.uk/default/sockit.* 4.1.4 >>>> LIBCMU [10-OCT-1994] ----------------- Summary: A socket library interface for OpenCMU Description: LIBCMU is a purpose built library of routines for interfacing applications that use Berkeley sockets to the OpenCMU programming interface. This library allows a number of applications written for sockets to be easily ported to OpenCMU. Note that development of this library has ceased. It is available for some applications that still require it but new developments should use the SOCKETSHR/NETLIB combination instead. Transports Supported: OpenCMU InterFace Type: BSD sockets compatible Author: Thanks go to Mike O'Malley for writing and maintaining the LIBCMU software. Availability: ftp://kermit.columbia.edu/vms-libcmu/ckvlcmu.hex ftp://ftp.kcl.ac.uk/cmu-tcpip/libcmu.* -------------------------------------------------------------------------------- 4.2 >>>> MAIL APPLICATIONS [10-OCT-1994] -------------------------- Electronic mail is one of the main applications used over TCP/IP networks. It allows messages to be sent from one user to another even though they are on opposite sides of the world. Provided the users both have access to a computer system running compatible mail software, messages can be sent easily. OpenCMU does not provide any mail applications. Instead one or more of the applications listed below are recommended. 4.2.1 >>>> MX ELECTRONIC MAIL [10-OCT-1994] ------------------------------- Summary: A comprehensive SMTP based network mail system that interfaces directly into VMS MAIL and the underlying TCP/IP network. Description: MX provides full SMTP mail support and interfaces to VMS MAIL. It also provides a mailing list and file server facility. MX is completely free of charge and may be obtained from your local DECUS representative or from the sites listed below. Pre-Requisites: MX requires the NETLIB interface library. Author: Matt Madison and Hunter Goatley (C) MadGoat Software ltd. Availability: ftp://ftp.spc.edu/mx/mxNNN/mxNNN.* ftp://ftp.kcl.ac.uk/madgoat/mx.* [ NNN = version number ] 4.2.2 >>>> IUPOP3 [10-OCT-1994] ----------------- Summary: A POP3 mail server Description: POP3 is a protocol that allows a PC user to download mail from a central mail server and read it on the PC using PC style interfaces. A client that understands the POP protocol must run on the PC and many public domain or shareware ones are available (Win/QVT, Eudora, PC-Eudora, POPmail, Pegasus Mail and MINUET to name but a few). IUPOP3 is a POP3 server that runs under a number of systems, including VMS, and runs over the OpenCMU TCP/IP software (also UCX and Multinet). Pre-Requisites: IUPOP3 requires a specific library for OpenCMU, INET_CMUTIL. Note the original author of this software (see below) does NOT currently support a OpenCMU version. The OpenCMU port is a one off. Author: Indiana University Thanks to Brian T. Carcich for the OpenCMU port. Availability: ftp://ftp.indiana.edu/pub/vms/iupop3/v1.7/* ftp://ftp.indiana.edu/pub/vms/iupop3/v1.7-CMU-TEK/* ftp://ftp.kcl.ac.uk/iupop3/iupop3-017.* ftp://ftp.kcl.ac.uk/cmu-tcpip/inet_cmutil.bck -------------------------------------------------------------------------------- 4.3 >>>> NEWS APPLICATIONS [10-OCT-1994] -------------------------- Usenet news is a world wide distributed news system. Messages generated on one system are passed around the world rapidly, to all other systems. To simplify the management of news, messages are divided into `newsgroups', each newsgroup concentrating on one general topic. Using an appropriate newsreader, a user can `subscribe' to a particular set of newsgroups and read all the related messages in a manner similar to mail. There are some 3000+ different user groups currently. There are a number of parts to the news system. Firstly, software is required to gather batches of news from an upstream `feed' site and insert it into a local news database; Second, software is required to allow users to read the news database, possibly modifying it by sending new messages. The news database can be on the same system as the user, or the news database can be on a remote system, accessible through a client-server mechanism. The user's news reader program becomes a client, using the network to access a news server. 4.3.1 >>>> ANU NEWS [10-OCT-1994] ------------------- Summary: A complete news system Description: ANU-NEWS provides a complete package to deal with USENET news. News is received from an up-stream news feed site and stored in a local on-disk database. This database can be interrogated by local users running the NEWS application; A news server can be set up that provides access to the news databases via any convenient NEWS client running on another system (see NEWSRDR elsewhere in this document for one example). The ANU-NEWS server supports OpenCMU. Author: Thanks go to Geoff Huston for writing and maintaining the ANU NEWS software. Availability: ftp://kuhub.cc.ukans.edu/anu_vNNN/news_vNNN.zip ftp://ftp.kcl.ac.uk/news/news.* [ NNN = version number ] 4.3.2 >>>> NEWSRDR [10-OCT-1994] ------------------ Summary: A VMS newsreader client Description: NEWSRDR is a news client that allows the user to access the news groups stored on a news server system. This gives users a quick way of accessing all the news without the need to build a full news system. Pre-Requisites: NEWSRDR requires the NETLIB library to interface to the underlying TCP/IP network. Author: Thanks go to Matt Madison for writing and maintaining the NEWSRDR software. >>> FNEWS [10-OCT-1994] ---------------- Summary: A NEWS reading client for VMS Description: FNEWS is another news reader client. It offers local caching of newsgroups to speed the downloading of messages. Pre-Requisities: None: FNEWS builds for the currently installed transport. Author: ??? Availability: ftp://zephyr.grace.cri.nz/pub/fnews/vms/fnews.bck ftp://ftp.kcl.ac.uk/news/fnews.* -------------------------------------------------------------------------------- 4.4. >>>> WORLD WIDE WEB APPLICATIONS [10-OCT-1994] ------------------------------------- The world wide web is a distributed hypertext system that literally encompasses the world. A document can be loaded from a remote server which contains hypertext links to other documents anywhere in the world. Documents can be text, graphics, sound, binary etc. World Wide Web servers accept requests from clients to download documents, and world wide web clients accept those documents and format them for the user's display. A single display can be composed of a mix of text and graphics etc. World Wide Web uses the HyperText Markup Language (HTML) to specify document format and remote links. World Wide Web links specify the location of the document (site, directory and filename) as well as the protocol used to access them (ftp, wais, gopher, http etc.). So world wide web combines the functionality of a number of client types. 4.4.1 >>>> MOSAIC [10-JUL-1995] ----------------- Summary: A graphical World Wide Web client. Description: MOSAIC is a superb graphical interface for browsing through the World Wide Web and gopher databases on the internet. By using a hypertext markup language, text, images and sound can be pulled together, irrespective of their locations, into a single on-screen document. This is THE program for information seekers. Pre-Requisites: DECwindows/Motif is required to display the document. SOCKETSHR and NETLIB are pre-requisite for the version described here. Please note that there are several different ports of this version but only those listed support SOCKETSHR, and hence OpenCMU. Author: MOSAIC is written by the National Centre for Supercomputing Applications at the University of Illinois. Availability: ftp://ftp.kcl.ac.uk/mosaic/mosaic.* ftp://ftp.kcl.ac.uk/mosaic/mosaic_bin.* ftp://ftp.ifn.ing.tu-bs.de/vms.socketshr/mosaic_src_2-4.zip ftp://ftp.ifn.ing.tu-bs.de/vms.socketshr/mosaic_bin_2-4.zip 4.4.2 >>>> LYNX [10-OCT-1994] --------------- Summary: A World Wide Web browser, designed for line mode terminals (such as Digital's VT series. Description: LYNX is a line mode version of a World Wide Web hypertext browser. It combines the functions of gopher and FTP, together with WWW and allows access from a VT compatible terminal. It provides similar functionality to that of Mosaic except that a simple terminal interface is all that is required. Pre-Requisites: A socket library interface is required; LYNX recognizes a number of socket libraries. For OpenCMU, either the SOCKETSHR (recommended) or the LIBCMU socket library is required. Author: Thanks go to the LYNX developers, mainly at the University of Kansas, for developing and maintaining this software, and for making it freely available. Availability: ftp://ftp.kcl.ac.uk/lynx/lynx.* 4.4.3 >>> HTTP_SERVER [10-OCT-1994] --------------------- Summary: A World Wide Web server conforming to the standard HTTP (HyperText Transfer Protocol) mechanism. Description: HTTP_SERVER provides a VMS system with the ability to act as a World Wide Web server using the HTTP protocol. It will accept requests from HTTP clients (such as MOSAIC - see elsewhere in this document) and return the necessary information. A full description of the World Wide Web system is outside the scope of this summary but it is, in essence, a distributed hypertext system capable of mixing text, images, graphics, animation and sound into a single on-screen display, with each element being on different systems anywhere in the world. The HTML language is used to specify the links. Pre-Requisites: DECthreads is required; so a minimum OpenVMS of 5.5 is required. The server contains all the necessary interfaces to work with OpenCMU, as well as with UCX and Multinet. Author: Thanks go to David Jones for writing and maintaining this software. Availability: ftp://osu.edu/http_server.tar ftp://ftp.spc.edu/macro32/savesets/http_server.zip ftp://ftp.wku.edu/vms.fileserv/http_server.zip ftp://ftp.kcl.ac.uk/default/http_server.* -------------------------------------------------------------------------------- 4.5 >>>> FILE TRANSFER APPLICATIONS [10-OCT-1994] File transfer is another major application run over the network. It allows files to be transferred between two different systems using a simple set of commands. It is most often used for retrieving files from one of the many public domain archive sites around the world. OpenCMU comes prepackaged with an FTP client and server but it is worth considering the alternatives listed here. 4.5.1 >>>> MADGOAT FTP [10-OCT-1994] ---------------------- Summary: An alternative FTP client and server. Description: The File Transfer program (or FTP) is an important part of the TCP/IP applications set. It allows files to be moved between two systems. MGFTP is a file transfer program which can be used over any of the available TCP/IP transports, including OpenCMU. This client is more functional than the one provided with OpenCMU and is recommended. Useful enhancements include: * Logging of server transactions to a file in each user's home directory * User control over how the server is used on an account * Anonymous FTP has per-directory messages * FTP client has automatic anonymous login * FTP client can have aliases defined to connect/fetch from specific systems/files Pre-Requisites: The NETLIB interface is required. Author: MGFTP is based on the OpenCMU FTP client and server, written by many people. Thanks go to Matt Madison and Hunter Goatley, of MadGoat software, and to Darrell Burkhead, for writing and maintaining MGFTP and making it available as freeware. Availability: ftp://ftp.wku.edu/madgoat/mgftp.zip ftp://ftp.spc.edu/macro32/savesets/mgftp.zip ftp://ftp.kcl.ac.uk/madgoat/mgftp.* 4.5.2 >>>> C-KERMIT [31-MAR-1995] ------------------- Summary: File transfer over the current terminal connection to a host. Description: The KERMIT program is a widely used way of tranferring files over serial lines between systems. The user's terminal temporarily becomes a client and the user's host session temporarily becomes a server. The KERMIT protocol allows switching between terminal mode and file transfer mode, as well as sending or requesting files to be transferred. In the past, kermit has been able to set up terminal sessions, and run the file transfers, only over serial line connections. More recent versions have allowed the terminal connections, and hence the file transfers, to take place over telnet links by having direct TCP/IP support built in. The latest version of C-kermit supports direct TCP/IP connections and will work over the OpenCMU package. Pre-Requisites: The OpenCMU version requires a socket library specific to the transport on which it runs. For OpenCMU, the required socket library is LIBCMU. Author: Columbia University and many contributors around the world. Availability: ftp://kermit.columbia.edu/kermit/b/ckvvcmu.hex 4.5.3 >>>> FSP [27-OCT-1994] -------------- Summary: File transfer over a lightweight UDP based protocol. Description: FSP is a simple file transfer protocol based around UDP rather than TCP protocols. It is designed to impose minimal load on the server and does not require the user to log in or identify themselves. Essentially, the client throws UDP packets at a server asking for a portion of a file or info about a file, and keeps throwing the same request at it until the server responds. Thus an FSP transfer is, in principle, resilient to server failure as it will retry until the server comes back on-line. It is said that FSP is what anonymous FTP should have been. This package is a port of the unix FSP client and server to VMS, and directly supports UCX, Multinet and OpenCMU. It also supports the vendor independent SOCKETSHR library. Pre-Requisities: Either: LIBCMU For direct OpenCMU support Or: SOCKETSHR For vendor independent TCP/IP support (recommended) NETLIB (required by SOCKETSHR) Author: Various. Availability: ftp://ftp.kcl.ac.uk/default/fsp.* -------------------------------------------------------------------------------- 4.6 >>>> NETWORK ARCHIVE SEARCH APPLICATIONS [10-OCT-1994] -------------------------------------------- There are many many sites around the world that allow public access to parts of the file system that contain freely available software. With so many sites and so many packages available, it can often be difficult to locate the appropriate site that holds the required software. ARCHIE was designed to ease this problem. A large number of sites are responsible for indexing all the other sites in the world and keeping track of what each contains. The ARCHIE mechanism allows a user to supply a keyword to the nearest archie host and have it return a list of software locations that contain the keyword somewhere in the directory/filename path. This usually results in a large list of potential places to search, which can then be interrogated using an FTP utility. 4.6.1 >>>> ARCHIE [10-AUG-1994] ----------------- Summary: A client used to interrogate the world-wide archive software database. Description: ARCHIE is a client for interrogating ARCHIE servers. Such servers maintain up to date information about what software is available on various FTP archives around the world and permit the client to ask where a particular item can be found. Given a keyword, ARCHIE will try to find all archives that contain files with the keyword as part of the name. Once located, FTP can be used to retrieve the item from the nearest archive. ARCHIE is configurable to use any one of a number of nearby archie servers with one selected at compile time as the default. Pre-Requisites: For OpenCMU usage, a socket library interface is required. There are two parallel versions of archie. One runs over the LIBCMU package, and the other runs over the SOCKETSHR package. Check the readme files with the software to see which is applicable. Author: Unknown. Many contributors. Availability: ftp://ftp.kcl.ac.uk/archie/archie.* -------------------------------------------------------------------------------- 4.7 >>>> GOPHER APPLICATIONS [10-OCT-1994] ---------------------------- GOPHER is a protocol for requesting information from a remote system. GOPHER servers run on these systems to handle the incoming requests and GOPHER clients are necessary to interact with a user and generate the requests. Information is presented to the user in a menu format and allows information of many different types to be downloaded, viewed and/or saved. One GOPHER server can send back a pointer to a file of information that exists on a completely different system. This provides a generalised world wide browsing system NOTE: To a large extent, the functionality of GOPHER has been superceded by the World Wide Web but there are still a large number of gopher servers around. 4.7.1 >>>> GOPHER [10-OCT-1994] ----------------- Summary: A gopher client and server for VMS Description: The gopher client allows a user to request documents from any gopher server in the world. The gopher server allows a site to serve documents to the rest of the world. Pre-Requisites: The gopher client requires NETLIB, and will run over any of the supported TCP/IP transports. The gopher server specifically requires either UCX or MULTINET. There is no version for OpenCMU. Author: The University of Minnesota Availability: ftp://boombox.micro.umn.edu//pub/gopher/VMS/gopher*VMS*.zip ftp://ftp.kcl.ac.uk/gopher/gopher.* -------------------------------------------------------------------------------- 4.8 >>>> FINGER APPLICATIONS [10-OCT-1994] ---------------------------- The FINGER protocol allows a client to `finger' another user on another system to find out basic information. For instance, fingering a system will give details of who is currently logged on. Fingering an individual username will give selected personal details (real name, location and any immediate plans). Note - some sites consider finger to be a security risk and do not run either the server or the clients. Thus it may not be possible to `finbger' some systems. 4.8.1 >>>> MADGOAT FINGER [10-AUG-1994] ------------------------- Summary: A FINGER Client and Server Description: FINGER provides both client and server facilities; This allows users to discover information about users on another system and for those users, in turn, to find out about local users. Pre-Requisites: FINGER requires the NETLIB library Author: Matt Madison Hunter Goatley (C) MadGoat Software ltd. Availability: ftp://ftp.spc.edu/macro32/savesets/mg_finger.zip ftp://ftp.kcl.ac.uk/madgoat/mg_finger.* -------------------------------------------------------------------------------- 4.9 >>>> DOMAIN NAME SERVER APPLICATIONS [10-OCT-1994] ---------------------------------------- The Domain Name Server (or DNS) is responsbible for mapping system names into network addresses. It is sometimes useful to interrogate the DNS directly, perhaps to do fault determination or to track down a system name. 4.9.1 >>>> NSQUERY [10-OCT-1994] ------------------ Summary: Request information from the DNS Description: NSQUERY is a very useful utility that allows a user to interrogate any Domain Name Server for full site details. Pre-Requisites: Requires the NETLIB library. Author: Thanks go to Matt Madison for writing and mainting the NSQUERY software. Availability: ftp://ftp.spc.edu/macro32/savesets/nsquery.zip ftp://ftp.kcl.ac.uk/madgoat/nsquery.* 4.9.2 >>>> IPADDR [10-OCT-1994] ----------------- Summary: Convert name to IP Address and vice versa Description: IPADDR is a simple utility to map an IP address into its corresponding host name(s) and vice versa. Pre-Requisites: Requires the NETLIB library. Author: Andy Harper Availability: ftp://ftp.kcl.ac.uk/default/ipaddr.* -------------------------------------------------------------------------------- 4.10 >>>> MISCELLANEOUS APPLICATIONS ------------------------------------ 4.10.1 >>>> NETTIME [19-DEC-1994] ------------------- Summary: Consult a network time server and display, or set, the time from it Description: A NTP conformant utility that can be used to consult a known time server and use it to set the clock. Alternatively, the current time on various different time servers can be displayed. Pre-Requisites: None Author: John Clement Availability: ftp://ftp.kcl.ac.uk/cmu-tcpip/nettime.bck 4.10.2 >>>> RLOGIN [28-APR-1995] ------------------ Summary: Remote Login to another host Description: An implementation of the BSD 'R' series of protocols which allows the user to login from one host to another host without specifying a password, using the concept of 'trusted' hosts. Note that this can be a major security hole. Pre-Requisites: None Author: Don Stokes Availability: ftp://toyvax.zl2tnm.gen.nz/rlogin.bck ftp://ftp.kcl.ac.uk/cmu-tcpip/rlogin.bck 4.10.3 >>>> CSDRV [28-APR-1995] ----------------- Summary: VJ Compressed SLip Driver Description: A compressed SLIP driver that is a drop-in replacement for the supplied SLDRV SLIP driver. This provides the Van Jacobsen header compression on SLIP connections, increasing the throughput and performance. Pre-Requisites: None Author: Don Stokes Availability: ftp://toyvax.zl2tnm.gen.nz/csdrv.bck ftp://ftp.kcl.ac.uk/cmu-tcpip/csdrv.bck