home *** CD-ROM | disk | FTP | other *** search
/ vsiftp.vmssoftware.com / VSIPUBLIC@vsiftp.vmssoftware.com.tar / FREEWARE / FREEWARE40.ZIP / cmuip / cmutcpip.faq < prev    next >
Text File  |  1995-10-03  |  115KB  |  3,218 lines
  1. Article 4588 of vmsnet.networks.tcp-ip.cmu-tek:
  2. 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
  3. From: System Manager <system@kcl.ac.uk>
  4. Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
  5. Subject: CMU Frequently Asked Questions List OCT 1995
  6. Message-ID: <00997344.A198D26A.22@bay.cc.kcl.ac.uk>
  7. Date: Sun, 01 Oct 1995 05:10:04 +0000 (GMT)
  8. Organization: Cmu-Openvms-Ip<==>Vmsnet.Networks.Tcp-Ip.Cmu-Tek Gateway
  9. X-Gateway-Source-Info: Mailing List
  10. Lines: 3070
  11.  
  12.                                                               CMU OpenVMS TCP/IP
  13.  
  14.                                                       Frequently Asked Questions
  15.  
  16.                                                         Last Update: 12-SEP-1995
  17.  
  18.                                                     FAQ Maintainer:  Andy Harper
  19.                                     A.Harper @ kcl.ac.uk
  20.  
  21. --------------------------------------------------------------------------------
  22.  
  23. This document is a set of Frequently Asked Questions (FAQ) About the CMU
  24. OpenVMS TCP/IP (hereinafter referred to as OpenCMU) package originally
  25. developed for VMS by Carnegie Mellon University and Tektronix. It is updated on
  26. an irregular basis, as new FAQs arise, and is posted on a monthly basis to the
  27. OpenCMU mailing list. The updated version may be obtained through anonymous FTP
  28. from `FTP.KCL.AC.UK' in directory [.CMU-TCPIP] as file CMU.FAQ.
  29.  
  30. Each FAQ section begins with >>>> followed by the title of the section and the
  31. source of the answer, where known. Use of SEARCH on this document allows
  32. FAQ titles to be located.
  33.  
  34. Please notify the maintainer of any omissions, out-of-date or incorrect
  35. information.
  36.  
  37. --------------------------------------------------------------------------------
  38.  
  39.                                 DISCLAIMER
  40.  
  41. The Author of this FAQ is in no way connected with the development of the
  42. OpenCMU software and does not offer support on it. The information has been
  43. collected from various postings to newsgroups and from personal experiences of
  44. using the software. Any questions regarding the software should be posted to
  45. the appropriate mailing list or news group, or by contacting the authors
  46. directly.
  47.  
  48. No responsibility can be taken for any problems arising from the use of any
  49. information in this FAQ. All information is provided on a best efforts basis
  50. and accuracy cannot be guaranteed.
  51.  
  52. Except where otherwise acknowledged, the information in this FAQ is
  53.  (C) Copyright Andy Harper, Kings College London, 1994,1995
  54.  
  55. While it may be freely distributed and used, it may not be sold or republished
  56. for profit without the permission of the author.
  57.  
  58. --------------------------------------------------------------------------------
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91. Changes Since SEP 1995 Edition.
  92. -------------------------------
  93.  
  94. 20-SEP-1995    Add disclaimer 
  95. 13-SEP-1995    Correct command to add rights identifiers
  96. 12-SEP-1995    Clarify contents of DEVICE_INIT device dependent field
  97. 12-SEP-1995    Clarify interaction with DECnet
  98.  
  99.  
  100. Changes Since AUG 1995 Edition.
  101. -------------------------------
  102.  
  103. 24-AUG-1995    Note on upgrading to OpenVMS 6.2
  104. 22-AUG-1995    Change references to CMU into OpenCMU, where applicable
  105. 22-AUG-1995    Add details on OpenCMU port allocation bug.
  106. 17-AUG-1995    Even more information on working with  OpenVMS 6.1
  107. 16-AUG-1995    Additional information on working with OpenVMS 6.1
  108. 15-AUG-1995    Modify intro in setting up IP over DECnet
  109.  
  110.  
  111. Changes Since JUL 1995 Edition.
  112. -------------------------------
  113.  
  114. 27-JUL-1995    More minor typos corrected.
  115. 24-JUL-1995    Added requirment for DECthreads to HTTP_SERVER application
  116. 24-JUL-1995    Added requirement for DECwindows/Motif to MOSAIC application
  117. 24-JUL-1995    Clarify status of dial-in and dial-out SLIP support
  118. 21-JUL-1995    Clarify LIBCMU status; development no longer continuing
  119. 21-JUL-1995    Change to section 4 title; clarify status of software
  120. 18-JUL-1995    Rewrite socket libraries introduction
  121. 18-JUL-1995    Different layout for software locations; use URLs everywhere
  122. 18-JUL-1995    Add brief description of products in 'known problems' section
  123. 18-JUL-1995    Update MAXBUF quota recommendation
  124. 17-JUL-1995    Updated DECwindows setup to include DECW$TRANSPORT_xxx logical
  125. 17-JUL-1995    More typos corrected
  126. 14-JUL-1995    New section on TCP tuning
  127. 14-JUL-1995    New section on OpenCMU security options
  128. 13-JUL-1995    Re-ordered the known problems section by facility
  129. 13-JUL-1995    New section on setting up gateway definitions
  130. 13-JUL-1995    New section on setting up X.25 links
  131. 13-JUL-1995    New section on setting up DECnet links
  132. 13-JUL-1995    New section on setting up SLIP links
  133. 13-JUL-1995    Update details on LYNX to cover SOCKETSHR compatible version
  134. 12-JUL-1995    Various small typos corrected
  135. 12-JUL-1995    More updates to the DEVICE_INIT description
  136. 12-JUL-1995    Updated OpenCMU introduction
  137. 12-JUL-1995    Add information on Hung NAMRES process and how to fix
  138. 10-JUL-1995    Add information on the DEVICE_INIT configuration record
  139. 10-JUL-1995    Updated details on new SOCKETSHR compatible MOSAIC
  140. 5-JUL-1995    Updated info on fixing BACKUP savesets corrupted by the
  141.         transfer process.
  142.  
  143.  
  144.  
  145. Changes Since APR 1995 Edition.
  146. -------------------------------
  147.  
  148. 28-APR-1995    Added details of RLOGIN software and Compressed Slip driver
  149. 28-APR-1995    Miscellaneous typos corrected
  150. 28-APR-1995    Added note about NFS support
  151.  
  152.  
  153. Changes Since MAR 1995 Edition.
  154. -------------------------------
  155.  
  156. 31-MAR-1995    Miscellaneous typos corrected
  157. 31-MAR-1995    Clean up section on obtaining software
  158. 31-MAR-1995    Update current versions section with OpenVMS 6.x kit availability
  159. 31-MAR-1995    Update C-kermit details for current release
  160. 30-MAR-1995    Add details giving availability of older openCMU versions
  161. 28-MAR-1995    Added section on posting questions to the newsgroup
  162. 20-MAR-1995    Improve documentation on IPACP BYTLM requirements
  163. 15-MAR-1995    Changed address of mailing list
  164.  
  165.  
  166. Changes Since JAN 1995 Edition.
  167. -------------------------------
  168.  
  169. 20-JAN-1995    Add note on FTP password hashing problem and new FTP_SERVER
  170. 20-JAN-1995    Add note on TELNET pause bug for OpenVMS 6.1
  171. 19-JAN-1995    Add details of VMS 6.x patch kits
  172. 9-JAN-1995    Correct spelling of listserver sitename
  173.  
  174.  
  175. Changes Since DEC 1994 Edition.
  176. -------------------------------
  177.  
  178.  
  179. 19-DEC-1994    Add details of NETwork TIME set/display utility
  180. 19-DEC-1994    Add details of automated listserv subscription mechanism
  181.  
  182.  
  183. Changes Since OCT 1994 Edition.
  184. -------------------------------
  185.  
  186. 27-OCT-1994    Add details of the FSP client/server software
  187. 11-OCT-1994    Rewrite section on telnet hanging
  188. 11-OCT-1994    Rewrite OpenCMU prerequisites section
  189. 11-OCT-1994    Change layout on all sections
  190. 10-OCT-1994    All relevant references to CMU changed to OpenCMU !
  191. 10-OCT-1994    Add note on OpenCMU under OpenVMS 6.1
  192. 10-OCT-1994    Reorganize software details by function; rewrite some entries
  193. 10-OCT-1994    Add details of SOCKIT - a general socket library for OpenVMS
  194. 3-OCT-1994    Add details of SOCKETSHR - socket interface to NETLIB
  195.  
  196.  
  197. Changes Since AUG 1994 Edition.
  198. -------------------------------
  199.  
  200. 10-AUG-1994    Add hint on location of NETERROR.OBJ file
  201. 3-AUG-1994    Fix minor typos
  202. 2-AUG-1994    MX now at revision 4.1; updated filenames aaccordingly
  203.  
  204.  
  205. Changes Since JUL 1994 Edition.
  206. -------------------------------
  207.  
  208. 1-AUG-1994    Add more info on SLIP connections
  209. 11-JUL-1994    Correct instructions for use under OpenVMS 6.x
  210. 5-JUL-1994    Corrected use of CONVERT/FDL to modify BACKUP saveset format
  211.  
  212.  
  213. Changes Since JUN 1994 Edition.
  214. -------------------------------
  215.  
  216. 4-JUL-1994    Updated locations for WWW HTTP server
  217. 15-JUN-1994    Making OpenCMU work with OpenVMS 6.0
  218. 15-JUN-1994    Add details of ARCHIE software for OpenCMU
  219. 15-JUN-1994    Add details of IPADDR software for OpenCMU
  220. 3-JUN-1994    Correct typo in MGFTP description
  221. 3-JUN-1994    MGFTP is freeware, not public domain
  222.  
  223.  
  224.  
  225. Changes Since MAY 1994 Edition.
  226. -------------------------------
  227.  
  228. 24-MAY-1994    Add details of LYNX package
  229. 16-MAY-1994    Rewrite GOPHER details.
  230. 16-MAY-1994    Update details of FTP patch kit
  231. 16-MAY-1994    Update OpenCMU overview LPD/LPRSYMB description
  232. 16-MAY-1994    How to print OpenCMU IP Error message texts
  233. 16-MAY-1994    Info on IPACP BYTLM quotas
  234. 11-MAY-1994    Tidy up software availability tables
  235. 11-MAY-1994    Add details of MGFTP - MadGoat FTP - product
  236. 6-MAY-1994    Add details of MG_FINGER - MadGoat Finger - product
  237.  
  238.  
  239.  
  240. Changes Since APRIL 1994 Edition.
  241. ---------------------------------
  242.  
  243. 14-APR-1994    Update Anonymous FTP address of UK mirror site
  244. 12-APR-1994    Correct directory of spanish mirror site
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267. --------------------------------------------------------------------------------
  268.  
  269.             C O N T E N T S
  270.  
  271.  
  272.     1.0    GENERAL INFORMATION . . . . . . . . . . . . . . . .
  273.         1.1 What is OpenCMU . . . . . . . . . . . . . . . .
  274.         1.2 Obtaining OpenCMU . . . . . . . . . . . . . . .
  275.         1.3 PreRequisites . . . . . . . . . . . . . . . . .
  276.         1.4 How does OpenCMU Affect DECnet  . . . . . . . .
  277.         1.5 Current Versions  . . . . . . . . . . . . . . .
  278.         1.6 The OpenCMU Mailing List/Newsgroup  . . . . . .
  279.         1.7 Getting Technical Help from the Newsgroup . . .
  280.  
  281.     2.0    COMMON SETUP AND CONFIGURATION INFORMATION  . . . .
  282.         2.1 Setting up the Network Interface  . . . . . . .
  283.         2.2 Notes on setting up a serial Line connection  .
  284.         2.3 Notes on setting up a DECnet connection . . . .
  285.         2.4 Notes on setting up an X.25 connection  . . . .
  286.         2.5 More on setting up SLIP . . . . . . . . . . . .
  287.         2.6 Setting up a gateway  . . . . . . . . . . . . . 
  288.         2.7 Setting Up DECwindows over OpenCMU IP . . . . .
  289.         2.8 Setting up an Anonymous FTP server  . . . . . .
  290.         2.9 Setting up OpenCMU on OpenVMS 6.0 and 6.1 . . .
  291.         2.10 How to setup restrictions on network access  .
  292.         2.11 Notes on TCP Tuning  . . . . . . . . . . . . .
  293.  
  294.  
  295.     3.0    KNOWN PROBLEMS  . . . . . . . . . . . . . . . . . .
  296.         3.1 IPACP . . . . . . . . . . . . . . . . . . . . .
  297.             3.1.1 IPACP Issues status codes to OPCOM  . . .
  298.             3.1.2 IPACP crash due to quota exceeded . . . .
  299.             3.1.3 IPACP crashes with divide by zero error .
  300.         3.2 NAMRES  . . . . . . . . . . . . . . . . . . . .
  301.             3.2.1 'Referral limit exceeded' . . . . . . . .
  302.             3.2.2 NAMRES hangs in RWAST . . . . . . . . . . 
  303.         3.3 NFS . . . . . . . . . . . . . . . . . . . . . .
  304.             3.3.1 Why doesn't the NFS server work . . . . .
  305.         3.4 FTP . . . . . . . . . . . . . . . . . . . . . .
  306.             3.4.1 Why is FTP so slow  . . . . . . . . . . .
  307.             3.4.2 Why does FTP crash with `exceeded quota'.
  308.             3.4.3 FTP of BACKUP savesets gives CRC errors .
  309.             3.4.4 Server login fails after 6.0 upgrade  . .
  310.         3.5 TELNET  . . . . . . . . . . . . . . . . . . . .
  311.             3.5.1 Why does TELNET sometimes hang in `RWAST'
  312.             3.5.2 Why does TELNETing into OpenCMU hang  . .
  313.         3.6 MISCELLANEOUS . . . . . . . . . . . . . . . . .
  314.             3.6.1 Port number allocation bug  . . . . . . .
  315.     
  316.     4.0    FREE AND PUBLIC DOMAIN SOFTWARE SUPPORTING OPENCMU
  317.  
  318.         4.1 TCP/IP Transport Interface Libraries  . . . . .
  319.             4.1.1 NETLIB  . . . . . . . . . . . . . . . . .
  320.             4.1.2 SOCKETSHR . . . . . . . . . . . . . . . .
  321.             4.1.3 LIBCMU  . . . . . . . . . . . . . . . . .
  322.                     4.1.4 SOCKIT  . . . . . . . . . . . . . . . . .
  323.  
  324.         4.2 Mail Applications . . . . . . . . . . . . . . .
  325.             4.2.1 MX  . . . . . . . . . . . . . . . . . . .
  326.             4.2.2 POP3 Server . . . . . . . . . . . . . . .
  327.  
  328.         4.3 News Applications . . . . . . . . . . . . . . .
  329.             4.3.1 ANU NEWS  . . . . . . . . . . . . . . . .
  330.             4.3.2 NEWSRDR . . . . . . . . . . . . . . . . .
  331.             4.3.3 FNEWS . . . . . . . . . . . . . . . . . .
  332.  
  333.         4.4 World Wide Web Applications . . . . . . . . . .
  334.             4.4.1 MOSAIC  . . . . . . . . . . . . . . . . .
  335.             4.4.2 LYNX  . . . . . . . . . . . . . . . . . .
  336.             4.4.3 HTTP_SERVER . . . . . . . . . . . . . . .
  337.  
  338.         4.5 File Transfer Applications  . . . . . . . . . .
  339.             4.5.1 MADGOAT FTP . . . . . . . . . . . . . . .
  340.             4.5.2 C-KERMIT  . . . . . . . . . . . . . . . .        
  341.             4.5.3 FSP . . . . . . . . . . . . . . . . . . .
  342.  
  343.         4.6 Network Archive Search Applications . . . . . .
  344.             4.6.1 ARCHIE  . . . . . . . . . . . . . . . . .
  345.  
  346.         4.7 Gopher Applications . . . . . . . . . . . . . .
  347.             4.7.1 GOPHER  . . . . . . . . . . . . . . . . .
  348.  
  349.         4.8 Finger Applications . . . . . . . . . . . . . .
  350.             4.8.1 MADGOAT FINGER  . . . . . . . . . . . . .
  351.  
  352.         4.9 Domain Name Server Applications . . . . . . . .
  353.             4.9.1 NSQUERY . . . . . . . . . . . . . . . . .
  354.             4.9.2 IPADDR  . . . . . . . . . . . . . . . . .
  355.  
  356.         4.10 Miscelleneous Applications   . . . . . . . . .
  357.             4.10.1 NETTIME  . . . . . . . . . . . . . . . .
  358.             4.10.2 RLOGIN . . . . . . . . . . . . . . . . .
  359.             4.10.3 CSDRV  . . . . . . . . . . . . . . . . .
  360.  
  361. --------------------------------------------------------------------------------
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399. 1.0    GENERAL INFORMATION
  400. ---------------------------
  401.  
  402.  
  403. 1.1 >>>> WHAT IS OPENCMU                [12-JUL-1995]
  404. ------------------------
  405.  
  406. The OpenCMU software provides a full TCP/IP network transport for VAX systems
  407. running the VMS operating system. This allows a VMS system to participate in
  408. the world wide Internet network and take advantage of the wealth of information
  409. and software available on it.
  410.  
  411. Support for various network interfaces is given in this table:
  412.  
  413.   +---------------------------------------------------------------------+
  414.   I Network Interface        SUPPORTED ?                I
  415.   +---------------------------------------------------------------------+
  416.   I                                    I
  417.   I  IP over Ethernet        YES                    I
  418.   I  IP over Serial Line (SLIP)    YES  [1]                I    
  419.   I  IP over DECnet        YES                    I
  420.   I  IP over Compressed SLIP    YES, via 3rd party driver        I
  421.   I  IP over X25        YES, via 3rd party driver        I
  422.   I                                    I
  423.   I  IP over Serial Line (PPP)  NO                    I
  424.   I                                    I
  425.   +---------------------------------------------------------------------+
  426.  
  427.     [1] SLIP is supported for statically connected links only; there is
  428.         no dial-out support, and dial-in is supported only partially.
  429.  
  430.  
  431. Support for various standard TCP services is given in this table:
  432.  
  433.   +---------------------------------------------------------------------+
  434.   I Application        Client            Server                I
  435.   +---------------------------------------------------------------------+
  436.   I                                    I
  437.   I  TELNET        YES            YES            I
  438.   I  FTP  [1]        YES            YES            I
  439.   I  LPD        YES            YES            I
  440.   I  FINGER        YES            YES            I
  441.   I  TALK        YES            YES            I
  442.   I  X windows        YES            YES            I
  443.   I  MAIL [2]        YES (3rd party s'ware)  YES (3rd party s'ware)    I
  444.   I  NFS  [3]        NO            NO (broke with 6.6-5)    I
  445.   I  RLOGIN [4]        YES (3rd party s'ware)  NO            I
  446.   I  REXEC        NO            NO            I
  447.   I  RSH        NO            NO            I
  448.   I  XDM        --            NO            I
  449.   I                                    I
  450.   +---------------------------------------------------------------------+
  451.   
  452.     [1] Although FTP is included with OpenCMU, a much improved client and
  453.     server is available as freeware - MadGoat FTP. See the applications
  454.     section later.
  455.  
  456.     [2] MAIL is supported through the freeware MX package. See the applications
  457.         section later.
  458.  
  459.     [3] An NFS server was supported up to Version 6.6-4. It broke with Version
  460.         6.6-5.
  461.  
  462.     [4] An RLOGIN client is available through a third party; see the
  463.         applications section later.
  464.  
  465.  
  466. Also Available:
  467.  
  468.    o  IPNCP for monitoring and controlling the TCP/IP system
  469.  
  470.    o  UNIXSHR - A TCP/IP socket library
  471.  
  472.  
  473. Also Supported:
  474.  
  475.    o  Domain Name Service is supported through the freeware DOMAIN package
  476.       by Bruce Orchard. Usually available from the same sites as OpenCMU.
  477.  
  478.  
  479. Note:
  480.  
  481.    o  Electronic mail support is also provided by the chargeable PMDF package
  482.       available from Innosoft. Contact them for details.
  483.                             <A.Harper@kcl.ac.uk>
  484.  
  485. --------------------------------------------------------------------------------
  486.  
  487. 1.2 >>>> OBTAINING THE OPENCMU SOFTWARE                [30-MAR-1995]
  488. ---------------------------------------
  489.  
  490. The OpenCMU software is entirely free of charge and may be obtained through
  491. your local DECUS representative. The last relevant symposium tape that contains
  492. the OpenCMU software is the Fall 1992 tape, in directory [VAX92B.CMU] and on
  493. DECUS CDROM #12.
  494.  
  495. A number of sites on the Internet maintain up to date anonymous FTP directories
  496. containing the OpenCMU software. These can be accessed using the FTP program or
  497. a mail server such as FTPMAIL that can transfer files from an anonymous FTP
  498. account back to the requestor via e-mail.
  499.  
  500. The following URLs point to where the latest versions of software may be
  501. obtained:
  502.  
  503.  * Master Site:
  504.      ftp://sacusr.mp.usbr.gov/cmuip/        (Henry Miller <henrym@sacto.mp.usbr.gov>)
  505.      ftp://sacusr.mp.usbr.gov/tekip/ftp/    ( " )
  506.      ftp://sacusr.mp.usbr.gov/telnet/        ( " )
  507.  
  508.  * Mirrors
  509.      ftp://ftp.kcl.ac.uk/cmu-tcpip/        (Andy Harper <A.Harper@kcl.ac.uk>)
  510.      ftp://ftp.csus.edu/pub/cmuip/        ( ?? )
  511.      ftp://dmc.com/vms/cmuip/            (Dick Munroe <munroe@dmc.com>)
  512.      ftp://marduk.iib.uam.es/pub/VMS/cmutek-ip/ (J.R.Valverde <sistema@biomed.iib.uam.es>)
  513.  
  514.  
  515. There are versions of OpenCMU available that run on earlier versions of VMS
  516. available from a number of sources:
  517.  
  518.      DECUS Fall 92 tape,        directory [VAX92B.CMU]
  519.      DECUS CDROM VS0152,        directory [LT92B.CMU]
  520.      ftp://flash.acornsw.com,   directory  VS0152:[LT92B.CMU]
  521.      ftp://ftp.kcl.ac.uk/cmu-tcpip/oldversion/
  522.  
  523.  
  524. The first time you obtain OpenCMU, you will very likely not have an existing
  525. network facility and hence will be unable to obtain the software across the
  526. network. In this case, you should contact your local DECUS representative for a
  527. copy of the software on a suitable media.
  528.  
  529. Subsequently, you can pick up new versions and patches using the network from
  530. many of the sites listed above. Announcements about these are made to the
  531. OpenCMU mailing list.
  532.                             <A.Harper@kcl.ac.uk>
  533.  
  534. --------------------------------------------------------------------------------
  535.  
  536. 1.3 >>>> PREREQUISITES                        [30-MAR-1995]
  537. ----------------------
  538.  
  539. Before installing OpenCMU on your system, take note of the following
  540. requirements.
  541.  
  542. Hardware Requirements:
  543.  
  544.    A Digital VAX system.
  545.    NOTE: Digital ALPHA systems are NOT currently supported.
  546.  
  547.    A Network interface.
  548.    OpenCMU supports the following types of network interface:
  549.     * Ethernet
  550.     * Serial line (using SLIP)
  551.     * X.25 Synchronous interface
  552.     * DECnet link
  553.  
  554.    A network link to the outside world.
  555.    The network interface must be connected to a network with at least one other
  556.    network aware system connected to it. Consult your local site management or
  557.    network service providers for details of how to connect to the rest of the
  558.    IP world (the `Internet').
  559.  
  560.    Each interface to the network MUST be allocated its own unique IP address
  561.    (your service provider will supply this) and a subnet mask.
  562.  
  563.    Although optional, it is highly likely that access to an IP router and a
  564.    Domain Name Server will be required. Ask your service provider for the IP
  565.    addresses of each of these.
  566.  
  567.  
  568. Minimum VMS:
  569.  
  570.    The latest version of OpenCMU requires VMS 5.2 and upwards.
  571.  
  572.                             <A.Harper@kcl.ac.uk>
  573.  
  574. --------------------------------------------------------------------------------
  575.  
  576. 1.4 >>>> HOW DOES OPENCMU AFFECT DECNET?            [12-SEP-1995]
  577. ----------------------------------------
  578.  
  579. The short answer - it doesn't.  OpenCMU and DECnet are completely independent.
  580. You can run either by itself or both together. The same applies to LAT, X25
  581. over LLC2, PathWorks and all the other network protocols supported by OpenVMS.
  582.  
  583. The only thing necessary is to start DECnet first if both are used. This is
  584. because DECnet needs to modify the ethernet address and hence be the only user
  585. of the network while it does that.
  586.  
  587.                             <A.Harper@kcl.ac.uk>
  588.  
  589. --------------------------------------------------------------------------------
  590.  
  591. 1.5 >>>> CURRENT VERSIONS OF OPENCMU                [31-MAR-1995]
  592. ------------------------------------
  593.  
  594. Base Version:
  595.     OpenCMU 6.6-5        Kit:    CMUIP066.%    { % = A,B,C,D }
  596.  
  597. Update Kits:
  598.     OpenCMU 6.6-5A        Kit:    TEKIP0665A.SAVE
  599.     Telnet 5.0-1        Kit:    TELNETU1050.A
  600.     FTP 2.12        Kit:    FTPU0212.A
  601.  
  602. VMS Version Specific Update Kits:
  603.     Drivers for OpenVMS 6.x    Kit:    V6DRIVER.SAVE
  604.     FTP_SERVER for VMS 6.x  Kit:    FTP_SERVER.SAVE
  605.     IPACP for OpenVMS 6.1    Kit:    IPACP.EXE
  606.  
  607. Additional Kits:
  608.     Compressed Slip driver        CSDRV.BCK
  609.     X25 driver            X25DRV.BCK
  610.     Domain name service kit        DOMAIN-%.BCK    (% = A,B,C)
  611.     
  612.                             <A.Harper@kcl.ac.uk>
  613.  
  614. --------------------------------------------------------------------------------
  615.  
  616. 1.6 >>>> THE OPENCMU MAILING LIST/NEWSGROUP            [11-OCT-1994]
  617. -------------------------------------------
  618.  
  619. An electronic mailing list and news group exists for exchanging information
  620. about the OpenCMU software. This is the preferred way to exchange information
  621. about problems, and their solutions, and to announce updates to the software.
  622. By subscribing, you gain access to a wealth of practical information from other
  623. users and the relevant OpenCMU experts.
  624.  
  625. The address of the electronic mailing list, to which all enquiries or
  626. announcements are directed, is:
  627.  
  628.    CMU-OpenVMS-IP@sacto.mp.usbr.gov
  629.  
  630.  
  631. Subscribe by sending a message containing the single line `subscribe' to:
  632.  
  633.    CMU-OpenVMS-IP-Request@sacto.mp.usbr.gov
  634.  
  635.  
  636. For those with access to USENET, the world-wide electronic NEWS system, this
  637. mailing list is automatically gatewayed to the newsgroup:
  638.  
  639.    vmsnet.networks.tcp-ip.cmu-tek
  640.  
  641. You are recommended to subscribe to the newsgroup wherever possible, in
  642. preference to the electronic mailing list.  Details of some suitable news
  643. readers can be found elsewhere in this document.
  644.                             <A.Harper@kcl.ac.uk>
  645.                             <Mark Berryman>
  646.                             <Tillman@swdev.si.com>
  647.  
  648. --------------------------------------------------------------------------------
  649.  
  650. 1.7 >>>> GETTING TECHNICAL HELP FROM THE NEWSGROUP        [28-MAR-1995]
  651. --------------------------------------------------
  652.  
  653. Much of the information flow on the OpenCMU mailing list and newsgroup are
  654. questions such as `I can't make OpenCMU work...' or some derivative thereof.
  655.  
  656. There are two fast ways you can get information that may help to solve your
  657. problem and it's worth trying these before trying the newsgroup:
  658.  
  659.   o  Look in the manual. There is extensive info in the manual about most
  660.      aspects of the OpenCMU package.
  661.  
  662.   o  Look in the FAQ. Some things that aren't documented in the manual are
  663.      in the FAQ. Your question may be a common one and, if so, the answer
  664.      could well be there.
  665.  
  666.  
  667. It is also useful to:
  668.  
  669.   o  Check the configuration. Most problems arise through a failure to
  670.      correctly configure some aspect of the OpenCMU software; often because of
  671.      a misunderstanding of the various items involved.
  672.  
  673.   o  Check system/user quotas and system parameters. The software is
  674.      sensitive to quotas and some system parameters. The manual and the FAQ
  675.      both contain information on the key ones. Don't assume that the `out of
  676.      the box' software' will run on your system without some tuning.
  677.  
  678.  
  679. If you have checked everything above, and still feel the need to get advice
  680. from other users, make sure that you give sufficient information to convey the
  681. problem to others by enclosing these details:
  682.  
  683.    A.   A description of the problem; Be as specific as possible, since vague
  684.         statements are not helpful.
  685.  
  686.    B.   Details of your configuration. Here, it's probably best to enclose a
  687.         copy of the various configuration files IN THEIR ENTIRETY (I.E. don't
  688.         edit them to include only the relevant bits because you don't
  689.         necessarily know what the relevant bits are yet). Files to include are:
  690.  
  691.           INTERNET.CONFIG
  692.           NAMRES.CONFIG
  693.           IP_STARTUP.COM
  694.  
  695.    C.   A sample transcript of the session, if possible, which includes all
  696.         the error messages. Enclose the whole transcript, not just the portion
  697.         that shows the error. Something that happened earlier might just
  698.         affect what you're doing.
  699.  
  700.         A transcript can be created in a number of ways, perhaps the easiest is
  701.         to use the "SET HOST 0/LOG" command. This creates a new session (and
  702.         you need to login again), recording everything that appears on your
  703.         terminal in a file called "SETHOST.LOG". This logfile is closed once
  704.         you logoff the new session.
  705.                                                         <A.Harper@kcl.ac.uk>
  706.             With thanks to: Harry Meier     <harry@aaas.org>
  707.  
  708.  
  709. --------------------------------------------------------------------------------
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751. 2.0    COMMON SETUP AND CONFIGURATION INFORMATION
  752. --------------------------------------------------
  753.  
  754. 2.1 >>>> SETTING UP THE NETWORK INTERFACE            [12-JUL-1994]
  755. ------------------------------------------
  756.  
  757. The INET$CONFIG file contains a single 'Device_Init'  line for each network
  758. interface to be used for OpenCMU IP. The general format is this:
  759.  
  760.    DEVICE_INIT:driver:devicename:device-specific-info:IP-address:net-mask
  761.  
  762.  
  763. Where:
  764.    DEVICE_INIT        Is the required keyword
  765.    driver        is the name of the interface driver to be used.
  766.    devicename        is the VMS devicename of the interface, or DECnet node
  767.    device-specific-info is device dependent
  768.    IP-address        is the IP address (a.b.c.d) of this interface
  769.    net-mask        is the subnet mask of the network behind the interface
  770.  
  771.  
  772. Examples:
  773.  
  774. [Unless otherwise stated, all example sitenames and IP addresses are
  775. ficticious]
  776.  
  777.  
  778.   Ethernet:
  779.      DEVICE_INIT:ETHER:ESA0:00-00-00-00-00-00:128.2.232.69:255.255.0.0
  780.  
  781.          * Defines an interface that connects to the ethernet via device ESA0.
  782.  
  783.  
  784.   Serial Line:
  785.      DEVICE_INIT:SLDRV:TXB3:REMHOST.CC.CMU.EDU:128.2.232.69:255.255.255.252
  786.  
  787.          * Defines an interface that connects over the TXB3 serial line to a
  788.        remote host using the SLIP protocol.
  789.  
  790.  
  791.   IP over DECnet:
  792.      DEVICE_INIT:DNDRV:KETTLE:IP_DECNET:128.2.232.69:255.255.255.252
  793.  
  794.          * Defines an interface that connects via DECnet to the remote
  795.            node KETTLE.
  796.  
  797.  
  798.   IP over X25:
  799.      DEVICE_INIT:X25DRV:NWA0:T300;S45050180021;L4505018004-0:128.2.232.69:255.255.255.252
  800.  
  801.          * Defines an interface that connects via X25 to the remote node on
  802.            X.25 address 45050180021.
  803.  
  804. Notes:
  805.  
  806.  [1] The OpenCMU manual refers to an XEDRV ethernet driver. This should NOT be
  807.      used. The name ETHER is a special internal driver that is faster and more
  808.      bug-free.
  809.  
  810.  
  811.  [2] All drivers should be in the CMUIP_ROOT:[SYSLIB] directory. Currently,
  812.      these are:
  813.         SLDRV   - The Serial Line, or SLIP, driver
  814.     DNDRV   - The DECnet driver
  815.         X25DRV  - The IP-over-X25 driver (third party)
  816.         CSDRV   - The Compressed-SLIP driver (Third party)
  817.  
  818.  
  819.  [3] If multiple interfaces are configured, then you should also set:
  820.      VARIABLE:IP_FORWARDING:1
  821.      in the INET$CONFIG file if you want packets routed between them.
  822.  
  823.  [4] OpenCMU does not support any of the standard routing information protocols,
  824.      such as RIP. Thus, all gateways must be explicitly specified. If multiple
  825.      interfaces are configured on the OpenCMU host with IP_FORWARDING set, then
  826.      all other hosts on the local subnet(s) must specify the OpenCMU host as
  827.      the gateway for all the other subnets to which it connects.
  828.  
  829.  [5] The device dependent field is ignored for the ethernet driver.
  830.  
  831.                             [A.Harper@kcl.ac.uk]
  832.  
  833. --------------------------------------------------------------------------------
  834.  
  835. 2.2 >>>> NOTES ON SETTING UP A SERIAL LINE (SLIP) CONNECTION    [13-JUL-1995]
  836. ------------------------------------------------------------
  837.  
  838. The SLDRV driver implements SLIP over a statically connected serial line; it
  839. does not handle dial-in or dial-out connections, although such connections can
  840. be established manually.
  841.  
  842.  
  843. Basic Setup:
  844.  
  845.  * Define the DEVICE_INIT record, similar to this:
  846.        DEVICE_INIT:SLDRV:TXB3:NONE:128.2.232.69:255.255.255.252
  847.  
  848.          Note that the subnet mask MUST allow for at least 4 distinct addresses,
  849.          the IP address of the interface itself, the IP address of the remote
  850.          end of the link, and the reserved network and broadcast addresses at
  851.          the low and high end of the range.
  852.  
  853.  * Set the Terminal device characteristics to allow 8-bit transparency:
  854.        $ SET TERMINAL term /PERM /SPEED=nnn /EIGHTBIT /NOTTSYNC /NOHOSTSYNC -
  855.                            /ALTYPAHD /NOECHO /NOBROADCAST /NOLINE /NOWRAP -
  856.                            /LOWERCASE
  857.  
  858.          This command should be placed in the system startup file BEFORE the
  859.          IP software is started.
  860.  
  861.  
  862.  * The system at the remote end of the link should be configured with
  863.    similar serial port characteristics. In particular, ensure that the
  864.    speeds match and that flow control (XON/XOFF) is disabled. The SLIP
  865.    protocol handles flow control itself.
  866.  
  867.  
  868.  * The precise cabling requirements between the two ends of the link are
  869.    dependent on the equipment used.
  870.  
  871.  
  872.  * If the local OpenCMU host is acting as an IP router, so that data from the
  873.    serial line can be passed to another interface, then an additional line
  874.    should be added to the INET$CONFIG file:
  875.        VARIABLE:IP_FORWARDING:1
  876.  
  877.  
  878.  
  879. Using LAT Terminals:
  880.  
  881. If the remote system connects via a serial line into a DECserver port, then
  882. there are some additional steps:
  883.  
  884.   * On the DECserver, set the port characteristics to allow 8-bit transparency
  885.     and disable flow control etc. Issue these commands as a privileged user
  886.     from another port:
  887.  
  888.     Local> CHANGE PORT port AUTOPROMPT DISABLED
  889.     Local> CHANGE PORT port SPEED xxx        ! Set the comms speed
  890.     Local> CHANGE PORT port BROADCAST DISABLED
  891.     Local> CHANGE PORT port INPUT FLOW DISABLED
  892.     Local> CHANGE PORT port OUTPUT FLOW DISABLED
  893.     Local> CHANGE PORT port LOSS NOTIFICATION DISABLED
  894.     Local> CHANGE PORT port VERIFICATION DISABLED
  895.  
  896.     NOTE that some DECservers may not support all of these commands. Other
  897.     characteristics may need modification if their default values are not
  898.     suitable. The above is suitable for a DECserver 700, provided that other
  899.     port characteristics have not been changed away from their default
  900.     values.
  901.  
  902.  
  903.   * On the OpenCMU host, use the LAT control program to create the LTAnnn
  904.     terminal device and map it to the appropriate port on the DECserver:
  905.  
  906.         $ MC LATCP
  907.           CREATE PORT LTAnnnn /DEDICATED    ! This becomes the 'hardwired' line
  908.           SET PORT LTAnnnn /SERVER=server /PORT=port
  909.  
  910.     'nnnn' is an arbitrary unused LAT terminal number, 'server' is the name
  911.     of the DECserver, 'port' is the name of the port used on the DECserver
  912.     for the SLIP link. Use the terminal name 'LTAnnnn' in the DEVICE_CONFIG
  913.     record.
  914.  
  915.     These commands should be placed in the system startup procedure BEFORE
  916.     the IP startup and BEFORE the SET TERMINAL command used to set the device
  917.     characteristics.
  918.  
  919.  
  920.  
  921. Further Notes:
  922.  
  923. Each SLIP line should be allocated it's own unique subnet; that is, one where
  924. the range of addresses does not overlap that possible on another subnet.
  925.  
  926. The device-dependent field of the DEVICE_INIT record is ignored.
  927.  
  928. Consider updating relevant SYSGEN parameters. TTY_ALTYPSIZ can be increased
  929. to allow for large packets. Around 2000 is a recommended value.
  930.  
  931. Although OpenCMU has no facility to automatically dial-out over a modem to
  932. establish a connection, it is possible for the connection to be manually
  933. established before the SLIP port is used.  Dial-in, via a modem, to a SLIP port
  934. is possible except that the OpenCMU software will not notice if the connection
  935. is dropped (having no facility for monitoring the line status). If this is
  936. required, information about it can be found in the article entitled "MORE ON
  937. SETTING UP SLIP" later in this document.
  938.  
  939. Some DECservers can support SLIP directly (that is, action the SLIP protocol
  940. on the port directly and route it onwards using 'real' TCP/IP over ethernet).
  941. If so, it is considerably more convenient to configure the DECserver to deal
  942. with it itself and not bother with SLIP support on the OpenCMU host.
  943.                             <A.Harper@kcl.ac.uk>
  944.  
  945. --------------------------------------------------------------------------------
  946.  
  947. 2.3 >>>> NOTES ON SETTING UP AN IP OVER DECNET CONNECTION    [15-AUG-1995]
  948. ---------------------------------------------------------
  949.  
  950. The DNDRV driver allows the TCP/IP protocol to be used over an existing DECnet
  951. link to a remote node. In this instance, DECnet is used merely as a low level
  952. carrier of the data.
  953.  
  954.  
  955. Basic Setup:
  956.  
  957.  * Define the DEVICE_INIT record, similar to this:
  958.        DEVICE_INIT:DNDRV:KETTLE:IP_DECNET:128.2.232.69:255.255.255.252
  959.  
  960.          Note that the subnet mask MUST allow for at least 4 distinct addresses,
  961.          the IP address of the interface itself, the IP address of the remote
  962.          end of the link, and the reserved network and broadcast addresses at
  963.          the low and high end of the range.
  964.  
  965.          The device name portion of the record is the name of the remote DECnet
  966.          node with whom the link is formed.
  967.  
  968.  
  969. General Notes:
  970.  
  971. The remote node must define a DEVICE_INIT record in similar fashion, but giving
  972. its own IP address and the DECnet name of this node.
  973.  
  974. The documentation does not say anything about what DECnet objects are defined,
  975. or whether the name IP_DECNET in the device dependent information field of the
  976. DEVICE_INIT record is meaningful. Therefore, it is difficult to say whether
  977. this will work in conjunction with a DECnet node that runs a transport other
  978. than OpenCMU IP. However, it is known to work when the remote node is running
  979. MULTINET TCP/IP, as follows:
  980.  
  981.   * In the DEVICE_INIT record, the device-specific-info field must be set to
  982.     the local DECnet nodename prefixed by "IP_".
  983.  
  984.   * Multinet's 'gated' has to be configured to achieve the desired announcement
  985.     and routing.
  986.  
  987.                             <A.Harper@kcl.ac.uk>
  988.                     With thanks to: <rok.vidmar@uni-lj.si>
  989. --------------------------------------------------------------------------------
  990.  
  991. 2.4 >>>> NOTES ON SETTING UP AN X25 CONNECTION            [13-JUL-1995]
  992. -----------------------------------------------
  993.  
  994. The X25DRV driver, which is third party software, allows an IP connection to be
  995. set up over an X25 circuit. This requires the VAX PSI or DECnet/OSI products to
  996. be installed and running.
  997.  
  998. Basic Setup:
  999.  
  1000.  * Define the DEVICE_INIT record, similar to this:
  1001.        DEVICE_INIT:X25DRV:NWA0:T300;S45050180021;L4505018004-0:128.2.232.69:255.255.255.252
  1002.  
  1003.          Note that the subnet mask MUST allow for at least 4 distinct addresses,
  1004.          the IP address of the interface itself, the IP address of the remote
  1005.          end of the link, and the reserved network and broadcast addresses at
  1006.          the low and high end of the range.
  1007.  
  1008.  
  1009.   * The device dependent information part defines the DTE addresses to be used,
  1010.     as a set of ; separated values, as follows:
  1011.  
  1012.        Tnnn            Time in seconds after which the connection is
  1013.                 dropped if there is no activity.
  1014.  
  1015.        S[R]ssssssssssss[-ss]    DTE address [and optional subaddress] of the
  1016.                 remote node to which the connection is to be
  1017.                 established. Connections initiated from this
  1018.                 end will place an outgoing X25 call specifiying
  1019.                 this DTE address [and subaddress].
  1020.                 Specifying the optional [R] will place the call
  1021.                 with reverse charging.
  1022.  
  1023.     R[R]rrrrrrrrrrrr[-rr]    DTE address [and optional subaddress] of the
  1024.                 remote site allowed to call us. Calls from
  1025.                 other addresses will be refused. If omitted,
  1026.                 the DTE address specified by the S parameter
  1027.                 is used.
  1028.                 Specifying the optional [R] will allow us to
  1029.                 accept incoming reverse charge calls.
  1030.  
  1031.     Llllllllllll[-ll]    DTE address [and optional subaddress] of this
  1032.                 node. This is placed into the outgoing call and
  1033.                 may be required if the network does not insert
  1034.                 it automatically.
  1035.  
  1036. General Notes:
  1037.  
  1038. The X25DRV driver is third party software, and not part of the standard OpenCMU
  1039. distribution. It is however freely available.
  1040.                             <A.Harper@kcl.ac.uk>
  1041.  
  1042. --------------------------------------------------------------------------------
  1043.  
  1044. 2.5 >>>> MORE ON SETTING UP SLIP                [11-OCT-1994]
  1045. --------------------------------
  1046.  
  1047. The information below has been culled mostly from personal experience (i.e., it
  1048. works for me).  All IP addresses have been changed.  The reason for this is
  1049. that OpenCMU SLIP doesn't require a password -- if you know the IP address of
  1050. the SLIP interface, and the phone number to dial, you can get in.  Also, any
  1051. explanations given below are not necessarily completely correct; I've tried to
  1052. put everything in simple terms that I understand.  Those caveats given, here
  1053. goes... 
  1054.  
  1055. First, in INET$CONFIG, you need to have *two* separate interfaces: one that
  1056. talks to the SLIP "network", and one that talks to the Ethernet "network". 
  1057. These two interfaces each have their own addresses.  If they "overlap" (this
  1058. will be defined later), the interface to the more general network must come
  1059. *last*.
  1060.  
  1061. Example: in my configuration (remember: *all* ip addresses have been  changed;
  1062. OpenCMU SLIP doesn't bother to ask for a password for connection purposes, so
  1063. anyone who knows the phone number of your modem and the IP address of your SLIP
  1064. interface can connect through your system), I have a VAX with an Ethernet
  1065. interface at IP address  128.97.101.101.  We use subnetting here at UCLA, and
  1066. our network mask is 255.255.255.0.  This means that my VAX can directly connect
  1067. to any computer whose address is 128.97.101.x, where x is in the range 0-255
  1068. (although I believe the first and last are off limits).  To get to any 
  1069. computer with an address not in this range, I need to go through a gateway.  In
  1070. my case, the gateway is at 128.97.101.105.  Note that I can directly connect to
  1071. this computer.  This is, of course, important.  So, I need a line in
  1072. INET$CONFIG that says something like
  1073.  
  1074. Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0
  1075.  
  1076. and further down, one that reads 
  1077.  
  1078. Gateway:GATEWAY.PHYSICS.UCLA.EDU:128.97.101.105:0.0.0.0:0.0.0.0:
  1079.  
  1080. Now, I want to start a SLIP interface with a modem attached to the device TTA2. 
  1081. I am assigned the address range 128.97.101.120 through  128.97.101.127.  This
  1082. is a total of eight addresses, but again, the  first and last are not usable
  1083. for reasons I don't understand (I think  the operative terms are "network
  1084. address" for the .0 one and "broadcast address" for the .127 one).  At this
  1085. point, the six remaining addresses belong to *me*, and are mine to assign as I
  1086. wish. I choose to assign the first one to the SLIP interface itself:
  1087.  
  1088. slip.physics.ucla.edu = 128.97.101.121
  1089.  
  1090. I have a computer at home (say it's a PC).  I choose to assign this the next
  1091. address:
  1092.  
  1093. mypc.physics.ucla.edu = 128.97.101.122
  1094.  
  1095. These names must be established with the network administrator, but I am free
  1096. to dole out the addresses to whomever I choose.
  1097.  
  1098. Note that by the rules above, the ethernet connection can speak directly to
  1099. mypc.  This is incorrect, since that must go through the SLIP interface.  This
  1100. is what I have called overlap above.  The range of SLIP addresses (.120 - .127)
  1101. lies within that of Ethernet addresses (.0-.255).  We therefore need a way to
  1102. tell OpenCMU to use the SLIP interface for the addresses .120-.127, and the
  1103. Ethernet interface for all the others.  We do this simply by placing the SLIP
  1104. device definition first, so that the Device_Init lines now look like:
  1105.  
  1106. Device_Init:SLDRV:TTA2:slip.physics.ucla.edu:128.97.101.121:255.255.255.248
  1107. Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0
  1108.  
  1109. The only new thing here is the mask on the SLIP interface.  That mask has all
  1110. bits set to 1 except the last three.  This means that there are eight addresses
  1111. (2^3) that the SLIP interface can access, which work out to .120-.127.  If
  1112. OpenCMU wants to connect to one of these addresses, it does it through the SLIP
  1113. interface.  If it wants to talk to anything else with an address of
  1114. 128.97.101.x, it does it through the Ethernet interface.  Any other address is
  1115. contacted via the gateway (which itself is contacted via the Ethernet
  1116. interface).
  1117.  
  1118. The only other thing to do is to set the IP_Forwarding flag.  This allows
  1119. OpenCMUI to transmit packets from one interface to the other. without this, you
  1120. couldn't use SLIP to get to the outside world:
  1121.  
  1122. Variable:IP_Forwarding:1
  1123.  
  1124. That should be it.  Restart OpenCMU, and all should be well.  One other thing:
  1125. many SLIP packages on the PC/Mac side expect to give the system some kind of
  1126. password upon connection, and will fail if they don't receive a response from
  1127. the VAX.  This needs to be turned off, since the VAX won't do a thing other
  1128. than just sit there.
  1129.                         <price@uclapp.physics.ucla.edu>
  1130.  
  1131. --------------------------------------------------------------------------------
  1132.  
  1133. 2.6 >>>> SETTING UP A GATEWAY                    [13-JUL-1995]
  1134. -----------------------------
  1135.  
  1136. Packets originating from the local node can only be sent DIRECTLY to a host on
  1137. the same subnet. Packets addressed to a host on a different subnet must be
  1138. directed at a gateway or router. A host is on the same subnet as the local
  1139. system if the following holds true:
  1140.  
  1141.    ( Local-IP-Address .AND. net-mask ) = ( Remote-IP-Address .AND. net-mask )
  1142.  
  1143. where '.AND.' represents a bitwise logical AND of the two values.
  1144.  
  1145.  
  1146. Gateway Record:
  1147.  
  1148. The GATEWAY record of the INET$CONFIG file defines the address of a router
  1149. connecting the current subnetwork to another. It has this general form:
  1150.  
  1151.    GATEWAY:gateway-name:gateway-address:gateway-net:mask
  1152.  
  1153. where:
  1154.    gateway-name        is the name of the gateway
  1155.    gateway-address    is the IP address of the gateway
  1156.    gateway-net        is the network on the other side of the gateway
  1157.    mask            is a subnet mask that determines which subset of the
  1158.             'gateway-net' address can be reached through the
  1159.             gateway.
  1160.  
  1161. Note that 'mask' is NOT the same as the local subnet mask.
  1162.  
  1163.  
  1164. Examples:
  1165.  
  1166.    GATEWAY:router1.mysite.edu:123.45.3.30:145.23.0.0:255.255.0.0
  1167.  
  1168.       Says that addresses 145.23.0.0 thru 145.23.255.255 are accessible via
  1169.       the gateway on address 124.45.3.30.
  1170.  
  1171.  
  1172.    GATEWAY:router2.mysite.edu:124.45.3.31:140.0.0.0:255.0.0.0
  1173.  
  1174.       Says that addresses 140.0.0.0 thru 140.255.255.255 are accessible via
  1175.       the gateway on address 124.45.3.31.
  1176.  
  1177.  
  1178.     GATEWAY:world.mysite.edu:124.45.3.40:0.0.0.0:0.0.0.0
  1179.  
  1180.       Says that all (non-local) addresses are accessible through the gateway on
  1181.       address 124.45.3.40 (Apply the algorithm below to see why this is so). In
  1182.       effect, this is a 'default' router to the rest of the networking world.
  1183.  
  1184.  
  1185.  
  1186. Selecting the Gateway:
  1187.  
  1188. If the address is non-local (I.E. does not match the subnet mask), a gateway
  1189. will be selected by testing each gateway record in turn, in order of definition
  1190. in the configuration file. The first one found that matches will be used.
  1191.  
  1192. The following algorithm is used to determine whether a particular address is
  1193. reachable through a gateway:
  1194.  
  1195.    ( remote-address .AND. mask ) = ( gateway-net .AND. mask )
  1196.  
  1197. In other words, if the network portion of the address ('remote-address'.AND.
  1198. 'mask') matches the network portion of the far network ('gateway-net'.AND.
  1199. mask), packets will be sent to the 'gateway-address'.
  1200.  
  1201. TIP: Think of the 0 in the mask as a 'wildcard' allowing all values in the
  1202. range at that point.
  1203.  
  1204.  
  1205.  
  1206. General Notes:
  1207.  
  1208. Each gateway MUST be directly reachable. That is, it MUST be on the same subnet
  1209. as the local host.
  1210.  
  1211. The 'default' router, if one exists, should be defined as the last gateway in
  1212. the configuration file.
  1213.  
  1214. If a site has multiple gateways out to a particular subnet, to provide failover
  1215. in case of problems, OpenCMU will never use the second and subsequent ones even
  1216. if the first fails to respond. This is a design limitation.
  1217.                             <A.Harper@kcl.ac.uk>
  1218.  
  1219. --------------------------------------------------------------------------------
  1220.  
  1221. 2.7 >>>> SETTING UP DEC WINDOWS OVER OPENCMU            [11-OCT-1994]
  1222. --------------------------------------------
  1223.  
  1224. NOTE: This summary applies to the LATEST version of OpenCMU. There may be minor
  1225. differences applying it to earlier versions.
  1226.  
  1227.  +===========================================================================+
  1228.  | Example of the installation of dec$transport_cmu of OpenCMU V6.6-5A       |
  1229.  +===========================================================================+
  1230.  
  1231. 1.  Copy DECW$TRANSPORT_CMU.exe to sys$common:[syslib]decw$transport_cmu.exe
  1232.    ( Note:  Although the change of $ to _ is required (see 5.3 upgrade and 
  1233.    installation procedures section 10.4, p.10-)7, I didn't do so. But it works)
  1234.  
  1235. 2.  Set protections on the file as -- S:rwed,O:rwed,g:rwed,w:re
  1236.  
  1237. 3.  Add the following record in IP_STARTUP.COM if it is not
  1238.     already there:
  1239.  
  1240.        $ install create sys$share:decw$transport_cmu.exe /open/share/header/prot
  1241.  
  1242. 4.  Customize decw$private_server_setup.com to have the following line:
  1243.  
  1244.        $ decw$server_transports == "DECNET,LOCAL,LAT,CMU"
  1245.  
  1246.     Eg. Copy decw$private_server_setup.template to *.com in Sys$common:[sysmgr]
  1247.         directory and add one record as follows;
  1248.  
  1249.        $do_default: 
  1250.   >>>  $ decw$server_transports == "DECNET,LOCAL,LAT,CMU"
  1251.        $ exit  
  1252.  
  1253. 5.  Reboot workstation. If IP is already setup and running, it should be
  1254.     sufficient to merely restart DECwindows via the following command:
  1255.  
  1256.        $ @sys$manager:decw$startup restart
  1257.  
  1258. 6. Security Entry on VAX/VMS+CMU
  1259.  
  1260.      If you are using VAX/Station(VMS+CMU) and you want to create a window on 
  1261.    the VAX/Station (i.e. you want to use it as a "server"), it is required to 
  1262.    customize security by adding as  "authorized user"  the OpenCMU transport for 
  1263.    the users and machines desired.
  1264.  
  1265.    (Select security in the setup menubar of VAX/Station and add following entry
  1266.       NODE:      IP-address or domain-name  (Eg. 134.160.1.1)
  1267.       USER nam   ? or *                     (Eg. *)
  1268.       Transport: CMU                        (Eg. CMU)
  1269.  
  1270.      If you want use your VAX only as a client or your VAX is not workstation,
  1271.    it is not necessary to define the security entry.
  1272.  
  1273. 6.1  Security entry on UNIX workstation (eg. SUN + X11 Release 4)
  1274.  
  1275.      If you want to communicate with a UNIX workstation running X11R4, it is 
  1276.     also required to define the security entry of the hostname on the UNIX.
  1277.     There are two ways to define the security entry 
  1278.       (1) Write hostname in   /etc/X*.hosts  file. (* is display number)
  1279.       (2) Define hostname by "xhost" command. (this works only in the local
  1280.           terminal. This does not work on the telneted terminal)
  1281.     You can get more information by "man X" and "man xhost" command in UNIX.
  1282.  
  1283.     X11 Release 4 entire kit and its patch are available for anonymous 
  1284.     ftp from expo.lcs.mit.edu in pub/R4 directory 
  1285.  
  1286. 7.  Then you can create a X-window from UNIX or on UNIX
  1287.  
  1288.       Eg. 1 (create a X-terminal on VAX/Station from SUN [SUN OS 4.0.3+X11R4] )
  1289.  
  1290.       (%  xhost  hostname              (authorize hostname, see 6.1))
  1291.        %  setenv DISPLAY hostname:0    (define display)
  1292.        %  xterm &                      (Create a X-terminal of sun on VAX/VMS)
  1293.  
  1294.       Eg. 2  (create a DEC-terminal on SUN from VAX/Station)
  1295.  
  1296.        $ set disp/cre/node="hostname"/tran=CMU
  1297.        $ cre/term/det
  1298.   
  1299.  
  1300. Checking the X server is running:
  1301.  
  1302. (This applies only where the VAX is being used as an X-server. For example, a
  1303. VAXstation). 
  1304.  
  1305. After you bring up the transport with DECWindows, do a NETSTAT to see if the
  1306. transport was initialized to wait for incoming connections.  You should see a
  1307. TCP port at port 6000 in the LISTEN state.  If not, you've done something
  1308. wrong.
  1309.  
  1310.      Example
  1311.  
  1312.       $ IPNCP
  1313.       IPNCP> netstat
  1314.        1 TCP connection found
  1315.        IDX  Address       Local Host    Port    Foreign Host    Port  State
  1316.          2  0004C188         0.0.0.0  23.112         0.0.0.0     0.0  LISTEN
  1317.        0 UDP connections found
  1318.  
  1319.  
  1320.  
  1321. Standardising The SET DISPLAY Command:
  1322.  
  1323. Because there are many different TCP/IP transports available for OpenVMS, of
  1324. which OpenCMU is just one (Multinet, UCX, Wollongong etc. ), there are a number
  1325. of different possibilities for the SET DISPLAY command, since it requires that
  1326. the transport be explicitly specified.
  1327.  
  1328. For UCX, you would require:
  1329.    $ SET DISPLAY /TRANSPORT=TCPIP
  1330.  
  1331. Whereas OpenCMU would require:
  1332.    $ SET DISPLAY /TRANSPORT=CMU
  1333.  
  1334. Thus, writing portable command procedures which set the display is made more
  1335. complex than necessary due to having to determine which of the underlying
  1336. transports is being used before issuing the SET DISPLAY command.
  1337.  
  1338. This can be circumvented very simply, by using a logical name to map a standard
  1339. transport name into the underlying transport compatible one:
  1340.  
  1341.    $ DEFINE /SYSTEM /EXEC DECW$TRANSPORT_TCPIP DECW$TRANSPORT_CMU
  1342.       This allows the user to issue SET DISPLAY /TRANSPORT=TCPIP and have it
  1343.       mapped to the OpenCMU transport. Defining this logical appropriately at
  1344.       system startup means that procedures only ever need to know the standard
  1345.       transport name of 'TCPIP'. Adding the above line to the IP_STARTUP file
  1346.       is recommended.
  1347.                         <HENRYM@SACUSR.MP.USBR.GOV>
  1348.                         <A.Harper@kcl.ac.uk> 
  1349. --------------------------------------------------------------------------------
  1350.  
  1351. 2.8 >>>> HOW TO SET UP ANONYMOUS FTP                [11-OCT-1994]
  1352. ------------------------------------
  1353.  
  1354. Note: following information taken from the FTP client release notes, with minor
  1355. editing to add additional info.
  1356.  
  1357.  
  1358. 2.4.1 RPI Modifications
  1359.  
  1360. 2.4.1.1    V2.7-5, 20-JUN-1989, Madison
  1361.  
  1362. > All FTP_ANON logical names should now be placed in the logical name
  1363.   table FTP_NAME_TABLE, to get them out of the system name table.  To
  1364.   do this, add the following lines to your IP_STARTUP.COM:
  1365.  
  1366.   $ CREATE/NAME_TABLE/EXEC/PROT=(S:RWED,O:RWED,G:R,W:R)-
  1367.         /PARENT=LNM$SYSTEM_DIRECTORY FTP_NAME_TABLE
  1368.   $ FTPDEF := DEFINE/TABLE=FTP_NAME_TABLE/EXEC/NOLOG
  1369.  
  1370.   then use FTPDEF to define the FTP_ANON... logical names, for example:
  1371.  
  1372.   $ FTPDEF FTP_ANONYMOUS_DIRS USER$:[ANONYMOUS...]
  1373.   $ FTPDEF FTP_ANON_LOAD_THRESHOLD "0.5"
  1374.   $ FTPDEF FTP_ANON_PRIME_DAYS "2,3,4"  ! Tuesday, Wednesday, Thursday
  1375.  
  1376. > Added system load checking on anonymous logins if LAV0 device is
  1377.   available.  To enable, define the following logical names in FTP_NAME_TABLE:
  1378.  
  1379.     FTP_ANON_LOAD_THRESHOLD     some floating-point number between 0.0 and 1.0.
  1380.     FTP_ANON_PRIME_DAYS            day-numbers -- indicate "prime time" days
  1381.     FTP_ANON_PRIMETIME_START    time-of-day -- indicates start of "prime time"
  1382.     FTP_ANON_PRIMETIME_END      time-of-day -- indicates end of "prime time"
  1383.     FTP_ANON_TIME_ZONE            any character string indicating local time zone
  1384.  
  1385.   The only required logical is FTP_ANON_LOAD_THRESHOLD.  If that logical name
  1386.   exists and the LAV0 device exists, the load checking code is used.  The
  1387.   code does the following:
  1388.  
  1389.     If FTP_ANON_PRIME_DAYS is defined, it is translated.  The comma-separated
  1390.     list of numbers (where 1=Monday, 2=Tuesday, etc.) is used to identify
  1391.     the days in which "prime time" is effective.  If it does not exist,
  1392.     "prime time" is assumed to be in effect Monday through Friday.
  1393.     Note: Use ONLY numbers 1 through 7, and NO SPACES in the string.  Surround
  1394.     the string with quotation marks when defining!
  1395.  
  1396.     If FTP_ANON_PRIMETIME_START is defined, it is translated and converted
  1397.     into a system date-time value using LIB$CONVERT_DATE_STRING.  If not,
  1398.     then 09:00 is used as the start of "prime time".
  1399.  
  1400.     If FTP_ANON_PRIMETIME_END is defined, it is translated and converted
  1401.     into a system date-time value using LIB$CONVERT_DATE_STRING.  If not,
  1402.     then 17:00 is used as the end of "prime time".
  1403.  
  1404.     If the current time is between the prime-time start and end times,
  1405.     then the current load averages are read from the LAV device.  The
  1406.     current load is computed using the following formula:
  1407.                     load = M15 * (P15 / 4.0)
  1408.     where M15 is the average load over the last 15 minutes, and P15 is
  1409.     the average priority over the last 15 minutes.  Thus, the average load
  1410.     is normalized against typical interactive priority to guard against
  1411.     low-priority batch jobs preventing guest login access.
  1412.  
  1413.     If the load is greater than or equal to the LOAD_THRESHOLD value, then
  1414.     the guest login is denied with a reason of "system too busy".
  1415.     If the threshold is not exceeded, then the guest login is accepted, but
  1416.     the user is warned to minimize access during prime time (with the
  1417.     start and end times displayed along with the time zone information
  1418.     [if FTP_ANON_TIME_ZONE is defined]).
  1419.  
  1420.     If the current time does not fall within prime time, no load checking
  1421.     is performed.
  1422.  
  1423. 2.4.1.2   V2.7-4, 09-JUN-1989, Madison
  1424.  
  1425. > Added special messages to FTP server during guest (anonymous) login.
  1426.   Modified the logging of anonymous sessions slightly.
  1427.  
  1428. 2.4.1.3   V2.7-2, 03-APR-1989, Madison
  1429.  
  1430. > The FTP server presents a somewhat more informative banner on connection--
  1431.   includes system name and version of FTP.
  1432.  
  1433. > The code that handled directory changes was really ugly, even though
  1434.   it had been modified to fix the infinite-loop problem from V2.6.  I
  1435.   replaced the code with some which makes use of available VMS system
  1436.   services, simply to satisfy my own sense of aesthetics.
  1437.  
  1438. > Enhanced the Anonymous FTP support provided by OpenCMU.  The enhancements
  1439.   include:
  1440.  
  1441.     * ANONYMOUS is never allowed privileges regardless of the contents of
  1442.       its UAF record.
  1443.  
  1444.     * All ANONYMOUS FTP sessions create logs.  Each session creates a
  1445.       file SYS$MANAGER:ANON_FTP_LOG.LOG.  You can put them elsewhere by
  1446.       defining ANON_FTP_LOG system-wide to a different location.  The
  1447.       password given to ANONYMOUS is logged along with the remote host's
  1448.       name and address, as well as RETR, LIST, NLST, CWD, and CDUP commands.
  1449.       The log files need not be accessible to the ANONYMOUS userid (and
  1450.       probably should not be).
  1451.  
  1452.       NOTE: It appears that the anonymous log file is ONLY created in
  1453.       SYS$MANAGER if the ANON_FTP_LOG logical name is explicitly defined. By
  1454.       default, no log file gets created.  Use:
  1455.  
  1456.     $ define/system ANON_FTP_LOG sys$manager:ANON_FTP_LOG.LOG
  1457.          
  1458.     * You can restrict the directories to which ANONYMOUS has access by
  1459.       defining the system-wide logical name FTP_ANONYMOUS_DIRS to
  1460.       a search list of device/directory specifications.  Any RETR,
  1461.       LIST, or NLST will check against this list before going through normal
  1462.       system access checks.  This prevents ANONYMOUS from gaining access
  1463.       to people's files via WORLD access.  If you do not define
  1464.       FTP_ANONYMOUS_DIRS, the extra access checks do not take place.
  1465.       You can use [directory...] notation to allow access to the entire
  1466.       subdirectory tree below the specified directory.
  1467.  
  1468. The steps needed to set up a controlled Anonymous FTP are:
  1469.  
  1470.     1. Create a UAF record for ANONYMOUS.  Set it /NOINTER/NOBATCH/NONETWORK
  1471.        to prevent logins or DECnet use.  Set /FLAG=DISMAIL to prevent mail
  1472.        from reaching it.  Assign it a UIC that is unique and outside any
  1473.        existing group.  Give it a default device and directory.
  1474.  
  1475. Example: UAF> ADD ANONYMOUS/PASS=JUNK/NOINTERACTIVE/NOBATCH/NONETWORK-
  1476.                 /FLAG=DISMAIL/UIC=[666,666]/DEV=USER$DISK/DIR=[PUBLIC]
  1477.  
  1478.     2. Put the definition of FTP_ANONYMOUS_DIRS in your system startup
  1479.        sequence.  Make sure it is defined before allowing Anonymous access.
  1480.        Make sure that the default device/directory in the UAF is accessible
  1481.        (not strictly necessary, but easier on the users).
  1482.  
  1483. Example: $ DEFINE/SYSTEM FTP_ANONYMOUS_DIRS -
  1484.                 USER$DISK:[PUBLIC...],-        ! public files
  1485.                 USER$DISK:[NEWS...],-        ! news archives
  1486.                 USER$DISK:[MAIL]            ! mail archives
  1487.  
  1488.     3. Create the directories to which ANONYMOUS will have access.  Do not
  1489.        permit ANONYMOUS to own any of the files or be in the same group
  1490.        as the owner of the files.  Set WORLD:R protection on all files
  1491.        and directories to be accessible, or use an ACL to grant access 
  1492.        specifically to ANONYMOUS.
  1493.  
  1494.   While these modifications were meant to enhance the security of Anonymous FTP,
  1495.   neither the author nor his employer (nor anyone else for that matter)
  1496.   guarantees that the software is secure.
  1497.                         <HENRYM @ SACUSR.MP.USBR.GOV>
  1498.  
  1499.  
  1500.  
  1501. Availability:
  1502.     ftp://ftp.kcl.ac.uk/default/lavdriver.*
  1503.  
  1504. --------------------------------------------------------------------------------
  1505.  
  1506. 2.9 >>>> SETTING UP OPENCMU WITH OPENVMS 6.x        [24-AUG-1995]
  1507. --------------------------------------------
  1508.  
  1509. If OpenCMU is already installed and you are upgrading from OpenVMS 5.x to
  1510. OpenVMS 6.x, or OpenCMU is being installed for the first time onto an OpenVMS
  1511. 6.x system, then some special steps need to be taken after the installation of
  1512. the base OpenCMU kit in order that it will run correctly:
  1513.  
  1514. OpenCMU works with OpenVMS 6.0, 6.1 and 6.2.
  1515.  
  1516.  
  1517. * Register OpenCMU images:
  1518.   OpenVMS 6.1 allows pre-version 6 drivers to run if the new image
  1519.   registration utility is used on them. Failure to register will result in
  1520.   the network failing to start with messages like 'System version level
  1521.   mismatch'. The following commands may be used:
  1522.  
  1523.     $ register == "@sys$update:register_privileged_image register"
  1524.     $ register cmuip_root:[sys$ldr]ipdriver.exe
  1525.     $ register cmuip_root:[sysexe]ipacp.exe
  1526.     $ register cmuip_root:[sysexe]lpd.exe
  1527.  
  1528.  
  1529. * Install OpenVMS 6.x patch kit:
  1530.   Under OpenVMS 6.x, a new password hashing scheme was introduced. The
  1531.   FTP_SERVER image does not understand the new method so that users who
  1532.   change their password under OpenVMS 6.x cannot subsequently login to the
  1533.   FTP server. The FTP_SERVER replacement fixes this. Some Version 6 specific
  1534.   drivers are also available:
  1535.  
  1536.     FTP_SERVER.SAVE    OpenVMS 6 version, with fixed password hashing
  1537.     V6DRIVER.SAVE    OpenVMS 6 versions of IPDRIVER, PNDRIVER, TZDRIVER
  1538.  
  1539.  
  1540.  
  1541. * Install OpenVMS 6.1 patch kit:
  1542.     IPACP.EXE    New version (6.7) linked against OpenVMS 6.1
  1543.  
  1544.   This version appears to be troublesome on some systems. If it causes problems
  1545.   then fall back to the version supplied in the TEKIP0665.A patch kit.
  1546.  
  1547.   Do not install this if running OpenVMS 6.0; it is for OpenVMS 6.1 and above
  1548.   only.
  1549.  
  1550.  
  1551.  
  1552. * Reboot system:
  1553.   Once all appropriate patches have been applied, the system MUST be rebooted
  1554.   in order that the new drivers can be loaded. Failure to do this will result
  1555.   in the old drivers remaining loaded and the patches not taking effect.
  1556.  
  1557. These patch kits are available via ftp from the sources named elsewhere in
  1558. this document.
  1559.                         <A.Harper@kcl.ac.uk>
  1560.                         <Rynda@scfe.chinalake.navy.mil>
  1561.                         <henrym@sacto.mp.usbr.gov>
  1562.                         <srshmgr@m2g.gns.cri.nz>
  1563.  
  1564. --------------------------------------------------------------------------------
  1565.  
  1566. 2.10 >>>> HOW TO SET UP RESTRICTIONS ON NETWORK ACCESS        [14-JUL-1995]
  1567. -----------------------------------------------------
  1568.  
  1569. Security Options
  1570.  
  1571. The OpenCMU software provides a number of mechanisms for restricting access to
  1572. the network from the local host. These restrictions apply to ANY type of
  1573. outgoing connection:
  1574.  
  1575.    *  NETMBX privilege for access to the network
  1576.  
  1577.    *  PHY_IO privilege [optionally] required to open local well known ports
  1578.  
  1579.    *  INTERNET_ACCESS identifier [optionally] required to connect to any
  1580.       network host
  1581.  
  1582.    *  ARPANET_ACCESS identifier [optionally] required to connect to any
  1583.       non-local network host. Which hosts are considered 'local' can be
  1584.       separately defined.
  1585.  
  1586.  
  1587. NETMBX Privilege
  1588.  
  1589. Being a network product, naturally OpenCMU requires that users have the NETMBX
  1590. privilege to use it. This is normally granted to users as it is typically not
  1591. dangerous (some sites may disagree though).  Alternatively, it is possible to
  1592. INSTALL selected applications with NETMBX privilege and allow all users to run
  1593. selected applications.
  1594.  
  1595.  
  1596. Configuration of Optional Security Mechanisms
  1597.  
  1598. The INET$CONFIG file defines further access restrictions that can be used. Of
  1599. these the first, and most important, is the ACCESS_FLAGS variable, defined
  1600. thus:
  1601.  
  1602.    VARIABLE:ACCESS_FLAGS:nnnn
  1603.  
  1604.  
  1605. where 'nnn' is a bitmask expressed as an integer value. Different security
  1606. measures are assigned to each bit. To determine the value, add together the
  1607. appropriate numbers from this list:
  1608.  
  1609.    1    If you require users to have PHY_IO privilege to open local well
  1610.     known ports. This option prevents non privileged users from setting up
  1611.     listeners on standard ports, such as FTP, TELNET or SMTP, and
  1612.     subverting such services.
  1613.  
  1614.    2    If you require users to possess the identifier ARPANET_ACCESS to talk
  1615.     to non-local hosts (see the LOCAL_HOST definition below). May be useful
  1616.     if you are charged for off-site access
  1617.  
  1618.    4    If you require users to possess the identifier INTERNET_ACCESS to talk
  1619.     to any host on the network.
  1620.  
  1621. Examples:
  1622.  
  1623.    VARIABLE:ACCESS_FLAGS:1
  1624.     Require PHY_IO privilege for well known ports; no other restrictions
  1625.     placed on where users can connect.
  1626.  
  1627.     This is the usual value for a site placing no major restrictions on
  1628.     users.
  1629.  
  1630.    VARIABLE:ACCESS_FLAGS:3
  1631.     As above, but also requires user to possess the ARPANET_ACCESS
  1632.     identifier when connecting to a non-local host (see LOCAL_HOST
  1633.     definition below)
  1634.  
  1635.     This is the usual value for a site that doesn't mind users accessing
  1636.     other internal systems but does not want uncontrolled access to the
  1637.     whole of the internet (which may incur costs).
  1638.  
  1639.  
  1640.    VARIABLE:ACCESS_FLAGS:7
  1641.     As above, but also requires user to possess the INTERNET_ACCESS
  1642.     identifier in order to connect to ANY host.
  1643.  
  1644.  
  1645.  
  1646. Local Hosts
  1647.  
  1648. With the appropriate value of ACCESS_FLAGS, access to non-local hosts can be
  1649. restricted to those possessing the ARPANET_ACCESS identifier. But what is a
  1650. 'Local Host'?
  1651.  
  1652. Hosts can be defined as 'local' (and hence accessible WITHOUT possession of the
  1653. ARPANET_ACCESS identifier) using the LOCAL_HOST configuration record in
  1654. INET$CONFIG:
  1655.  
  1656.   General form is:
  1657.       LOCAL_HOST:address:address-mask
  1658.  
  1659.   where:
  1660.       LOCAL_HOST    is the required keyword
  1661.       address        is the address of the networks/hosts to be local
  1662.       address-mask    is the mask to determine which subset of 'address'
  1663.             is to be local
  1664.  
  1665.   Examples:
  1666.       LOCAL_HOST:123.45.0.0:255.255.0.0
  1667.  
  1668.     * Defines addresses 123.45.0.0 through 123.45.255.255 as local, and
  1669.       accessible without possession of ARPANET_ACCESS
  1670.  
  1671.  
  1672.       LOCAL_HOST:120.67.3.1:255.255.255.255
  1673.  
  1674.     * Defines the specific address 120.67.3.1 as local, and accessible
  1675.       without possession of ARPANET_ACCESS.
  1676.  
  1677.  
  1678.       LOCAL_HOST:0.0.0.0:0.0.0.0
  1679.  
  1680.     * Defines all addresses as local
  1681.  
  1682.  
  1683. There can be as many LOCAL_HOST definitions as required. Note that they are
  1684. only relevant if the ACCESS_FLAGS variable contains the appropriate setting.
  1685.  
  1686.  
  1687. Creating and Granting Identifiers
  1688.  
  1689. If flags 2 or 4 are set, then the corresponding identifiers MUST exist. If
  1690. they do not, a warning will be issued when the IP network is started and the
  1691. corresponding flag settings will be ignored. To create them:
  1692.  
  1693.    $ set def sys$system:
  1694.    $ mc authorize
  1695.      add/identifier INTERNET_ACCESS
  1696.      add/identifier ARPANET_ACCESS
  1697.  
  1698. To grant the identifiers to a user (actually to a UIC):
  1699.  
  1700.    $ set def sys$system:
  1701.    $ mc authorize
  1702.      grant/identifier INTERNET_ACCESS username
  1703.      grant/identifier ARPANET_ACCESS  username
  1704.  
  1705. To remove the identifiers from a user:
  1706.  
  1707.    $ set def sys$system:
  1708.    $ mc authorize
  1709.      revoke/identifier INTERNET_ACCESS username
  1710.      revoke/identifier ARPANET_ACCESS  username
  1711.                             <A.Harper@kcl.ac.uk>
  1712.  
  1713. --------------------------------------------------------------------------------
  1714.  
  1715. 2.11 >>>> NOTES ON TCP TUNING                    [14-JUL-1995]
  1716. -----------------------------
  1717.  
  1718. For optimum performance, the OpenCMU software should be 'tuned' to match the
  1719. settings of the network to which it is connected.
  1720.  
  1721. This article is taking from the 'alt.winsock' newsgroup and relates primarily
  1722. to the configuration of PCs. However the information applies to other systems
  1723. too, OpenCMU included.
  1724.  
  1725. For MTU, substitute the OpenCMU configuration variable MAX_TCP_DATASIZE.
  1726. For MSS, substitute the OpenCMU configuration variable DEFAULT_MSS.
  1727. For RWIN, there is no configurable setting in OpenCMU (at least, not a
  1728. documented one).
  1729.  
  1730.  
  1731.                    MTU, MSS and RWIN settings:
  1732.  
  1733. The size of packets which a particular Internet access provider's 
  1734. network likes to use can vary greatly. Ideally, in direct downloads, 
  1735. your Maximum (data) Segment Size should match the network to which 
  1736. you are connected through your PPP or SLIP dial-up connection. The 
  1737. size of header added to the "datagram" is usually 40 bytes (20 bytes 
  1738. for TCP and 20 bytes for IP), yielding a Maximum Transmission Unit 
  1739. of MSS+40.
  1740.  
  1741. One of my providers (UltraNet) gives me access via PPP to an EtherNet-
  1742. based network, which likes MTU=1500 (i.e. MSS=1460). The other (NetCom) 
  1743. gives me access via Compressed SLIP (CSLIP) to a system which likes 
  1744. MSS=512 (i.e MTU=552).
  1745.  
  1746. However, most of us like to get downloads from machines on other 
  1747. networks, which we reach through several intermediate networks along 
  1748. the Internet. If I request a 1500 byte packet (or stream of them) 
  1749. from a remote Ethernet, chances are the 1500-byte packets will have 
  1750. to be relayed through one of these intermediaries. 
  1751.  
  1752. In my case, most of the time when I enable Trumpet WinSock's TCP Trace, 
  1753. I will see my MTU=1500 PPP provider sending me a stream of 536-byte 
  1754. data segments in one of these long-distance downloads. (This is a kind 
  1755. of default size which all TCP/IP servers are supposed to be able to use, 
  1756. regardless of whatever other size they offer.) These same downloads 
  1757. through my CSLIP provider come (unsurprisingly) as 512-byte streams 
  1758. through his 512-byte "funnel". 
  1759.  
  1760. Obviously, I use MSS=512 (MTU=552) with NetCom on CSLIP, because they 
  1761. can't send me anything bigger. (If I insist, I'll get each 536-byte 
  1762. data segment broken into two packet fragments - 512 and 24, each with 
  1763. its own 40-byte header and "acknowledge" signal back from my machine -
  1764. not very fast.)
  1765.  
  1766. However, I use MSS=536 (MTU=576) with UltraNet on PPP, because most of 
  1767. the time I'm not getting downloads *from* them (MTU=1500), but just 
  1768. *through* them. If I request a 1460-byte data segment, UltraNet will 
  1769. happily pass-on my request. Usually, it results in two 536-byte 
  1770. segments and a 388-byte segment, each transmitted with a 40-byte 
  1771. header after awaiting my machine's "acknowledgement of receipt" of the 
  1772. last one. (Sometimes, two 512's and a 436; and there are old machines 
  1773. out there on the 'net which like even smaller datagrams!)
  1774.  
  1775. This is an old problem. In the days of ARPANet, the maximum packet 
  1776. size was only two-thirds the size of the Ethernet maximum. With the 
  1777. diversity of networks now populating the Internet, it's gotten even 
  1778. worse. (I believe, for instance, that NetBIOS-based systems like MSSs 
  1779. that are multiples of 32 bytes.)
  1780.  
  1781. So, in summary, your "optimum" MSS/MTU settings depend on your IP (can't 
  1782. be bigger than his) and on *the smallest MTU* of all the machines on 
  1783. the particular path through the Internet taken by the particular down-
  1784. load you request. (Big help, right?)
  1785.  
  1786. RWIN ("Receive WINdow") is nothing more than the buffer your machine 
  1787. waits to fill before attending to whatever other TCP/IP transactions 
  1788. (like mail) are occurring on other "threads" through the multiple 
  1789. logical "sockets" your WinSock has open while your download is in 
  1790. progress. 
  1791.  
  1792. Since your download packets may be coming a long (electrical) 
  1793. distance, that trip-delay should be less than your RWIN-filling time 
  1794. at the speed the packets are coming in, or you won't "keep the pipe 
  1795. full" for maximum throughput. If RWIN is too large, however, the 
  1796. latency time your other threads experience may be intollerable. 
  1797. (This is especially true if you have 2 or 3 windows open in Netscape 
  1798. and have multiple downloads occuring in the background while you're 
  1799. "surfing" -your "surfing" may show annoyingly long response times.)
  1800.  
  1801. Most people seem to find RWIN of 3-to-4 MSSs a good compromise. If 
  1802. all you do is large file downloads, RWINs of 8 or even 10 times MSS 
  1803. will yield slightly better throughput, but slightly poorer response 
  1804. delays if you try to ask anything else from the 'net while the 
  1805. download is in progress. 
  1806.  
  1807. After all this, if you want a good (but not "optimal") set of numbers, 
  1808. I'd suggest either:
  1809.  
  1810.           (1) MSS=536/MTU=576 and RWIN=2144 or 4288;
  1811.  
  1812. or, if your Internet Provider has MSS=512,
  1813.  
  1814.           (2) MSS=512/MTU=552 and RWIN=2048 or 4096.
  1815.  
  1816. [If your IP's MSS is even smaller, use it and MTU=MSS+40, with RWIN=4*MSS 
  1817.     -  I'd change providers, if possible.]
  1818.  
  1819.  
  1820. IN SUMMARY:
  1821.  
  1822. Use TCP Trace to tune your settings for the size datagrams that appear in 
  1823. the downloads from the sites you access most often. (The path they follow 
  1824. will vary, of course, but this is generally as close as you can come to 
  1825. an "optimum" setting to avoid fragmentation of your requested packet 
  1826. sizes into sizes that intermediaries on the 'net can handle.)
  1827.  
  1828. I've generally found that if your provider can handle MTU=576/MSS=536, 
  1829. most transfers will move right along without the slow-down effects of 
  1830. packet fragmentation. If he can only handle 552/512, that's still pretty 
  1831. good. For example, my 28.8Kbps modem connections run at 3.2Kbytes/sec 
  1832. with MSS=536 PPP, and 3.1Kbytes/sec with MSS=512 CSLIP for binary or 
  1833. compressed files. (The fastest *direct* downloads from an Ethernet host 
  1834. will occur with MTU=1500, of course.)
  1835.  
  1836. (Note:If you're downloading over transoceanic telephone links, you may be 
  1837. limited by their throughput. For this reason, my downloads from Australia 
  1838. and, especially Scandanavia, are much slower than those from within North 
  1839. America, where I'm located).
  1840.  
  1841. Your mileage may vary ;-)
  1842.  
  1843.         With thanks to: "Albert P. Belle Isle" <belleisl@ultranet.com>
  1844.  
  1845. --------------------------------------------------------------------------------
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851. 3.0 KNOWN PROBLEMS
  1852. ------------------
  1853.  
  1854. This section lists known problems with the current base release that are either
  1855. outstanding or fixed by one or more of the patch kits.
  1856.  
  1857. --------------------------------------------------------------------------------
  1858.  
  1859. 3.1 >>>> IPACP                            [13-JUL-1995]
  1860. --------------
  1861.  
  1862. The IPACP process coordinates all IP traffic. It also includes a built in
  1863. ethernet driver and telnet server.
  1864.  
  1865.  
  1866.  
  1867. 3.1.1 >>>> IPACP ISSUES STATUS CODES TO OPCOM            [11-OCT-1994]
  1868.  
  1869. When the IPACP process (which coordinates the IP traffic) has problems, it can
  1870. issue system status codes to OPCOM. Here is a typical sequence:
  1871.  
  1872.    %%%%%%%%%%%  OPCOM  16-AUG-1993 10:49:23.75  %%%%%%%%%%%
  1873.    Message from user SYSTEM on XYZZY
  1874.    IPACP: XE status error.  Status = 00000A00
  1875.  
  1876.    %%%%%%%%%%%  OPCOM  16-AUG-1993 10:49:23.83  %%%%%%%%%%%
  1877.    Message from user SYSTEM on XYZZY
  1878.    IPACP: XE retried 5 times.
  1879.  
  1880.    %%%%%%%%%%%  OPCOM  16-AUG-1993 10:49:23.89  %%%%%%%%%%%
  1881.    Message from user SYSTEM on XYZZY
  1882.    IPACP: XE $QIO read error (dev_inact), RC=000020D4
  1883.  
  1884.  
  1885. To determine the exact problem, it is first necessary to translate the status
  1886. codes (00000A00  and  000020D4) into the more usual text form. The DCL lexical
  1887. function F$MESSAGE will translate them for you.  Here is a little command file
  1888. to make it easier:
  1889.  
  1890.  
  1891.    $! SHOWMSG.COM
  1892.    $! Usage: @SHOWMSG 20D4
  1893.    $    WRITE SYS$OUTPUT F$MESSAGE(%X'P1')
  1894.  
  1895.  
  1896. Typically, the messages are indicative of a problem with the ethernet itself or
  1897. with the ethernet controller; the status messages may help to determine the
  1898. root cause.
  1899.  
  1900. The message texts from OpenCMU are not part of the standard system message
  1901. files. For a translation of the error code into the text to be possible, the
  1902. user must have issued a SET MESSAGE command on the file  NETERROR.EXE.  The
  1903. installation of OpenCMU should have placed this in the SYS$MESSAGE directory.
  1904.  
  1905. If not, locate the file called NETERROR.OBJ in the CMUIP_ROOT:[*...] tree and
  1906. relink it to form the NETERROR.EXE, using this command:
  1907.  
  1908.    $ LINK/SHARE=SYS$COMMON:[SYSMSG]NETERROR NETERROR.OBJ
  1909.  
  1910.  
  1911. Following this, the message texts can be made available to F$MESSAGE using:
  1912.  
  1913.    $ SET MESSAGE SYS$MESSAGE:NETERROR
  1914.  
  1915. [Note: if, for any reason, NETERROR.OBJ does not exist in the directory tree, 
  1916. it can be found in the second saveset of the OpenCMU kit - CMUIP066.B]
  1917.                             <dragon@nscvax.princeton.edu>
  1918.                             <A.Harper@kcl.ac.uk>
  1919.  
  1920.  
  1921. 3.1.2 >>>> IPACP CRASH DUE TO QUOTA EXCEEDED            [20-MAR-1995]
  1922.  
  1923. For systems with a high IP load, IPACP may occasionally crash with a quota
  1924. exceeded. This does not refer to disk quota, but to one of the process quota
  1925. limits. Usually, the quota in question is BYTLM.
  1926.  
  1927. The default BYTLM provided for IPACP (65536) is sufficient for only about 20
  1928. connections. IPACP takes about 32000 for itself and each connection takes about
  1929. 1872 bytes. This requirement is NOT currently documented.
  1930.  
  1931. To increase the BYTLM for the IPACP, modify the IP_STARTUP.COM procedure and
  1932. change the value of the /BUFFER_LIMIT qualifier on the RUN command that starts
  1933. the IPACP process. Then shut down and restart IPACP.
  1934.  
  1935. At the current time, there also appears to be a memory leak in IPACP which has
  1936. the effect of gradually reducing the available BYTLM over time. When this gets
  1937. close to zero, IPACP will hang (as it retries) and then crash soon afterwards.
  1938. It is therefore desirable to give IPACP more BYTLM than the typical load might
  1939. suggest. If this sort of crash is experienced, increase the BYTLM by 50% and
  1940. restart it.
  1941.                             <A.Harper@kcl.ac.uk>
  1942.  
  1943.  
  1944.  
  1945. 3.1.3 >>>> IPACP CRASHES WITH DIVIDE BY ZERO ERROR        [15-AUG-1995]
  1946.  
  1947.  
  1948. On some systems, the IPACP supplied in the V6DRIVER.SAVE patch kit can cause
  1949. divide by zero problems when running OpenCMU on OpenVMS 6.1. If this happens,
  1950. return to the IPACP.EXE image supplied in the TEKIP0665A.SAVE patch kit.
  1951.  
  1952. The erroneous version identifies itself as version 6.7.
  1953.  
  1954.                             <A.Harper@kcl.ac.uk>
  1955.  
  1956. --------------------------------------------------------------------------------
  1957.  
  1958. 3.2 >>>> NAMRES                            [13-JUL-1995]
  1959. ---------------
  1960.  
  1961. NAMRES is the DNS Name Resolver, responsible for translating system names into
  1962. IP addresses, and vice versa. If not running, use of domain names is not
  1963. possible though use of IP addresses ought to continue to work.
  1964.  
  1965.  
  1966. 3.2.1 >>>> NAMRES GIVES DOMAIN REFERRAL EXCEEDED MESSAGES    [11-OCT-1994]
  1967.  
  1968. The name resolver can produce the message `Maximum domain referral limit
  1969. exceeded' and fail to resolve a name into its address. This is often indicative
  1970. of incorrect configuration of the name resolver.  Ensure that the following
  1971. lines are included in the NAMRES$CONFIG file:
  1972.  
  1973.    Variable:TIMEOUT:5
  1974.    Variable:REFMAX:10
  1975.    Variable:RECURSE:1
  1976.  
  1977. You might also want to add:
  1978.  
  1979.    Variable:NS_RETRANS:2
  1980.  
  1981.  
  1982. (NOTE: in table 3-8 of the last official manual, the last variable, labelled
  1983. TIMEOUT, should be labelled RECURSE. TIMEOUT is given correctly as the second
  1984. entry in the table).
  1985.  
  1986. Restart the name resolver if necessary:
  1987.  
  1988.    $ IPNCP
  1989.    IPNCP> NAMRES EXIT
  1990.    ....
  1991.    IPNCP> STARTUP /NAMRES
  1992.                             <A.Harper@kcl.ac.uk>
  1993.  
  1994.  
  1995. 3.2.2 >>>> NAMRES HANGS IN RWAST                [12-JUL-1995]
  1996.  
  1997. After some time, the NAMRES process can hang in an RWAST state, preventing
  1998. further name resolutions from taking place.  This is a bug in the current
  1999. version and no fix is currently available.  Processes in an RWAST state cannot
  2000. be killed so stopping and restarting the NAMRES process is not possible by
  2001. standard means.
  2002.  
  2003. However, a number of workarounds may be possible:
  2004.  
  2005.   *  Change the process name and restart NAMRES
  2006.         $ SET PROCESS/ID=xxxx/NAME=OLDNAMRES
  2007.         $ IPNCP STARTUP/NAMRES
  2008.  
  2009.   *  Start up NAMRES under a privileged username different from that normally
  2010.      used.
  2011.  
  2012.   *  Reboot the system.
  2013.  
  2014. The last is the only recommended way to completely clear a hung 'RWAST'
  2015. process.
  2016.                             <A.Harper@kcl.ac.uk>
  2017.  
  2018. --------------------------------------------------------------------------------
  2019.  
  2020. 3.3 >>>> NFS                            [13-JUL-1995]
  2021. ------------
  2022.  
  2023. The NFS server allows directory hierarchies to be made accessible over the
  2024. network, such that they can be 'mounted' as a disk on another system. There is
  2025. no NFS client to allow local mounting of remote disks.
  2026.  
  2027.  
  2028. 3.3.1 >>>> WHY DOESN'T THE NFS SERVER WORK            [11-OCT-1994]
  2029.  
  2030. The NFS server broke with version 6.6-5 of OpenCMU.  At this time, there is no
  2031. workable solution. IF NFS is a requirement, version 6.6-4 is the last version
  2032. in which NFS works.
  2033.                             <A.Harper@kcl.ac.uk>
  2034.  
  2035. --------------------------------------------------------------------------------
  2036.  
  2037. 3.4 >>>> FTP                            [13-JUL-1995]
  2038. ------------
  2039.  
  2040. FTP provides file tranfer capabilities. The FTP server allows remote users to
  2041. connect and transfer files. The FTP client allows local users to access remote
  2042. systems.
  2043.  
  2044.  
  2045. 3.4.1 >>>> WHY IS FTP SO SLOW                    [11-OCT-1994]
  2046.  
  2047. The version of FTP supplied with the master 6.6-5 kit suffers from a number of
  2048. bugs. One of these causes excessive error rates and retransmissions resulting
  2049. in a low throughput rate.
  2050.  
  2051. It is STRONGLY recommended that the 6.6-5A patch kit be applied. This greatly
  2052. improves the performance.
  2053.  
  2054. See also the freeware MGFTP software (described in more detail in the
  2055. `Software' section elsewhere).
  2056.                             <A.Harper@kcl.ac.uk>
  2057.  
  2058.  
  2059. 3.4.2 >>>> WHY DOES FTP CRASH WITH `EXCEEDED QUOTA'        [11-OCT-1994]
  2060.  
  2061. FTP (client or server) can fall over with an `exceeded quota' message if the
  2062. SYSGEN parameter `MAXBUF' is not set correctly.  The latest recommendation is
  2063. for the minimum value to be 8192.
  2064.  
  2065. Note that transferring files with large records, exceeding MAXBUF, may still
  2066. cause problems.
  2067.                             <A.Harper@kcl.ac.uk>
  2068.  
  2069.  
  2070. 3.4.3 >>>> FTP OF BACKUP SAVESETS GIVES CRC ERRORS        [11-OCT-1994]
  2071.  
  2072. One major use of FTP is in transferring BACKUP savesets to/from other systems.
  2073. Often this leads to the recipient having difficulties unpacking that saveset;
  2074. in particular, using BACKUP to list or unpack it results in a stream of
  2075. messages similar to `CRC error' to the user's terminal and to OPCOM. This
  2076. article summarizes why the error occurs and how to correct it.
  2077.  
  2078. When BACKUP creates a saveset, it writes the file with a fixed length record
  2079. format - the length being that specified with BACKUP's /BLOCK qualifier. For
  2080. example:
  2081.  
  2082.     BACKUP/BLOCK=8192 * s.bck/save
  2083.          Creates a file with fixed length records of 8192.
  2084.  
  2085. When FTP is used, in binary mode, the data is sent correctly but the record
  2086. structure changes; typically, it is created with 512 byte records. Thus, when
  2087. BACKUP is used to list or unpack the file contents, it finds that the record
  2088. length of the file does not match the size used originally (this value is
  2089. stored in the BACKUP saveset header as well as in the file header).
  2090.  
  2091. If both ends of the FTP session support the special STRUC VMS mode of transfer,
  2092. then it should be used and the file will transfer correctly. If this structure
  2093. is not supported, the record structure becomes corrupted and must be manually
  2094. `fixed up' before BACKUP can be used.
  2095.  
  2096. There are three ways in which this can be done. Note that, in each case, the
  2097. technique will work ONLY  if the file has been transferred in binary mode ftp.
  2098. If the file format has been corrupted by ANY other means (such as kermit, or a
  2099. pathworks file copy) then the techniques will need to be modified
  2100. appropriately.
  2101.  
  2102.  1.    Use the VMS CONVERT utility to alter the record structure:
  2103.  
  2104.        $ CONVERT/FDL=SYS$INPUT  file.bck  file.bck
  2105.        RECORD
  2106.          FORMAT FIXED
  2107.              SIZE nnnn
  2108.        ^Z
  2109.  
  2110.     Where 'nnn' is the record size used on the original BACKUP command.
  2111.  
  2112.     NOTE: a new copy of the file is made.
  2113.  
  2114.  
  2115.  2.    Use the public domain utility called FILE (courtesy of Joe Meadows):
  2116.  
  2117.        $ FILE/RECORD_SIZE=nnn file.bck
  2118.  
  2119.     Where 'nnn' is the record size used on the original BACKUP command.
  2120.  
  2121.     NOTE: this utility does NOT make a copy of the file; instead it patches
  2122.     the file header directly. It is wise to make a backup copy before using
  2123.     this technique!!!
  2124.  
  2125.  
  2126.  
  2127. 3.    Use the public domain utility called FIX_SAVESET (author unknown):
  2128.  
  2129.        $ FIX_SAVESET file.bck
  2130.  
  2131.     This utility scans the file, on the assumption that it is a backup
  2132.     saveset; picks out the original record length from the backup saveset
  2133.     header stored in the file; and finally, patches the file header record
  2134.     size back to this length. A new copy of the file is not made.
  2135.  
  2136.  
  2137. Summary:
  2138.  
  2139. To summarize the correct method of transferring a BACKUP saveset using FTP:
  2140.  
  2141.   1.    If both ends support STRUC VMS, then
  2142.       a.    ftp> SET STRUC VMS
  2143.       b.    ftp> GET file
  2144.  
  2145.     File will be stored locally with the correct attributes.
  2146.  
  2147.   2.    If STRUC VMS is not supported by one or both ends, then
  2148.       a.    ftp> BINARY
  2149.       b.    ftp> GET file
  2150.  
  2151.     Once file arrives on the VMS system:
  2152.       c.    FIX_SAVESET file
  2153.                             <A.Harper@kcl.ac.uk>
  2154.  
  2155.  
  2156. Availability:
  2157.    ftp://ftp.kcl.ac.uk/default/fix_saveset.*
  2158.    ftP://ftp.kcl.ac.uk/joemeadows/file.*
  2159.  
  2160. NOTE:  These items are available in source form only and require a C compiler.
  2161.  
  2162.  
  2163.  
  2164. 3.4.4 >>>> CANNOT LOGIN TO FTP SERVER AFTER UPGRADE TO OPENVMS 6.0 [20-JAN-1995]
  2165.  
  2166. Following an upgrade to OpenVMS 6.0, users cannot log in to the FTP server once
  2167. they have changed their password!. This is because the password hashing
  2168. algorithm is updated in OpenVMS 6.0 and all new passwords use the new hashing
  2169. algorithm. The existing FTP_SERVER does not know about the new one and
  2170. consequently cannot hash correctly, causing a password mismatch.
  2171.  
  2172. An updated FTP_SERVER is available. This will run on all version of VMS from
  2173. 5.4 upwards.
  2174.  
  2175. Alternatively, install MadGoat FTP (see software section elsewhere in this
  2176. document).
  2177.                             <A.Harper@kcl.ac.uk>
  2178.  
  2179. --------------------------------------------------------------------------------
  2180.  
  2181. 3.5 >>>> TELNET                            [13-JUL-1995]
  2182. ---------------
  2183.  
  2184. TELNET allows interactive use. The telnet server, built into the IPACP, allows
  2185. remote users to access the local system. The telnet client allows local users
  2186. to access remote systems interactively.
  2187.  
  2188.  
  2189.  
  2190. 3.5.1 >>>> WHY DOES TELNET SOMETIMES HANG IN `RWAST'        [11-OCT-1994]
  2191.  
  2192. TELNET clients prior to version 5.0 could, under certain conditions, lock up a
  2193. process in an RWAST state. All users are strongly recommended to upgrade to
  2194. Version 5.0-1 of TELNET in which this problem, and others, are solved.
  2195.                             <A.Harper@kcl.ac.uk>
  2196.  
  2197.  
  2198.  
  2199. 3.5.2 >>>> WHY DOES TELNETTING INTO OPENCMU HANG        [11-OCT-1994]
  2200.  
  2201. When telnetting into a OpenCMU host, the system does not prompt for a username
  2202. until an extra carriage return appears. There are three known, unrelated,
  2203. causes for this problem.
  2204.  
  2205. First, a bug in earlier versions of the OpenCMU telnet software is known to cause
  2206. unexpected hangs. To fix this, All users should install the latest patches to
  2207. OpenCMU (6.6-5A) and the telnet client.
  2208.  
  2209. Second, some PC telnet clients are known to contain problems that prevent them
  2210. successfully interworking with OpenCMU TELNET. PC-NFS telnet versions 4.x and 5.x
  2211. suffer from this problem.  To fix, avoid these clients - there are plenty of
  2212. reasonable alternative telnet clients around.
  2213.  
  2214. Finally, it may be the case that some PC telnet's do not correctly negotiate
  2215. the telnet options when the call is connected. One or other end can wait
  2216. indefinitely for the opposite end to continue. At this time, no clear solution
  2217. is known but the problem can sometimes be alleviated by adding the following to
  2218. the OpenCMU INET$CONFIG file:
  2219.  
  2220.       Variable:TELNET_NEG_TIMEOUT:0
  2221.  
  2222. This causes telnet not to wait for negotiations to timeout, and can speed up
  2223. those logins which appear to hang for a long time.
  2224.  
  2225. Note: Under OpenVMS 6.1, the telnet pause bug appears again and there is no
  2226. current solution to this.
  2227.                             <A.Harper@kcl.ac.uk>
  2228.  
  2229. --------------------------------------------------------------------------------
  2230.  
  2231. >>>> 3.6 MISCELLANEOUS                     [ 22-AUG-1995 ]
  2232. ----------------------
  2233.  
  2234. This section notes various unrelated items and known bugs that may affect
  2235. several applications.
  2236.  
  2237.  
  2238. 3.6.1 PORT NUMBER ALLOCATION BUG            [ 22-AUG-1995 ]
  2239.  
  2240. There is a bug in the low level IP software in OpenCMU 6.6-5 and up, that can
  2241. result in bad port numbers being returned to an application. The details are as
  2242. follows:
  2243.  
  2244.   *  Client requests that a free port be allocated and set up for listening.
  2245.  
  2246.   *  OpenCMU allocates and sets up the port correctly but returns ZERO back to
  2247.      the caller instead of the port number.
  2248.  
  2249.   *  Subsequent references to the port then fail.
  2250.  
  2251. NOTE: If the client requests an explicit port number, rather than letting Open
  2252. CMU select it, the port number is returned correctly.
  2253.  
  2254.  
  2255. Here is an example of the problem with FTP:
  2256.  
  2257.   * FTP client has a control connection opened to port 20 on the remote FTP
  2258.     server and wants to download a file.
  2259.  
  2260.   * FTP client requests OpenCMU to allocate a free port and set it up for
  2261.     listening, the idea being that the remote FTP server will make an outgoing
  2262.     call to this port and send the file to it. The OpenCMU bug causes ZERO to
  2263.     be returned for the randomly allocated port.
  2264.  
  2265.   * FTP client sends the returned port number to the FTP server in a PORT
  2266.     command, thus:
  2267.       PORT 123,45,1,2,0,0
  2268.  
  2269.   * FTP server tries to open the data connection back to this port on the
  2270.     client system. This fails because port zero does not exist.
  2271.  
  2272. This problem is corrected in the forthcoming 6.7 release.
  2273.  
  2274. This bug is known to affect WWW clients, such as Lynx and Mosaic, where they
  2275. are linked with an OpenCMU compatible socket library. The effect is to cause
  2276. FTP transfers to fail unexpectedly while other protocols work fine.
  2277.  
  2278. Note that the OpenCMU FTP client gets around the problem by randomly allocating
  2279. the port itself, based on some function of the date/time, and asking OpenCMU to
  2280. allocate that specific port. This causes the port number to be returned
  2281. correctly but risks clashing with a port allocated by another application on
  2282. the same system. The risk is small but can cause random failures of FTP. The
  2283. same technique can be used by user written applications.
  2284.  
  2285.                             <A.Harper@kcl.ac.uk>
  2286.  
  2287. --------------------------------------------------------------------------------
  2288.  
  2289.  
  2290.  
  2291. 4.0 >>>> FREE AND PUBLIC DOMAIN SOFTWARE SUPPORTING OPENCMU
  2292. -----------------------------------------------------------
  2293.  
  2294. In this section is described a number of network applications which are known
  2295. to work with the OpenCMU transport. All are available freely (I.E. without
  2296. charge) though some authors have chosen to retain copyright (freeware rather
  2297. than public domain).
  2298.  
  2299. The locations of these software items are given via URLs. The presence of a '*'
  2300. wildcard does not imply that the URL can be used 'as is' to fetch the whole
  2301. package, but merely that there are several files which make up the item.
  2302.  
  2303.  
  2304. Volunteers are always required to port other network applications to the latest
  2305. OpenCMU release. If you port anything, please notify the FAQ maintainer and the
  2306. OpenCMU mailing list. Also, please try to persuade the original author of any
  2307. ported application to include your OpenCMU changes in the official release.
  2308. This will greatly reduce the amount of work needed to track the latest releases
  2309. of software.
  2310.  
  2311. --------------------------------------------------------------------------------
  2312.  
  2313. 4.1 >>>> TCP/IP TRANSPORT INTERFACE LIBRARIES            [10-OCT-1994]
  2314. ---------------------------------------------
  2315.  
  2316. There are a number of different free and commercial TCP/IP transports available
  2317. for OpenVMS, including UCX, Multinet, OpenCMU, Pathway and TCPware.  Each has a
  2318. slightly different programming interface, making it somewhat difficult to write
  2319. portable network applications.
  2320.  
  2321. A universal, though not exclusive, de-facto standard for interfacing
  2322. applications to the network is the Berkeley (BSD) 'sockets' interface. By
  2323. writing applications conforming to this standard, it should be a relatively
  2324. simple matter to link with the transport specific socket library.
  2325. Unfortunately, there are other considerations that make this difficult;
  2326. non-standard or transport-specific header files for one.
  2327.  
  2328. The software here provides a selection of socket libraries that interface an
  2329. application, written to the sockets standard, to the OpenCMU networking
  2330. software. Some libraries also interface to two or more different network
  2331. transports. For maximum portability, applications should be written in terms of
  2332. these multi-transport interfaces. The recommended one is the SOCKETSHR library
  2333. on top of the NETLIB library.
  2334.  
  2335. Some of the applications described in this section require a specific socket
  2336. library interface, so it may be necessary to install two or more of them on a
  2337. given system to get all the applications to run.
  2338.                             <A.Harper@kcl.ac.uk>
  2339.  
  2340.  
  2341.  
  2342. 4.1.1 >>>> NETLIB                        [10-OCT-1994]
  2343. -----------------
  2344.  
  2345. Summary:
  2346.     A vendor independent TCP/IP programming interface.
  2347.  
  2348. Description:
  2349.     NETLIB solves the problem by providing a vendor-independent programming
  2350.     interface that sits between the application and the particular version
  2351.     of TCP/IP installed on the system. Thus, applications can be written in
  2352.     terms of NETLIB routines and will run over any transport supported by
  2353.     NETLIB.
  2354.  
  2355. Transports Supported:
  2356.     NETLIB supports OpenCMU; also, Multinet, TCPware, UCX and TWG's Win/TCP
  2357.     and Pathway Access.
  2358.  
  2359. Interface Type:
  2360.     Similar to BSD sockets in concept but not in syntax. See SOCKETSHR
  2361.     package.
  2362.  
  2363. Author:
  2364.     Matt Madison <Madison @ tgv.com>
  2365.  
  2366. Pre-Requisites:
  2367.     NONE, except for one of the supported TCP/IP transports listed above.
  2368.                             <A.Harper@kcl.ac.uk>
  2369.  
  2370.  
  2371. Availability:
  2372.     ftp://ftp.spc.edu/macro32/savesets/netlibNNN.zip
  2373.     ftp://ftp.wku.edu/madgoat/netlibNNN.zip
  2374.     ftp://ftp.kcl.ac.uk/madgoat/netlib.*
  2375.                         [ NNN = version number ]
  2376.  
  2377.  
  2378.  
  2379. 4.1.2 >>>> SOCKETSHR                        [10-OCT-1994]
  2380. --------------------
  2381.  
  2382. Summary:
  2383.     A BSD sockets interface to NETLIB
  2384.  
  2385. Description:
  2386.     SOCKETSHR provides a complete BSD compatible socket library that allows
  2387.     applications to be written with complete independence of the underlying
  2388.     network transport. It is written to interface to the NETLIB software,
  2389.     which provides an interface to all the available TCP/IP transports for
  2390.     VMS.
  2391.  
  2392.     A recommended package for all users who are writing or porting network
  2393.     applications.
  2394.  
  2395. Transports Supported:
  2396.     All those supported by NETLIB
  2397.  
  2398. Interface Type:
  2399.     BSD sockets compatible
  2400.  
  2401. Author:
  2402.     Thanks go to Eckart Meyer for making this package available, and to
  2403.     Mike O'Malley, on whose LIBCMU package this is based.
  2404.  
  2405. Pre-Requisites:
  2406.     To use SOCKETSHR, the NETLIB package is a pre-requisite; to use
  2407.     SOCKETSHR with UDP applications requires NETLIB version 1.7 as a
  2408.     minimum!
  2409.                             <A.Harper@kcl.ac.uk>
  2410.  
  2411.  
  2412. Availability:
  2413.     ftp://ftp.ifn.ing.tu-bs.de/vms/socketshr/socketshr_bin_NNN.zip
  2414.     ftp://ftp.ifn.ing.tu-bs.de/vms/socketshr/socketshr_src_NNN.zip
  2415.     ftp://ftp.kcl.ac.uk/default/SOCKETSHR.*
  2416.                         [ NNN = version number ]
  2417.  
  2418.  
  2419.  
  2420. 4.1.3 >>>> SOCKIT                        [10-OCT-1994]
  2421. -----------------
  2422.  
  2423. Summary:
  2424.     A socket library interface for VMS network applications
  2425.  
  2426. Description:
  2427.     SOCKIT provides an emulation of the BSD socket routines for VMS. The
  2428.     interesting thing about this package is that it will interface to
  2429.     several of the commonly available TCP/IP transports, OpenCMU included.
  2430.  
  2431. Transports Supported:
  2432.     OpenCMU
  2433.     Wollongong
  2434.     UCX            (thus works with Multinet if UCX emulation on!)
  2435.     X.25
  2436.  
  2437. Interface Type:
  2438.     BSD sockets compatible
  2439.  
  2440. Author:
  2441.     Peter Kay
  2442.  
  2443. Pre-Requisites:
  2444.     NONE. The code to interface to each transport is built-in.
  2445.                             <A.Harper@kcl.ac.uk>
  2446.  
  2447.  
  2448. Availability:
  2449.     ftp://ftp.kcl.ac.uk/default/sockit.*
  2450.  
  2451.  
  2452.  
  2453. 4.1.4 >>>> LIBCMU                         [10-OCT-1994]
  2454. -----------------
  2455.  
  2456. Summary:
  2457.     A socket library interface for OpenCMU
  2458.  
  2459.  
  2460. Description:
  2461.     LIBCMU is a purpose built library of routines for interfacing
  2462.     applications that use Berkeley sockets to the OpenCMU programming
  2463.     interface. This library allows a number of applications written for
  2464.     sockets to be easily ported to OpenCMU.
  2465.  
  2466.     Note that development of this library has ceased. It is available for
  2467.     some applications that still require it but new developments should
  2468.     use the SOCKETSHR/NETLIB combination instead.
  2469.  
  2470. Transports Supported:
  2471.     OpenCMU
  2472.  
  2473. InterFace Type:
  2474.     BSD sockets compatible
  2475.  
  2476. Author:
  2477.     Thanks go to Mike O'Malley for writing and maintaining the LIBCMU
  2478.     software.
  2479.                             <A.Harper@kcl.ac.uk>
  2480.  
  2481.  
  2482. Availability:
  2483.     ftp://kermit.columbia.edu/vms-libcmu/ckvlcmu.hex
  2484.     ftp://ftp.kcl.ac.uk/cmu-tcpip/libcmu.*
  2485.  
  2486. --------------------------------------------------------------------------------
  2487.  
  2488. 4.2 >>>> MAIL APPLICATIONS                    [10-OCT-1994]
  2489. --------------------------
  2490.  
  2491. Electronic mail is one of the main applications used over TCP/IP networks. It
  2492. allows messages to be sent from one user to another even though they are on
  2493. opposite sides of the world. Provided the users both have access to a computer
  2494. system running compatible mail software, messages can be sent easily.
  2495.  
  2496. OpenCMU does not provide any mail applications. Instead one or more of the
  2497. applications listed below are recommended.
  2498.                             <A.Harper@kcl.ac.uk>
  2499.  
  2500.  
  2501.  
  2502.  
  2503. 4.2.1    >>>> MX ELECTRONIC MAIL                    [10-OCT-1994]
  2504. -------------------------------
  2505.  
  2506. Summary:
  2507.     A comprehensive SMTP based network mail system that interfaces directly
  2508.     into VMS MAIL and the underlying TCP/IP network.
  2509.  
  2510.  
  2511. Description:
  2512.     MX provides full SMTP mail support and interfaces to VMS MAIL.  It also
  2513.     provides a mailing list and file server facility.
  2514.  
  2515.     MX is completely free of charge and may be obtained from your local
  2516.     DECUS representative or from the sites listed below.
  2517.  
  2518. Pre-Requisites:
  2519.     MX requires the NETLIB interface library.
  2520.  
  2521. Author:
  2522.     Matt Madison <Madison @ tgv.com> and
  2523.     Hunter Goatley <goathunter@alpha.wkuvx1.wku>
  2524.     (C) MadGoat Software ltd.
  2525.                             <A.Harper@kcl.ac.uk>
  2526.  
  2527.  
  2528. Availability:
  2529.     ftp://ftp.spc.edu/mx/mxNNN/mxNNN.*
  2530.     ftp://ftp.kcl.ac.uk/madgoat/mx.*
  2531.                         [ NNN = version number ]
  2532.  
  2533.  
  2534.  
  2535. 4.2.2 >>>> IUPOP3                        [10-OCT-1994]
  2536. -----------------
  2537.  
  2538. Summary:
  2539.     A POP3 mail server
  2540.  
  2541. Description:
  2542.     POP3 is a protocol that allows a PC user to download mail from a
  2543.     central mail server and read it on the PC using PC style interfaces. A
  2544.     client that understands the POP protocol must run on the PC and many
  2545.     public domain or shareware ones are available (Win/QVT, Eudora,
  2546.     PC-Eudora, POPmail, Pegasus Mail and MINUET to name but a few).
  2547.  
  2548.     IUPOP3 is a POP3 server that runs under a number of systems, including
  2549.     VMS, and runs over the OpenCMU TCP/IP software (also UCX and Multinet).
  2550.  
  2551.  
  2552. Pre-Requisites:
  2553.     IUPOP3 requires a specific library for OpenCMU, INET_CMUTIL.
  2554.     Note the original author of this software (see below) does NOT currently
  2555.     support a OpenCMU version. The OpenCMU port is a one off.
  2556.  
  2557. Author:
  2558.     Indiana University
  2559.     Thanks to Brian T. Carcich for the OpenCMU port.
  2560.                             <A.Harper@kcl.ac.uk>
  2561.  
  2562.  
  2563. Availability:
  2564.     ftp://ftp.indiana.edu/pub/vms/iupop3/v1.7/*
  2565.     ftp://ftp.indiana.edu/pub/vms/iupop3/v1.7-CMU-TEK/*
  2566.     ftp://ftp.kcl.ac.uk/iupop3/iupop3-017.*
  2567.  
  2568.     ftp://ftp.kcl.ac.uk/cmu-tcpip/inet_cmutil.bck
  2569.  
  2570. --------------------------------------------------------------------------------
  2571.  
  2572. 4.3 >>>> NEWS APPLICATIONS                    [10-OCT-1994]
  2573. --------------------------
  2574.  
  2575. Usenet news is a world wide distributed news system. Messages generated on one
  2576. system are passed around the world rapidly, to all other systems. To simplify
  2577. the management of news, messages are divided into `newsgroups', each newsgroup
  2578. concentrating on one general topic. Using an appropriate newsreader, a user can
  2579. `subscribe' to a particular set of newsgroups and read all the related messages
  2580. in a manner similar to mail. There are some 3000+ different user groups
  2581. currently.
  2582.  
  2583. There are a number of parts to the news system. Firstly, software is required
  2584. to gather batches of news from an upstream `feed' site and insert it into a
  2585. local news database; Second, software is required to allow users to read the
  2586. news database, possibly modifying it by sending new messages.
  2587.  
  2588. The news database can be on the same system as the user, or the news database
  2589. can be on a remote system, accessible through a client-server mechanism. The
  2590. user's news reader program becomes a client, using the network to access a news
  2591. server.
  2592.                             <A.Harper@kcl.ac.uk>
  2593.  
  2594.  
  2595.  
  2596. 4.3.1 >>>> ANU NEWS                        [10-OCT-1994]
  2597. -------------------
  2598.  
  2599. Summary:
  2600.     A complete news system
  2601.  
  2602. Description:
  2603.     ANU-NEWS provides a complete package to deal with USENET news. News is
  2604.     received from an up-stream news feed site and stored in a local on-disk
  2605.     database. This database can be interrogated by local users running the
  2606.     NEWS application; A news server can be set up that provides access to
  2607.     the news databases via any convenient NEWS client running on another
  2608.     system (see NEWSRDR elsewhere in this document for one example).
  2609.  
  2610.     The ANU-NEWS server supports OpenCMU.
  2611.  
  2612.  
  2613. Author:
  2614.     Thanks go to Geoff Huston for writing and maintaining the ANU NEWS
  2615.     software.
  2616.                             <A.Harper@kcl.ac.uk>
  2617.  
  2618.  
  2619. Availability:
  2620.     ftp://kuhub.cc.ukans.edu/anu_vNNN/news_vNNN.zip
  2621.     ftp://ftp.kcl.ac.uk/news/news.*
  2622.                         [ NNN = version number ]
  2623.  
  2624.  
  2625. 4.3.2 >>>> NEWSRDR                        [10-OCT-1994]
  2626. ------------------
  2627.  
  2628. Summary:
  2629.     A VMS newsreader client
  2630.  
  2631.  
  2632. Description:
  2633.     NEWSRDR is a news client that allows the user to access the news groups
  2634.     stored on a news server system. This gives users a quick way of
  2635.     accessing all the news without the need to build a full news system.
  2636.  
  2637.  
  2638. Pre-Requisites:
  2639.     NEWSRDR requires the NETLIB library to interface to the underlying
  2640.     TCP/IP network.
  2641.  
  2642.  
  2643. Author:
  2644.     Thanks go to Matt Madison for writing and maintaining the NEWSRDR
  2645.     software. <madison @ tgv.com>
  2646.                             <A.Harper@kcl.ac.uk
  2647.  
  2648.  
  2649. Availability:
  2650.     ftp://ftp.spc.edu/macro32/savesets/newsrdr.zip
  2651.     ftp://ftp.kcl.ac.uk/news/newsrdr.*
  2652.  
  2653.  
  2654.  
  2655. 4.3.3 >>>> FNEWS                        [10-OCT-1994]
  2656. ----------------
  2657.  
  2658. Summary:
  2659.     A NEWS reading client for VMS
  2660.  
  2661. Description:
  2662.  
  2663.     FNEWS is another news reader client. It offers local caching of
  2664.     newsgroups to speed the downloading of messages.
  2665.  
  2666.  
  2667. Pre-Requisities:
  2668.     None: FNEWS builds for the currently installed transport.
  2669.  
  2670.  
  2671. Author:
  2672.     ???
  2673.                             <A.Harper@kcl.ac.uk>
  2674.  
  2675.  
  2676. Availability:
  2677.     ftp://zephyr.grace.cri.nz/pub/fnews/vms/fnews.bck
  2678.     ftp://ftp.kcl.ac.uk/news/fnews.*
  2679.  
  2680. --------------------------------------------------------------------------------
  2681.  
  2682. 4.4. >>>> WORLD WIDE WEB APPLICATIONS                [10-OCT-1994]
  2683. -------------------------------------
  2684.  
  2685. The world wide web is a distributed hypertext system that literally encompasses
  2686. the world. A document can be loaded from a remote server which contains
  2687. hypertext links to other documents anywhere in the world. Documents can be
  2688. text, graphics, sound, binary etc.
  2689.  
  2690. World Wide Web servers accept requests from clients to download documents, and
  2691. world wide web clients accept those documents and format them for the user's
  2692. display. A single display can be composed of a mix of text and graphics etc.
  2693.  
  2694. World Wide Web uses the HyperText Markup Language (HTML) to specify document
  2695. format and remote links.
  2696.  
  2697. World Wide Web links specify the location of the document (site, directory and
  2698. filename) as well as the protocol used to access them (ftp, wais, gopher, http
  2699. etc.). So world wide web combines the functionality of a number of client
  2700. types.
  2701.                             <A.Harper@kcl.ac.uk>
  2702.  
  2703.  
  2704.  
  2705. 4.4.1 >>>> MOSAIC                        [10-JUL-1995]
  2706. -----------------
  2707.  
  2708. Summary:
  2709.     A graphical World Wide Web client.
  2710.  
  2711. Description:
  2712.     MOSAIC is a superb graphical interface for browsing through the World
  2713.     Wide Web and gopher databases on the internet. By using a hypertext
  2714.     markup language, text, images and sound can be pulled together,
  2715.     irrespective of their locations, into a single on-screen document. This
  2716.     is THE program for information seekers.
  2717.  
  2718.  
  2719. Pre-Requisites:
  2720.     DECwindows/Motif is required to display the document.
  2721.  
  2722.     SOCKETSHR and NETLIB are pre-requisite for the version described here.
  2723.     Please note that there are several different ports of this version but
  2724.     only those listed support SOCKETSHR, and hence OpenCMU.
  2725.  
  2726. Author:
  2727.     MOSAIC is written by the National Centre for Supercomputing
  2728.     Applications at the University of Illinois.
  2729.                             <A.Harper@kcl.ac.uk>
  2730.  
  2731.  
  2732.  
  2733. Availability:
  2734.     ftp://ftp.kcl.ac.uk/mosaic/mosaic.*
  2735.     ftp://ftp.kcl.ac.uk/mosaic/mosaic_bin.*
  2736.  
  2737.     ftp://ftp.ifn.ing.tu-bs.de/vms.socketshr/mosaic_src_2-4.zip
  2738.     ftp://ftp.ifn.ing.tu-bs.de/vms.socketshr/mosaic_bin_2-4.zip
  2739.  
  2740.  
  2741.  
  2742. 4.4.2 >>>> LYNX                            [10-OCT-1994]
  2743. ---------------
  2744.  
  2745. Summary:
  2746.     A World Wide Web browser, designed for line mode terminals (such as
  2747.     Digital's VT series.
  2748.  
  2749. Description:
  2750.     LYNX is a line mode version of a World Wide Web hypertext browser. It
  2751.     combines the functions of gopher and FTP, together with WWW and allows
  2752.     access from a VT compatible terminal.  It provides similar
  2753.     functionality to that of Mosaic except that a simple terminal interface
  2754.     is all that is required.
  2755.  
  2756. Pre-Requisites:
  2757.     A socket library interface is required; LYNX recognizes a number of
  2758.     socket libraries. For OpenCMU, either the SOCKETSHR (recommended) or
  2759.         the LIBCMU socket library is required.
  2760.  
  2761. Author:
  2762.     Thanks go to the LYNX developers, mainly at the University of Kansas,
  2763.     for developing and maintaining this software, and for making it freely
  2764.     available.
  2765.                             <A.Harper@kcl.ac.uk>
  2766.  
  2767.  
  2768. Availability:
  2769.     ftp://ftp.kcl.ac.uk/lynx/lynx.*
  2770.  
  2771.  
  2772.  
  2773. 4.4.3 >>> HTTP_SERVER                    [10-OCT-1994]
  2774. ---------------------
  2775.  
  2776. Summary:
  2777.     A World Wide Web server conforming to the standard HTTP (HyperText
  2778.     Transfer Protocol) mechanism.
  2779.  
  2780. Description:
  2781.     HTTP_SERVER provides a VMS system with the ability to act as a World
  2782.     Wide Web server using the HTTP protocol. It will accept requests from
  2783.     HTTP clients (such as MOSAIC - see elsewhere in this document) and
  2784.     return the necessary information. A full description of the World Wide
  2785.     Web system is outside the scope of this summary but it is, in essence,
  2786.     a distributed hypertext system capable of mixing text, images,
  2787.     graphics, animation and sound into a single on-screen display, with
  2788.     each element being on different systems anywhere in the world. The HTML
  2789.     language is used to specify the links.
  2790.  
  2791. Pre-Requisites:
  2792.     DECthreads is required; so a minimum OpenVMS of 5.5 is required.
  2793.  
  2794.     The server contains all the necessary interfaces to work with
  2795.     OpenCMU, as well as with UCX and Multinet.
  2796.  
  2797. Author:
  2798.     Thanks go to David Jones for writing and maintaining this software.
  2799.                             <A.Harper@kcl.ac.uk>
  2800.  
  2801.  
  2802. Availability:
  2803.     ftp://osu.edu/http_server.tar
  2804.     ftp://ftp.spc.edu/macro32/savesets/http_server.zip
  2805.     ftp://ftp.wku.edu/vms.fileserv/http_server.zip
  2806.     ftp://ftp.kcl.ac.uk/default/http_server.*
  2807.  
  2808. --------------------------------------------------------------------------------
  2809.  
  2810. 4.5 >>>> FILE TRANSFER APPLICATIONS                [10-OCT-1994]
  2811.  
  2812. File transfer is another major application run over the network. It allows
  2813. files to be transferred between two different systems using a simple set of
  2814. commands. It is most often used for retrieving files from one of the many
  2815. public domain archive sites around the world.
  2816.  
  2817. OpenCMU comes prepackaged with an FTP client and server but it is worth
  2818. considering the alternatives listed here.
  2819.                             <A.Harper@kcl.ac.uk>
  2820.  
  2821.  
  2822. 4.5.1 >>>> MADGOAT FTP                        [10-OCT-1994]
  2823. ----------------------
  2824.  
  2825. Summary:
  2826.     An alternative FTP client and server.
  2827.  
  2828. Description:
  2829.     The File Transfer program (or FTP) is an important part of the TCP/IP
  2830.     applications set. It allows files to be moved between two systems. 
  2831.     MGFTP is a file transfer program which can be used over any of the
  2832.     available TCP/IP transports, including OpenCMU.
  2833.  
  2834.     This client is more functional than the one provided with OpenCMU and is
  2835.     recommended. Useful enhancements include:
  2836.       * Logging of server transactions to a file in each user's home
  2837.         directory
  2838.       * User control over how the server is used on an account
  2839.       * Anonymous FTP has per-directory messages
  2840.       * FTP client has automatic anonymous login
  2841.       * FTP client can have aliases defined to connect/fetch from specific
  2842.         systems/files
  2843.  
  2844. Pre-Requisites:
  2845.     The NETLIB interface is required.
  2846.  
  2847. Author:
  2848.     MGFTP is based on the OpenCMU FTP client and server, written by many
  2849.     people.
  2850.  
  2851.     Thanks go to Matt Madison and Hunter Goatley, of MadGoat software, and
  2852.     to Darrell Burkhead, for writing and maintaining MGFTP and making it
  2853.     available as freeware.
  2854.                             <A.Harper@kcl.ac.uk>
  2855.  
  2856.  
  2857. Availability:
  2858.     ftp://ftp.wku.edu/madgoat/mgftp.zip
  2859.     ftp://ftp.spc.edu/macro32/savesets/mgftp.zip
  2860.     ftp://ftp.kcl.ac.uk/madgoat/mgftp.*
  2861.  
  2862.  
  2863. 4.5.2 >>>> C-KERMIT                        [31-MAR-1995]
  2864. -------------------
  2865.  
  2866. Summary:
  2867.     File transfer over the current terminal connection to a host.
  2868.  
  2869. Description:
  2870.     The KERMIT program is a widely used way of tranferring files over
  2871.     serial lines between systems. The user's terminal temporarily becomes a
  2872.     client and the user's host session temporarily becomes a server. The
  2873.     KERMIT protocol allows switching between terminal mode and file
  2874.     transfer mode, as well as sending or requesting files to be transferred.
  2875.     In the past, kermit has been able to set up terminal sessions, and run
  2876.     the file transfers, only over serial line connections. More recent
  2877.     versions have allowed the terminal connections, and hence the file
  2878.     transfers, to take place over telnet links by having direct TCP/IP
  2879.     support built in.
  2880.  
  2881.  
  2882.     The latest version of C-kermit supports direct TCP/IP connections and
  2883.     will work over the OpenCMU package.
  2884.  
  2885. Pre-Requisites:
  2886.     The OpenCMU version requires a socket library specific to the transport
  2887.     on which it runs. For OpenCMU, the required socket library is LIBCMU.
  2888.  
  2889. Author:
  2890.     Columbia University and many contributors around the world.
  2891.                             <A.Harper@kcl.ac.uk>
  2892.  
  2893.  
  2894. Availability:
  2895.     ftp://kermit.columbia.edu/kermit/b/ckvvcmu.hex
  2896.  
  2897.  
  2898.  
  2899. 4.5.3 >>>> FSP                            [27-OCT-1994]
  2900. --------------
  2901.  
  2902. Summary:
  2903.     File transfer over a lightweight UDP based protocol.
  2904.  
  2905.  
  2906. Description:
  2907.     FSP is a simple file transfer protocol based around UDP rather than
  2908.     TCP protocols.  It is designed to impose minimal load on the server
  2909.     and does not require the user to log in or identify themselves.
  2910.     Essentially, the client throws UDP packets at a server asking for
  2911.     a portion of a file or info about a file, and keeps throwing the same
  2912.     request at it until the server responds. Thus an FSP transfer is, in
  2913.     principle, resilient to server failure as it will retry until the
  2914.     server comes back on-line. It is said that FSP is what anonymous FTP
  2915.     should have been.
  2916.  
  2917.     This package is a port of the unix FSP client and server to VMS, and
  2918.     directly supports UCX, Multinet and OpenCMU. It also supports the
  2919.         vendor independent SOCKETSHR library.
  2920.  
  2921.  
  2922. Pre-Requisities:
  2923.     Either:
  2924.         LIBCMU    For direct OpenCMU support
  2925.  
  2926.     Or:
  2927.         SOCKETSHR    For vendor independent TCP/IP support (recommended)
  2928.         NETLIB    (required by SOCKETSHR)
  2929.  
  2930.  
  2931. Author:
  2932.     Various.
  2933.                             <A.Harper@kcl.ac.uk>
  2934.  
  2935.  
  2936. Availability:
  2937.     ftp://ftp.kcl.ac.uk/default/fsp.*
  2938.  
  2939. --------------------------------------------------------------------------------
  2940.  
  2941. 4.6 >>>> NETWORK ARCHIVE SEARCH APPLICATIONS            [10-OCT-1994]
  2942. --------------------------------------------
  2943.  
  2944. There are many many sites around the world that allow public access to parts of
  2945. the file system that contain freely available software. With so many sites and
  2946. so many packages available, it can often be difficult to locate the appropriate
  2947. site that holds the required software.
  2948.  
  2949. ARCHIE was designed to ease this problem. A large number of sites are
  2950. responsible for indexing all the other sites in the world and keeping track of
  2951. what each contains. The ARCHIE mechanism allows a user to supply a keyword to
  2952. the nearest archie host and have it return a list of software locations that
  2953. contain the keyword somewhere in the directory/filename path. This usually
  2954. results in a large list of potential places to search, which can then be
  2955. interrogated using an FTP utility.
  2956.                             <A.Harper@kcl.ac.uk>
  2957.  
  2958.  
  2959. 4.6.1 >>>> ARCHIE                        [10-AUG-1994]
  2960. -----------------
  2961.  
  2962. Summary:
  2963.     A client used to interrogate the world-wide archive software database.
  2964.  
  2965. Description:
  2966.     ARCHIE is a client for interrogating ARCHIE servers. Such servers
  2967.     maintain up to date information about what software is available on
  2968.     various FTP archives around the world and permit the client to ask
  2969.     where a particular item can be found. Given a keyword, ARCHIE will try
  2970.     to find all archives that contain files with the keyword as part of the
  2971.     name. Once located, FTP can be used to retrieve the item from the
  2972.     nearest archive.
  2973.  
  2974.     ARCHIE is configurable to use any one of a number of nearby archie
  2975.     servers with one selected at compile time as the default.
  2976.  
  2977. Pre-Requisites:
  2978.     For OpenCMU usage, a socket library interface is required. There are
  2979.     two parallel versions of archie. One runs over the LIBCMU package, and
  2980.     the other runs over the SOCKETSHR package. Check the readme files with
  2981.     the software to see which is applicable.
  2982.  
  2983. Author:
  2984.     Unknown. Many contributors.
  2985.                             <A.Harper@kcl.ac.uk>
  2986.  
  2987.  
  2988. Availability:
  2989.     ftp://ftp.kcl.ac.uk/archie/archie.*
  2990.  
  2991. --------------------------------------------------------------------------------
  2992.  
  2993. 4.7 >>>> GOPHER APPLICATIONS                    [10-OCT-1994]
  2994. ----------------------------
  2995.  
  2996. GOPHER is a protocol for requesting information from a remote system. GOPHER
  2997. servers run on these systems to handle the incoming requests and GOPHER clients
  2998. are necessary to interact with a user and generate the requests. Information is
  2999. presented to the user in a menu format and allows information of many different
  3000. types to be downloaded, viewed and/or saved.  One GOPHER server can send back a
  3001. pointer to a file of information that exists on a completely different system.
  3002. This provides a generalised world wide browsing system
  3003.  
  3004. NOTE: To a large extent, the functionality of GOPHER has been superceded by the
  3005. World Wide Web but there are still a large number of gopher servers around.
  3006.                             <A.Harper@kcl.ac.uk>
  3007.  
  3008.  
  3009. 4.7.1 >>>> GOPHER                        [10-OCT-1994]
  3010. -----------------
  3011.  
  3012. Summary:
  3013.     A gopher client and server for VMS
  3014.  
  3015. Description:
  3016.     The gopher client allows a user to request documents from any gopher
  3017.     server in the world. The gopher server allows a site to serve documents
  3018.     to the rest of the world.
  3019.  
  3020. Pre-Requisites:
  3021.     The gopher client requires NETLIB, and will run over any of the
  3022.     supported TCP/IP transports. The gopher server specifically requires
  3023.     either UCX or MULTINET. There is no version for OpenCMU.
  3024.  
  3025.  
  3026. Author:
  3027.     The University of Minnesota
  3028.                             <A.Harper@kcl.ac.uk>
  3029.  
  3030.  
  3031. Availability:
  3032.     ftp://boombox.micro.umn.edu//pub/gopher/VMS/gopher*VMS*.zip
  3033.     ftp://ftp.kcl.ac.uk/gopher/gopher.*
  3034.  
  3035. --------------------------------------------------------------------------------
  3036.  
  3037. 4.8 >>>> FINGER APPLICATIONS                    [10-OCT-1994]
  3038. ----------------------------
  3039.  
  3040. The FINGER protocol allows a client to `finger' another user on another system
  3041. to find out basic information. For instance, fingering a system will give
  3042. details of who is currently logged on. Fingering an individual username will
  3043. give selected personal details (real name, location and any immediate plans).
  3044.  
  3045. Note - some sites consider finger to be a security risk and do not run either
  3046. the server or the clients. Thus it may not be possible to `finbger' some
  3047. systems.
  3048.                             <A.Harper@kcl.ac.uk>
  3049.  
  3050.  
  3051.  
  3052. 4.8.1 >>>> MADGOAT FINGER                    [10-AUG-1994]
  3053. -------------------------
  3054.  
  3055. Summary:
  3056.     A FINGER Client and Server
  3057.  
  3058. Description:
  3059.     FINGER provides both client and server facilities; This allows users
  3060.     to discover information about users on another system and for those
  3061.     users, in turn, to find out about local users.
  3062.  
  3063. Pre-Requisites:
  3064.     FINGER requires the NETLIB library
  3065.  
  3066. Author:
  3067.     Matt Madison   <madison@tgv.com>
  3068.         Hunter Goatley <goathunter@alpha.wku.edu>
  3069.     (C) MadGoat Software ltd.
  3070.                             <A.Harper@kcl.ac.uk>
  3071.  
  3072.  
  3073.  
  3074. Availability:
  3075.     ftp://ftp.spc.edu/macro32/savesets/mg_finger.zip
  3076.     ftp://ftp.kcl.ac.uk/madgoat/mg_finger.*
  3077.  
  3078. --------------------------------------------------------------------------------
  3079.  
  3080. 4.9 >>>> DOMAIN NAME SERVER APPLICATIONS            [10-OCT-1994]
  3081. ----------------------------------------
  3082.  
  3083. The Domain Name Server (or DNS) is responsbible for mapping system names into
  3084. network addresses. It is sometimes useful to interrogate the DNS directly,
  3085. perhaps to do fault determination or to track down a system name.
  3086.                             <A.Harper@kcl.ac.uk>
  3087.  
  3088.  
  3089. 4.9.1 >>>> NSQUERY                        [10-OCT-1994]
  3090. ------------------
  3091.  
  3092. Summary:
  3093.     Request information from the DNS
  3094.  
  3095. Description:
  3096.     NSQUERY is a very useful utility that allows a user to interrogate any
  3097.     Domain Name Server for full site details.
  3098.  
  3099. Pre-Requisites:
  3100.     Requires the NETLIB library.
  3101.  
  3102. Author:
  3103.     Thanks go to Matt Madison <madison@tgv.com> for writing and mainting
  3104.     the NSQUERY software.
  3105.                             <A.Harper@kcl.ac.uk>
  3106.  
  3107.  
  3108. Availability:
  3109.     ftp://ftp.spc.edu/macro32/savesets/nsquery.zip
  3110.     ftp://ftp.kcl.ac.uk/madgoat/nsquery.*
  3111.  
  3112.  
  3113.  
  3114. 4.9.2 >>>> IPADDR                        [10-OCT-1994]
  3115. -----------------
  3116.  
  3117. Summary:
  3118.     Convert name to IP Address and vice versa
  3119.  
  3120. Description:
  3121.     IPADDR is a simple utility to map an IP address into its corresponding
  3122.     host name(s) and vice versa.
  3123.  
  3124. Pre-Requisites:
  3125.     Requires the NETLIB library.
  3126.  
  3127. Author:
  3128.     Andy Harper <A.Harper @ kcl.ac.uk>
  3129.                             <A.Harper@kcl.ac.uk>
  3130.  
  3131.  
  3132. Availability:
  3133.     ftp://ftp.kcl.ac.uk/default/ipaddr.*
  3134.  
  3135. --------------------------------------------------------------------------------
  3136.  
  3137. 4.10 >>>> MISCELLANEOUS APPLICATIONS
  3138. ------------------------------------
  3139.  
  3140.  
  3141.  
  3142. 4.10.1 >>>> NETTIME                        [19-DEC-1994]
  3143. -------------------
  3144.  
  3145. Summary:
  3146.     Consult a network time server and display, or set, the time from it
  3147.  
  3148. Description:
  3149.     A NTP conformant utility that can be used to consult a known time
  3150.     server and use it to set the clock. Alternatively, the current time
  3151.     on various different time servers can be displayed.
  3152.  
  3153. Pre-Requisites:
  3154.     None
  3155.  
  3156. Author:
  3157.     John Clement <clement@physics.rice.edu>
  3158.                             <A.Harper@kcl.ac.uk>
  3159.  
  3160.  
  3161. Availability:
  3162.     ftp://ftp.kcl.ac.uk/cmu-tcpip/nettime.bck
  3163.  
  3164.  
  3165.  
  3166. 4.10.2 >>>> RLOGIN                        [28-APR-1995]
  3167. ------------------
  3168.  
  3169. Summary:
  3170.     Remote Login to another host
  3171.  
  3172. Description:
  3173.     An implementation of the BSD 'R' series of protocols which allows the
  3174.     user to login from one host to another host without specifying a
  3175.     password, using the concept of 'trusted' hosts. Note that this can be
  3176.     a major security hole.
  3177.  
  3178.  
  3179. Pre-Requisites:
  3180.     None
  3181.  
  3182. Author:
  3183.     Don Stokes <don@vuw.ac.nz>
  3184.                             <A.Harper@kcl.ac.uk>
  3185.  
  3186.  
  3187. Availability:
  3188.         ftp://toyvax.zl2tnm.gen.nz/rlogin.bck
  3189.     ftp://ftp.kcl.ac.uk/cmu-tcpip/rlogin.bck
  3190.  
  3191.  
  3192.  
  3193. 4.10.3 >>>> CSDRV                        [28-APR-1995]
  3194. -----------------
  3195.  
  3196. Summary:
  3197.     VJ Compressed SLip Driver
  3198.  
  3199. Description:
  3200.     A compressed SLIP driver that is a drop-in replacement for the
  3201.     supplied SLDRV SLIP driver. This provides the Van Jacobsen header
  3202.     compression on SLIP connections, increasing the throughput and
  3203.     performance.
  3204.  
  3205. Pre-Requisites:
  3206.     None
  3207.  
  3208. Author:
  3209.     Don Stokes <don@vuw.ac.nz>
  3210.                             <A.Harper@kcl.ac.uk>
  3211.  
  3212.  
  3213. Availability:
  3214.         ftp://toyvax.zl2tnm.gen.nz/csdrv.bck
  3215.     ftp://ftp.kcl.ac.uk/cmu-tcpip/csdrv.bck
  3216.  
  3217.