CMU OpenVMS TCP/IP Frequently Asked Questions Last Update: 7-OCT-1996 FAQ Maintainer: Andy Harper A.Harper @ kcl.ac.uk PART 2 OF 4 -------------------------------------------------------------------------------- 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 articlea entitled "MORE ON SETTING UP SLIP" and "AUTOMATING DIAL-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 >>>> AUTOMATING DIAL-UP SLIP [23-MAY-1996] -------------------------------- If you are going to connect to an Internet Service Provider (ISP) via modem with a temporary SLIP connection you will have to: 01. Comment out the SLPDRV definition in INET$CONFIG. You will have to Stop, then restart IPACP, NAMRES and any other processes that die if you previously defined SLPDRV in INET$CONFIG because IPACP becomes the Owner of the line assigned to the SLIP driver. 02. Call your ISP using CKERMIT or SET HOST/DTE. 03. LOGIN and read the temporary IP address assigned to you by the ISP. 04. SPAWN out of your communication process. 05. Uncomment the SLPDRV definition in INET$CONFIG and edit it to use the assigned IP address. 06. Stop, then restart IPACP, NAMRES and any other processes that die. 07. Use the internet resources that you are now connected to. 08. When finished, comment out the SLPDRV definition in INET$CONFIG. 09. Stop, then restart IPACP, NAMRES and any other processes that die. 10. Logout of your spawned process (returns you to your communication process). 11. Exit your communication process. I wrote a CKERMIT script and a DCL command procedure that work together to automate the whole process. If you have access to an Internet Browser, you can get SLIP.ZIP (the compressed file archive) from: http://www.afn.org/~rpuller/. KLIP.INI will require some modification to match it's input/output to that required by your ISP, but it should be easy to figure out. SLIP.COM "should" work out of the box. Obviously, you'll need CKERMIT. -------------------------------------------------------------------------------- 2.7 >>>> 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:124.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.8 >>>> 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.9 >>>> 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://ftp2.kcl.ac.uk/vms/default/lavdriver.* -------------------------------------------------------------------------------- 2.10 >>>> 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.11 >>>> 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.12 >>>> 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" --------------------------------------------------------------------------------