Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ tcp.release_notes() — Apollo

Media Vault

Software Library

Restoration Projects

Artifacts Sought









                          Domain TCP/IP Release Document

                               Software Version 3.1

                               Part No. 005498-A00

                                   Revision 00

         This document describes Domain TCP/IP Software Version 3.1.

                  Release   documents  for  standard  Domain
                  software and  optional  software  products
                  are    located    in   the   system   /doc
                  directory.































                             APOLLO COMPUTER INC.
                              330 Billerica Road
                       Chelmsford, Massachusetts 01824


















Copyright c 1988 Apollo Computer Inc.
All rights reserved. Printed in U.S.A.

First Printing: June, 1988

This document was formatted using the FMT tool  distributed  with  the  Domain
computer system.


Apollo and Domain are registered trademarks of Apollo Computer Inc.

UNIX  is  a registered trademark of AT&T in the USA and other countries.   Ada
is  a registered trademark of U.S. Government (Ada Joint Program  Office).

3DGMR, Aegis, D3M, DGR, Domain/Access, Domain/Ada,  Domain/Bridge,   Domain/C,
Domain/ComController,     Domain/CommonLISP,     Domain/CORE,    Domain/Debug,
Domain/DFL,   Domain/Dialogue,   Domain/DQC,    Domain/IX,    Domain/Laser-26,
Domain/LISP,   Domain/PAK,   Domain/PCC,  Domain/PCI, Domain/SNA, Domain/X.25,
DPSS, DPSS/Mail, DSEE, FPX,  GMR,  GPR,  GSR,  NCK,   NLS,  Network  Computing
Kernel,   Network  Computing  System,  Network  License Server, Open Dialogue,
Open  System  Toolkit,   Personal  Super  Workstation,  Personal  Workstation,
Series 3000, and Series 4000 are trademarks of Apollo Computer Inc.



Apollo  Computer  Inc.  reserves  the  right to make changes in specifications
and other information contained in this  publication  without  prior   notice,
and  the reader should in all cases consult Apollo Computer  Inc. to determine
whether any such changes have been made.

THE TERMS AND CONDITIONS GOVERNING THE SALE OF APOLLO COMPUTER  INC.  HARDWARE
PRODUCTS  AND  THE LICENSING OF APOLLO COMPUTER INC. SOFTWARE PROGRAMS CONSIST
SOLELY OF THOSE SET FORTH IN THE WRITTEN  CONTRACTS  BETWEEN  APOLLO  COMPUTER
INC.  AND  ITS  CUSTOMERS.   NO  REPRESENTATION  OR  OTHER AFFIRMATION OF FACT
CONTAINED IN  THIS  PUBLICATION,  INCLUDING  BUT  NOT  LIMITED  TO  STATEMENTS
REGARDING   CAPACITY,   RESPONSE-TIME  PERFORMANCE,  SUITABILITY  FOR  USE  OR
PERFORMANCE OF PRODUCTS DESCRIBED HEREIN SHALL BE DEEMED TO BE A  WARRANTY  BY
APOLLO  COMPUTER INC. FOR ANY PURPOSE, OR GIVE RISE TO ANY LIABILITY BY APOLLO
COMPUTER INC. WHATSOEVER.

IN NO  EVENT  SHALL  APOLLO  COMPUTER  INC.  BE  LIABLE  FOR  ANY  INCIDENTAL,
INDIRECT,  SPECIAL  OR  CONSEQUENTIAL  DAMAGES  WHATSOEVER  (INCLUDING BUT NOT
LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATING  TO  THIS  PUBLICATION  OR
THE  INFORMATION  CONTAINED  IN  IT,  EVEN  IF  APOLLO  COMPUTER INC. HAS BEEN
ADVISED, KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES.

THE SOFTWARE PROGRAMS DESCRIBED IN THIS DOCUMENT ARE CONFIDENTIAL  INFORMATION
AND PROPRIETARY PRODUCTS OF APOLLO COMPUTER INC. OR ITS LICENSORS.















Reader_Notice

This  document resides on line in the /doc directory.  To print a copy of this
document, use  the PRF command with the -npag and -pr switches.

     prf <file_pathname> -pr <printer_name> -npag


















































                                     iii









                                   Contents



Section

CHAPTER 1 FEATURES OF DOMAIN TCP/IP SOFTWARE RELEASE 3.1

       1.1 Software Requirements. . . . . . . . . . . . . . . . . . . . . . . 1-1
       1.2 Startup Procedure. . . . . . . . . . . . . . . . . . . . . . . . . 1-1
       1.3 Improvements to Tcp_Server . . . . . . . . . . . . . . . . . . . . 1-1
       1.4 Improvements to Rip_Server . . . . . . . . . . . . . . . . . . . . 1-2
       1.5 Improvements to Setroute . . . . . . . . . . . . . . . . . . . . . 1-2

CHAPTER 2 INSTALLATION INFORMATION

       2.1 TCP/IP Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
       2.2 New Installation Information . . . . . . . . . . . . . . . . . . . 2-2
           2.2.1 Choosing a Target Node . . . . . . . . . . . . . . . . . . . 2-2
           2.2.2 Choosing a Source Area . . . . . . . . . . . . . . . . . . . 2-3
           2.2.3 Improved Error Checking and Verification . . . . . . . . . . 2-3
       2.3 TCP/IP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
           2.3.1 Common Files . . . . . . . . . . . . . . . . . . . . . . . . 2-4
           2.3.2 Administrative Files . . . . . . . . . . . . . . . . . . . . 2-5
           2.3.3 Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

CHAPTER 3 DOCUMENTATION

       3.1 Tcp_Server Usage . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
           3.1.1 Debug Switch . . . . . . . . . . . . . . . . . . . . . . . . 3-2
           3.1.2 Dynamic Routing Switch . . . . . . . . . . . . . . . . . . . 3-2
           3.1.3 Ping Switch. . . . . . . . . . . . . . . . . . . . . . . . . 3-3
           3.1.4 MAXTTL Switch. . . . . . . . . . . . . . . . . . . . . . . . 3-3
           3.1.5 Window Size Switch . . . . . . . . . . . . . . . . . . . . . 3-4
       3.2 Changes to Configuring and Managing TCP/IP . . . . . . . . . . . . 3-4
           3.2.1 Changes in the TCP/IP Initialization Procedure . . . . . . . 3-4
           3.2.2 Changes to Setroute. . . . . . . . . . . . . . . . . . . . . 3-5
           3.2.3 Changes to Rip_Server. . . . . . . . . . . . . . . . . . . . 3-6
           3.2.4 Domain Network Types . . . . . . . . . . . . . . . . . . . . 3-6
           3.2.5 Changes in TCP/IP Product Definitions. . . . . . . . . . . . 3-7
           3.2.6 Changes to Tcp_Server Switches . . . . . . . . . . . . . . . 3-7
           3.2.7 Additions to Makegate Description. . . . . . . . . . . . . . 3-7
           3.2.8 Changes to Tcpstat . . . . . . . . . . . . . . . . . . . . . 3-7
           3.2.9 New Definitions of Physical Interfaces for Network Devices . 3-8
           3.2.10 Comments in Local.Txt . . . . . . . . . . . . . . . . . . . 3-9
       3.3 Clarifications to Using telnet and ftp . . . . . . . . . . . . . . 3-9
           3.3.1 Option Support. . . . .. . . . . . . . . . . . . . . . . . . 3-9
           3.3.2 Transferred File Attributes. . . . . . . . . . . . . . . . . 3-9
       3.4 EtherBridge Requirement. . . . . . . . . . . . . . . . . . . . . . 3-11

CHAPTER 4 FIXES AND BUGS IN TCP/IP VERSION 3.1

      4.1 Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1



Contents                              iv









          4.1.1 Fixes for Data Corruption Problems. . . . . . . . . . . . . . 4-1
          4.1.2 Tcp_Server Improvements . . . . . . . . . . . . . . . . . . . 4-1
          4.1.3 Fixes for Routing Problems. . . . . . . . . . . . . . . . . . 4-2
          4.1.4 Fixes for Window Problems . . . . . . . . . . . . . . . . . . 4-2
          4.1.5 Fixes for Socket Problems . . . . . . . . . . . . . . . . . . 4-2
          4.1.6 Initialization Problems . . . . . . . . . . . . . . . . . . . 4-3
          4.1.7 UDP Problems. . . . . . . . . . . . . . . . . . . . . . . . . 4-3
          4.1.8 FTP Problems. . . . . . . . . . . . . . . . . . . . . . . . . 4-3
          4.1.9 Other Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . 4-3
      4.2 Bugs  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4


APPENDIX A FIXES AND BUGS IN VERSION 3.0

      A.1 Bugs in Version 3.0 . . . . . . . . . . . . . . . . . . . . . . . . A-1
      A.2 Bug Fixes Since Version 2.1 . . . . . . . . . . . . . . . . . . . . A-1








































Contents                              v
















                                  CHAPTER 1

                   FEATURES OF TCP/IP SOFTWARE VERSION  3.1





This chapter briefly describes the main features of the  TCP/IP   Version  3.1
software   release.    These   features  include  a  new  recommended  startup
procedure  and improvements to several TCP/IP  server  and  utility  programs.
Version  3.1  also  includes  significant performance enhancements.  Bug fixes
included in this release are described in Chapter 4.


1.1  Software Requirements


TCP/IP  Version  3.1  requires  SR9.7  for  proper  operation  of  tcpserver.
Specifically,  the  Version  3.1  software  contains  a modified SR9.7 streams
library, /lib/streams, which is necessary for all network send operations.


1.2  Startup Procedure


In order to overcome the  initialization  problem  of  TCP-based  servers  not
coming  up  properly  at node boot time, we recommend that you change the node
startup procedure to invoke tcpserver with cps -w from the DM  startup  file.
The  -w switch for the  cps command halts the DM until tcpserver has finished
initializing.  Section 3.3.1 of Chapter 3 of  this  document  includes  sample
command lines for the startup file.


1.3  Improvements to Tcp_server


Changes  to  tcpserver  include  the  addition  of  four  new switches, which
increase functionality of the server process,  a  new  syntax  for  specifying
switches  to  the  server,  and  delayed  acknowledgement for packets. The new
switches, which are described in greater detail  in Chapter 3, are:

     -r Initializes dynamic routing by  invoking  /sys/tcp/ripserver  and  by
        not  executing  /sys/tcp/makegate,  the program which creates a static
        internal routing table.




Version 3.1                          1-1                         Domain TCP/IP









     -p Sets the gateway ping interval in seconds.

     -t Sets the IP maximum TTL (time-to-live) parameter.

     -w Sets maximum receive window size.


The syntax change affects the previous -debug  and  -version  switches.   They
have  been  changed  to  -d  and  -v,  respectively,  and a space is no longer
allowed   between the debug switch and the value associated with  the  switch.
Tcpserver  now  forks  (i.e.,  detaches  from the window) after it is invoked
unless the -d switch is used.

In TCP/IP Version 3.1, delayed  acknowledgement  of  packets  is  the  default
condition.   In  Version  3.0,  each incoming packet caused an ACK to be sent.
In Version 3.1, the ACK is delayed  until the receiver can uncover 33% of  the
maximum  window  it  offers.   However,   in no case is the ACK delayed longer
than 0.25 seconds.

Finally, to run the Version 3.1 tcpserver,  you  must  use  the  /lib/streams
that is installed with Version 3.1.


1.4  Improvements to Rip_Server


Three  new switches have been added to ripserver.  For more information about
these switches, see Chapter 3 of this release document.  Ripserver  will  not
change or delete routes added with setroute.


1.5  Improvements to Setroute


Version  3.1  improvements  to  setroute  include commands to add priority and
default routes.  When setroute is used to specify routes,  we  recommend  that
you specify gateways by their local address rather than by name.



















Domain TCP/IP                        1-2                           Version 3.1
















                                  CHAPTER 2

                           INSTALLATION INFORMATION






You  can  add TCP/IP Version 3.1 to a user node (one equipped with monitor and
keyboard)  or to a Domain Server Processor (DSP) that is running  SR9.7  or  a
more  recent version of the Aegis or  Domain/IX operating system.  If the user
node or DSP is not  running  SR9.7  or  a  more  recent  version,  follow  the
appropriate  software  update  procedures  as  described  in Installing_Domain
Software (Order No. 008860) or in the appropriate release notes.

The user node or DSP must have a minimum of  1560  blocks  of  available  disk
space for a successful installation of this software.

NOTES:   TCP/IP  Version  3.1  requires  SR9.7,  or  a  more  recent
          version,   for    proper    operation    of    tcpserver.
          Specifically,   the  Version  3.1  tcpserver  contains  a
          modified SR9.7 lib streams file, which  is  necessary  for
          all network send operations.

          You  must  update  nodes  that  will  run  TCP/IP to SR9.7
          before you install Version 3.1.

          If a Domain node containing  the  EtherBridge  product  is
          being  used  as a TCP/IP gateway, all Domain nodes running
          TCP/IP on the 2 networks connected to the gateway must  be
          updated  to  at  least Version 3.0 of TCP/IP for the nodes
          to communicate through the gateway.   However,  we  highly
          recommend  that  you  update  all  your  TCP/IP  nodes  to
          Version 3.1.


For general instructions on how to install this  product,  see  Chapter  5  of
Installing__Domain__Software  which describes installation of optional product
software.









Version 3.1                          2-1                                TCP/IP









2.1  TCP/IP Queries


As part of the install of TCP/IP  Version  3.1,  you  must  know  whether  the
target   node   will   be   a   TCP/IP  administrative  node.   Domain  TCP/IP
administrative nodes have the /sys/tcp/hostmap  directory  installed  locally.
Refer  to  Chapter  3 of Configuring_and_Managing_TCP/IP for information about
configuring TCP/IP administrative nodes, hosts, and gateways.

If the target node will not be an administrative node, you must then know  the
path  name  of  the  administrative node that will be used by the target node.
The two questions asked in this install referring to this information are:

     Is the installation to //target_node
     a tcp administrative node install?
     Yes or no?:

If the answer is "yes," then the second question is not asked and the  install
proceeds  according to Chapter 5 of Installing_Domain_Software.  If the answer
is "no," then the second question is asked.

     Please enter the name of the TCP/IP ADMINISTRATOR node on which
     the /sys/tcp/hostmap DIRECTORY resides (e.g. //SERVER).
     Enter node name or type 'quit':

After you enter the pathname to  the  administrative  node,  the  installation
proceeds according to Chapter 5 of Installing_Domain_Software.

After  installing  the TCP/IP software for the first time and before rebooting
your node, you must edit the following files:

     o  /sys/tcp/thishost: add your node's name

     o  /sys/tcp/networks:  add your node's physical interfaces




2.2  New Installation Information


There have been  some enhancements made to the  installation  procedure  since
the  publication  of  the   last  revision  of  Installing_Domain_Software; we
describe those changes here.



2.2.1 Choosing a Target Node


The new installation sets the TARGET area  by  default  to  the  current  work
node.  When   you are prompted to enter a TARGET, the name of the current work
node appears as the default  and  can  be  selected  simple  by  pressing  the



TCP/IP                               2-2                           Version 3.1









<RETURN> key. For example:

    The TARGET is the node or subdirectory on which you are installing
    software (e.g., '//my_node' or '//my_node/subdirectory').
    Enter Target: <//sum>  <RETURN>

The program then confirms your choice of target.

    TARGET set to : //sum



2.2.2 Choosing a Source Area


When you choose a source area, the program now confirms your choice by displaying it
on the screen. For example:

    The SOURCE AREA is the node or subdirectory from which you are
    copying software (e.g., '//node' or '//node/subdirectory').
    Enter Source Area: //ergo

    SOURCE AREA set to : //ergo




2.2.3 Improved Error Checking and Verification


After  you  have  chosen the TARGET, the INSTALL program describes constraints
on  the installation  process,  and  asks  if  you  wish  to  see  a  list  of
directories  affected  by  those  constraints.  If  you  choose  to see such a
listing by typing 'yes' or 'y', the tool displays  the  list  immediately,  or
prints the message "No errors found." For example:

    NOTICE:
    Objects will not be installed across
    links, nor if unexpected objects currently
    exist where directories are needed.

    Would you like to see a listing of any
    problems of this sort before proceeding?
    Yes or No? y

    -------------------------------------------------
    Listing pathname errors found with TARGET set to  //sum
    (Please be patient)

    //sum/sys/help
    //sum/domain_examples

If  you  answered  the  question  above  with  a 'yes' or 'y', and the program



Version 3.1                          2-3                                TCP/IP









displayed one or more  'pathname  errors,'  the  program  now  describes   the
warning  messages  about  link objects that are generated during a later phase
of the installation. Enter 'yes' or 'y' at the  prompt  if  you  wish  to  see
error  messages  regarding installation of links. If you wish to suppress such
messages, enter 'no' or 'n.'

    The program displays a warning message
    whenever one of these objects is
    encountered during the installation,
    although the display of these messages
    can be suppressed.

    CAUTION : These objects will not be
    installed, whether or not the warning
    messages are displayed.

    Do you want to see the warning messages?
    Yes or No? y


2.3  TCP/IP Files


The following sections list the files and links that are  installed  during  a
TCP/IP Version 3.1 installation.


2.3.1 Common Files

The following files are installed on all TCP/IP nodes:

     //TARGET/com/ftp

     //TARGET/com/host

     //TARGET/com/tcpstat

     //TARGET/com/telnet

     //TARGET/doc/tcp.release_notes

     //TARGET/sys/help/ftp.hlp

     //TARGET/sys/help/host.hlp

     //TARGET/sys/help/tcpstat.hlp

     //TARGET/sys/help/telnet.hlp

     //TARGET/sys/tcp/ftp_server

     //TARGET/sys/tcp/makegate




TCP/IP                               2-4                           Version 3.1









     //TARGET/sys/tcp/maphost

     //TARGET/sys/tcp/networks_template

     //TARGET/sys/tcp/rip_server

     //TARGET/sys/tcp/setroute

     //TARGET/sys/tcp/tcpinit

     //TARGET/sys/tcp/tcpreset

     //TARGET/sys/tcp/tcp_server

     //TARGET/sys/tcp/telnet_server

     //TARGET/sys/tcp/thishost_template

     //TARGET/lib/streams

     //TARGET/systest/ssr_util/dtcb

     //TARGET/systest/ssr_util/mbd

     //TARGET/systest/ssr_util/sodebug

     //TARGET/systest/ssr_util/trpt



2.3.2 Administrative Files

The following files are installed on the TCP/IP administrative node:

     //TARGET/sys/tcp/hostmap/hashnic

     //TARGET/sys/tcp/hostmap/hosts.txt

     //TARGET/sys/tcp/hostmap/local.txt

     //TARGET/sys/tcp/hostmap/makehdb

     //TARGET/sys/tcp/hostmap/makehost.sh

     //TARGET/sys/tcp/hostmap/ndb_format

     //TARGET/sys/tcp/hostmap/sortnic









Version 3.1                          2-5                                TCP/IP









2.3.3 Links

The  installation  procedure  creates  the following links on user nodes.  The
new link, tcp_admin, is an indirect link to the  TCP/IP  administrative  node.
This  link  simplifies updating hosts if you change your TCP/IP administrative
node; you simply change this link instead of changing multiple  links  to  the
administrative node.

//ADMIN  indicates  the  administrative  node  that  you  specify  during  the
installation  procedure.  TARGET is the target  area  where  the  software  is
being installed.

            FROM                              TO

     TARGET/com/net                   TARGET/com/host
     TARGET/sys/tcp/tcp_admin         //ADMIN/sys/tcp
     TARGET/sys/tcp/gateways          tcp_admin/gateways
     TARGET/sys/tcp/host_addr         tcp_admin/host_addr
     TARGET/sys/tcp/hostmap           tcp_admin/hostmap
     TARGET/sys/tcp/hosts.hst         tcp_admin/hosts.hst
     TARGET/sys/tcp/networks          `node_data/networks
     TARGET/sys/tcp/thishost          `node_data/thishost


































TCP/IP                               2-6                           Version 3.1
















                                  CHAPTER 3

                                DOCUMENTATION





This  chapter  describes  the  usage  of  tcpserver and summarizes changes to
existing TCP/IP  documentation  caused  by  Version  3.1.   The  documentation
affected  includes  the user manuals  Configuring_and_Managing_TCP/IP (008543)
and Using_telnet_and_ftp (008667).  These manuals have not  been  revised  for
TCP/IP Version 3.1.

Configuring__and__Managing__TCP/IP  describes  how  to  configure, manage, and
troubleshoot Domain TCP/IP and Domain/IX BSD4.2 TCP/IP.

Using_telnet_and_ftp describes how to use two  common  TCP/IP  utilities:  the
TELNET  remote terminal emulator and the FTP file transfer program.  This book
describes both the Domain and Domain/IX versions of these utilities.


3.1  Tcp_Server Usage


Version 3.1 introduces four switches for  tcpserver  and  a  new  syntax  for
specifying switch  values.

Usage: tcp_server [-d<mask>] | [-w<window>]| -r<routing server>
       | -t | -u/-? | -v | [-p<time>]

     -d<mask>           Set debug mask (HEX).  See table below for mask values.
     -n                 Do not run tcpinit.
     -p<time>           Gateway Ping time in seconds. Value must be expressed in hex.
     -r<routing server> Initialize using dynamic routing (you must specify
                          /sys/tcp/rip_server).  Do not execute /sys/tcp/makegate.
     -t<ipttl>          Set IP max time-to-live. Value must be expressed in hex.
     -u/-?              Print this text.
     -v                 Print the TCP/IP version number.
     -w<window>         Set receive window size. Value must be expressed in hex.

NOTES:     The  -d  switch  is changed from -debug and the -v switch
          is  changed from -version. The previous versions of  these
          switches  are  documented   in  Configuring__and__Managing
          TCP/IP (008543).




Version 3.1                          3-1                                TCP/IP









          Tcpserver requires lower case switches.  Therefore,  when
          you  start   tcpserver  with  a  DM  command  (e.g.,  cps
          /sys/tcp/tcp_server), you must  enclose  the  switches  in
          quotes  to  prevent  the  DM from converting them to upper
          case.

The new  syntax  eliminates  the  space  between  the  switch  and  the  value
associated  with  the switch. The following command lines show the old and new
syntax to specify the tcp_server debug mask:

     New (Version 3.1): tcpserver -d0001

     Old (Version 3.0 and before): tcpserver -debug 0001



3.1.1 The Debug Switch.

This switch prevents tcp_server from  forking  and  requests  the  display  of
debugging  information  as  defined   by  the  16-bit  mask.   The table below
describes the debug information   that  can  be  requested.   Add  bit  values
together to request several types of information.

       Mask                   Information
     _________            _________________

     0001 (default)       General information
     0002                 IP level information
     0004                 ARP information
     0008                 TCP information
     0010                 Data in TCP packets
     0020                 UDP information
     0200                 Broadcasts
     1000                 TCP finite state machine information
     2000                 Device level information
     4000                 Additional detail at any level
     f0ff                 All available debug information
                          except broadcasts
     ffff                 All available debug information


3.1.2 The Dynamic Routing Switch

When you use the -r switch, tcp_server

     o  Invokes the routing server specified with the switch, and

     o  Does not execute /sys/tcp/makegate.


You  must  specify  the whole_pathname of /sys/tcp/ripserver with this switch
to invoke ripserver since the default is /etc/routed.




TCP/IP                               3-2                           Version 3.1









When you do not use the -r switch, tcpserver

     o  Executes tcpinit, which reads the file  /sys/nodedata/networks  whose
        entries  associate  the node's network addresses with network physical
        level interface  identifiers, and

     o  Executes makegate, which initializes  a static internal routing  table
        using the routing information in /sys/tcp/gateways.

        (On  nodes  running  Domain  TCP/IP,  the /sys/tcp/hostmap/makehost.sh
        shell script creates /sys/tcp/gateways.)


We recommend that you use dynamic routing on  TCP/IP  gateways  and  that  you
invoke  rip_server  separately from tcp_server in the startup file. For Domain
hosts, we recommend that you run rip_server with the -h option to   allow  the
hosts  to  gain  dynamic,  up-to-date routing information.  See section  3.2.1
below for examples of the command lines you should add  to  the  startup  file
`node_data/startup.<display-type>  to  invoke  these  processes  correctly and
section 3.2.2 for information about rip_server options.


3.1.3 The Ping Switch

The -p switch causes tcpserver to send ICMP echo requests, at  the  specified
interval,  to gateways which are in use by open connections on that device, to
determine whether they are functioning.

Using the -p switch can help to establish which  gateways  are  available  and
to   convey  information  about unavailable gateways to the routing table.  At
the specified interval, tcpserver  issues  an  ICMP  echo  request  to  every
gateway  in  use by an active connection on that device.  After three requests
with no response, the gateway is  'pinged out' and it  is moved to the end  of
the  routing  table.  Tcpserver  then  uses  an  alternate  route   if one is
available.

The Version 3.1  tcpserver  allows  you  to  specify  the  ping  interval  in
seconds.  The default value is 4 seconds.  You may set the time to 1 second to
help trace a failing gateway or to improve  routing performance  when  gateway
failures  are  frequent.   You  may inhibit pinging altogether by specifying a
0-second interval.


3.1.4 The MAXTTL Switch

The  Version  3.1  tcp_server  supports  a  -t  switch  to  set   IP   maximum
time-to-live   (MAXTTL)  to  any  desired  value.  The  maximum   time-to-live
indicates how long a TCP/IP packet will continue  to  be  transmitted  through
the  network.   In  Version  3.0,  the IP MAXTTL parameter  default was 10; in
Version 3.1, the default is 30.  Most TCP/IP implementations treat  MAXTTL  as
a  hop-count  and  decrement  the  TTL  field  in  packet  headers  by  1 when
forwarding packets.  Thus, in effect, the new default means that a packet  can
be transmitted across 30 gateways (or hops) before it will be discarded.



Version 3.1                          3-3                                TCP/IP









3.1.5 The Window Size Switch

With  Version  3.1,  users can set a maximum offered window size. This feature
allows for interoperation with  third  party  vendor  network  devices,  e.g.,
gateways,   routers,  bridges,  and  repeaters.  The  tcpserver  process  now
accepts a -w argument, so that the user can reduce the maximum offered  window
size.  The  default  value  is  0x23B0  bytes.  The  user can set the value to
between 0x800 and 0x23B0 bytes. We recommend that  users  who  desire  maximum
throughput  on their TCP/IP connections use the default maximum offered window
size. In some cases where  users  are  experiencing  buffering  problems  with
third-party  repeaters,  it may be useful to reduce the maximum offered window
size by using the -w switch.

NOTE:     Exercise care in using this  switch.   We  recommend  that
          you  do  not  offer  a window size less than 0x1000 bytes,
          unless your  Apollo  service  representative  advises  you
          otherwise.



3.2  Changes to Configuring_and_Managing_TCP/IP


This   section   contains  new  information  about  the  TCP/IP  products  and
configuring  procedures.  The  information  in  this  section  supercedes  the
information  in  Configuring__and_Managing_TCP/IP, Revision 01. Keep a copy of
these pages with the manual for reference.


3.2.1 Changes in the TCP/IP Initialization Procedure

Page 4-6 of the Configuring_and_Managing_TCP/IP manual  contains  instructions
for  editing the DM startup file on each host to start /sys/tcp/tcp_server and
other TCP/IP servers.

At  TCP/IP  Version  3.1,  tcpserver   now   detaches   from   the   invoking
window/process   after  it  completes  its  initialization.  This  change  was
introduced to fix the initialization problem of TCP-based servers  failing  to
come up properly at node boot time.

Invoke    tcpserver   from   the   DM   startup   file   (`node_data/startup.
<display-type>) using cps -w  which  suspends  the  DM  until  tcpserver  has
finished  initializing.    Do__not use the tcpserver -d switch in combination
with cps -w or you will_hang_the_node. For example,

     cps -w /sys/tcp/tcp_server

Tcpserver now forks and names the child process  tcpserver.   Therefore,  do
not use cps -n to name the process.

The  following  are  examples  of  command  lines  that  can  be added  to the
`node_data/startup.<display-type>  file.   Add  the  appropriate   lines   and
uncomment the command lines.



TCP/IP                               3-4                           Version 3.1










The  tcpserver  command line example below  starts the tcpserver process but
uses the tcpserver -n command to suppress initialization; tcpinit is  invoked
on  a  separate  line.  Note  that  tcpserver  switches should be enclosed in
quotes to preserve lower case.

For hosts and gateways that will run ripserver,  use  the  following  command
lines:

     # for a host or gateway that WILL run rip_server
     cps -w /sys/tcp/tcp_server '-n'
     cps -w /sys/tcp/tcpinit
     #
     # invoke rip_server AFTER tcp_server and tcpinit  (add -h option for hosts)
     cps -w /sys/tcp/rip_server
     #
     # for all hosts that needs telnet and ftp services
     cps /sys/tcp/telnet_server
     cps /sys/tcp/ftp_server
     #

For  hosts  and  gateways  that  will__not  run  ripserver, use the following
command lines:

     # for a host or gateway that will NOT run rip_server
     cps -w /sys/tcp/tcp_server
     #
     # for all hosts that needs telnet and ftp services
     cps /sys/tcp/telnet_server
     cps /sys/tcp/ftp_server
     #


NOTE:     Do not use the cps -w switch  when  invoking  the  Version
          3.0 tcpserver.  It will cause the node to hang.



3.2.2 Changes to Setroute

The  command  /sys/tcp/setroute  is  described on page B-10 of Configuring_and
Managing_TCP/IP.  At Version 3.1, two commands have been added to setroute  to
allow priority and  default routes to be added to the routing table.

Usage: /sys/tcp/setroute [-f] [-n] cmd [net | host] gate [metric]


NOTES:    Setroute requires you to supply a non-zero metric value.

          When  adding  routes  to  the routing table with setroute,
          specify the gateway by means of  its  IP  address  on  the
          local network, not by its logical name.




Version 3.1                          3-5                                TCP/IP









The  new  commands  added  at  Version  3.1  are  listed  below.  Routes added
manually by setroute cannot be deleted by ripserver.

     add default      Add  the  specified  gateway   as   a   default   route.
                    Tcpserver  uses  the  default  route  when  other  routes
                    occuring earlier in the routing table have  failed  or  if
                    no other possible route exists. To add a default route:

                    /sys/tcp/setroute add default gatewayaddress [metric]

     addp             Add the   specified   gateway   as   a  priority  route.
                    Tcpserver uses priority routes before default  routes  or
                    routes  established by ripserver. A route added with addp
                    will appear  first   in  the  gateway  table  when  it  is
                    displayed with tcpstat -g.  To add a priority route:

                    /sys/tcp/setroute addp gatewayaddress [metric]



3.2.3 Changes to Rip_Server

Three  new  switches  have been added to ripserver to improve performance and
facilitate debugging.

Usage: ripserver [-s] [-q] [-t] [-g] [-n] [-f] [-h] <logfile>

The three new switches added at Version 3.1 are:

     -n Directs ripserver not to  install  changes  into  the  local  routing
        table.   However,   the   ripserver   process  continues  to  receive
        broadcasts from other ripserver processes.   The  -n  switch  is  for
        debugging purposes.

     -f Directs  ripserver  at  startup  to flush (purge) all routes from the
        local routing table  except routes added manually with setroute.

     -h Stops the ripserver process after the routing table  has  stabilized.
        Use  the  -h  option  on  hosts  only.  Gateways must continuously run
        ripserver to update routing tables.



3.2.4 Domain Network Types

Configuring_and_Managing_TCP/IP assumes that a Domain  network  is  an  Apollo
Token  Ring  network (ATR). As of SR9.6, a Domain network can be either an ATR
or an IEEE 802.3 network (commonly called  an  ETHERNET  network).   For  more
information  about  IEEE  802.3  networks,  see  Planning__Domain_Networks_and
Internets (009916).






TCP/IP                               3-6                           Version 3.1









3.2.5 Changes in TCP/IP Product Definitions

Prior to release 3.0, Domain TCP/IP provided driver software for  the  gateway
node's   multibus  ETHERNET  controller.  Since  TCP/IP  Version  3.0,  driver
software has not shipped with the TCP/IP software.  All driver software,  with
the  exception   of  the  EtherController-MB,  is  now an integral part of the
standard software release.

EtherController-MB driver software is shipped with  the  controller.  See  the
EtherController-MB  Release Document (009743) for information about installing
that software.

This change obsoletes the information on pages 3-4 and 3-5 of Configuring__and
Managing_TCP/IP.


3.2.6 Changes in the Tcp_server -Debug and -Version Switches

The  tcpserver  -debug  and  -version switches  are now -d<mask> and -v. Note
that there is no longer a space between the switch and  the  bit  value  mask.
The  functionality of these switches remains the same. The -debug and -version
switches  are described on pages 7-3 and 7-5.


3.2.7 Addition to Makegate Description

The makegate command is described on page  B-4  of  Configuring__and__Managing
TCP/IP.   The  following paragraph is a further clarification of the operation
of this command.

Makegate only accepts lines in the /sys/tcp/gateways file that describe  local
gateways.    Local  gateways  are  gateways running on the same network as the
node running makegate.  Makegate discards lines  describing  remote  gateways.
Remote  gateways  are  one or more hops  away from the node running makegate).
Remote gateway information is picked up by the node via ripserver.


3.2.8 Changes to Tcpstat

Flags which indicate the status of available routes   have  been  defined  for
tcpstat.   The  flags  are  displayed when the command is executed with the -g
option.  The flags are:

     U  Indicates the route is up.

     G  Indicates the route is to a gateway.

     D  Indicates route was created dynamically by a redirect.

     P  Indicates priority route.

     S  Indicates static route added explicitly with route.




Version 3.1                          3-7                                TCP/IP









     X  Route marked for deletion.


In addition, when you execute tcpstat -i, a new flag is displayed in the  STAT
field.   The  flag  N  indicates  that the physical interface is to a "native"
(i.e., Domain) network. The other  flags  displayed  with  this  command   are
described on page 7-10 of Configuring_and_Managing_TCP/IP.



3.2.9 New Definitions of Physical Interfaces for Network Devices

On  page  3-6  of  Configuring__and__Managing_TCP/IP there are descriptions of
network physical interfaces and the way in which they are specified  for  each
node  in  its `/node_data /networks file. These descriptions have changed with
the introduction of the IEEE 802.3 network as a Domain network type  and  with
the  implementation  of  shared  routing and gateway applications  on a single
network controller.

Please note the following changes to the descriptions on page 3-6:

dr0, dr1       Specify Apollo Token Ring  (Domain  ring)  interfaces.   A  drn
               interface  can be a pre-SR9.6 Apollo Token Ring  controller, an
               A-NET-ATR, an IIC in a Domain/Bridge -A or -B  con  figuration,
               or  a  COM-ECMB  controller.  The COM-ECMB controller is always
               dr1 in an EtherBridge Domain router configuration.

eth0, eth1     Specify IEEE 802.3 Network  (ETHERNET)  interfaces.   The  ethn
               interface  can be an A-ADD-ETH, an A-NET-ETH, a V-NET-ETH, or a
               COM-ECMB controller. The COM-ECMB controller is always eth0  in
               a TCP/IP gateway configuration.

DN3000/DN4000  nodes  can  contain  a maximum of four network controllers, but
only two of the  same  network  type.  Thus,  you  can  have  a  gateway  that
contains  two  Apollo Token Ring Controllers and two 802.3 Network Controllers
(dr0, dr1, eth0, and eth1), for example:

     129.9.3.023 on dr0   ; Apollo Token Ring
     130.1.2.023 on dr1   ; Apollo Token Ring
     149.8.5.023 on eth0  ; ETHERNET
     150.2.3.023 on eth1  ; ETHERNET

A DSP90 gateway connected to an Apollo Token  Ring  and  an  ETHERNET  network
through   the   EtherBridge   product   would  appear  in  the  networks  file
/sys/node_data[.node_id]/networks as follows:

     197.9.8.11 on dr0  ; Apollo Token Ring
     149.8.5.023 on dr1 ; EtherBridge

Note that the dr1 interface can also apply to a Domain/Bridge-A or -B link  or
to a second Apollo Token Ring network.





TCP/IP                               3-8                           Version 3.1









NOTE:    If   you  have  a  node  with  an  EtherController-MB,  the
          controller's device definition file (DDF)  must  be  named
          /sys/dev/ethernet0  in  order for TCP/IP to run  correctly
          on that node. If the DDF file does  not  have  that  name,
          change  the  name  of  the  DDF  using  the chn command or
          rebuild the DDF after you  have  installed  SR9.7.    This
          information  does  not  apply to nodes with AT- or VME-bus
          controllers since they no longer require DDFs.



3.2.10 Comments in Local.txt

Table 3-5 on Page 3-11 of Configuring_and_Managing_TCP/IP should specify  that
you  must  place each comment on a separate line that begins with a semicolon.
Do not place semicolons on lines with host and  gateway  entries.   Also  note
that the first three lines of the local.txt file must be comment lines.

Place each comment on a separate line, as shown in the following example:

     NET :  197.6.3.0 :  OFFICE-ETHERNET  :
     NET :  197.9.8.0 :  ATR  :
     GATEWAY  : 197.9.8.1,197.6.3.8 : JANUS,APOLLO : DN460 : AEGIS : IP/GW, GW/PRIME :
     ; The tcp_server software loopback connector
     HOST  :  127.0.0.1  : LOCALHOST  : : :
     ; The following are hosts on the ATR
     HOST : 197.6.3.15 : BACCHUS : DN4000 : DOMAIN/IX : TCP/TELNET, TCP/FTP
     ; This is the only host on ATR
     ; The following are hosts on the ETHERNET

NOTE:     Page    3-27   in   the   manual   Managing___TCP/IP-Based
          Communications_Products incorrectly states  that  comments
          can  follow  entries  on  the  same  line.   Comments  and
          semicolons must appear on separate lines.



3.3  Clarifications to Using_telnet_and_ftp




3.3.1 Option Support

The telnet -t option described on page 2-8 of Using__telnet__and__ftp  is  not
supported.


3.3.2 Transferred File Attributes

The  Domain  ftp  (/com/ftp)  allows you to specify four types of data  format
(ascii, binary, image,and local) and two file structures  (file  and  record).
The  attributes of transferred files will differ depending  on how you use the



Version 3.1                          3-9                                TCP/IP









Data Transfer Specification Commands and whether you are talking to the  Aegis
ftp server, /sys/tcp/ftp_server, or to the UNIX server, /etc/ftpd.

/com/ftp   processes   the  Type  command  to  be  compatible  with  BSD  UNIX
implementations of the ftp server.  That is, although you can  specify  binary
format  with  the  Type  command,   and  the local host will treat the data as
binary, /com/ftp sends a Type image command to the remote server,  since  UNIX
ftp servers usually do not  understand binary format type.

This  action by /com/ftp results in non-symmetrical treatment of files between
the local and  remote hosts running /sys/tcp/ftp_server when you use the  Type
binary  command.   When  you  get a file (and the file is created by the local
host which thinks the format is binary), the resulting file  will  be  an  obj
file.  When  you send a file, however, (and the file  is created by the remote
host which thinks the format is image) the  resulting  file  will  be  a  uasc
file.   You  must  use  the Type local command in order to send obj files to a
/sys/tcp/ftp_server.

The following table describes the file attributes of  transferred  files  that
will   result   from  various  combinations  of  the  /com/ftp  Data  Transfer
Specification Commands when the  files  are  transferred  by  a  node  running
/com/ftp,   from   or   to  a  remote  node  running  the  Aegis  ftp  server,
/sys/tcp/ftp_server.


        Data Transfer    ||           Resulting File Attributes
      Specification Cmds ||  With Get Command     ||    With Send Command
     --------------------||-----------------------||----------------------
     Structure|   Type   ||Ascii/Bin Flag|  Type  ||Ascii/Bin Flag|  Type
     ---------|----------||--------------|--------||--------------|-------
              |  Ascii   ||    ascii     |  uasc  ||    ascii     |  uasc
              |----------||--------------|--------||--------------|-------
              |  Binary  ||     bin      |  obj   ||    ascii     |  uasc
        File  |----------||--------------|--------||--------------|-------
              |  Image   ||    ascii     |  uasc  ||    ascii     |  uasc
              |----------||--------------|--------||--------------|-------
              |  Local   ||     bin      |  obj   ||     bin      |  obj
     =====================================================================
              |  Ascii   ||    ascii     |  uasc  ||    ascii     |  uasc
              |----------||--------------|--------||--------------|-------
              |  Binary  ||     bin      |  rec   ||    ascii     |  rec
       Record |----------||--------------|--------||--------------|-------
              |  Image   ||    ascii     |  rec   ||    ascii     |  rec
              |----------||--------------|--------||--------------|-------
              |  Local   ||     bin      |  rec   ||     bin      |  rec
     ---------|----------||--------------|--------||--------------|-------


The  Domain/IX  ftp  (/usr/ucb/ftp)  Data  Transfer  Specification   Commands,
however,  allow  you  to  specify  four  types  of data format (ascii, binary,
image, and local) but only one file structure (file).  Ftp and ftpd  use  this
information  for file transfer optimization only.  Since UNIX does not support
typed files in the Aegis sense,  all  transferred  files  have  the  following



TCP/IP                               3-10                          Version 3.1









attributes:

     Ascii/Binary Flag = ascii
     Type = uasc


3.4  EtherBridge Requirement


EtherBridge  nodes  with  the dr1 interface normally route Domain packets over
the ETHERNET to another EtherBridge node with a  dr1  interface.   EtherBridge
nodes  configured  as  TCP/IP  gateways  with an eth0 interface normally route
TCP/IP packets to a host on the ETHERNET with an eth0 interface.

Domain packets dr1  ---> dr1
TCP/IP packets eth0 ---> eth0

Because both the dr1  and  the  eth0  interfaces  are  attached  to  the  same
physical  ETHERNET, you can assign the same IP address to both the dr1 and the
eth0 interfaces.  In this case, however, TCP/IP packets may interpret the  dr1
interface  as  a  gateway  to  the ETHERNET. To ensure that TCP/IP packets are
properly routed through the eth0 interface, assign a  unique  IP  address   to
the EtherBridge link.

The EtherBridge link in the figure below has it own IP address: 192.3.8.

                     TCP/IP
                      Host
                     dr0 192.3.1
                    ___|___
                   /       \
                  /  ring   \
                 |  192.3.1  |
                  \         /
                   \_______/                   TCP/IP
       dr0 192.3.1 EB   GW dr0  192.3.1         Host
       dr1 192.3.8  |   |  eth0 192.3.3         eth0 192.3.3
                ____|___|________________________|______
                               |         ETHERNET
                   dr1 192.3.8 |     192.3.3
                   dr0 192.3.2 |
                            ___EB__
                           /       \
                          /  ring   \
                         |  192.3.2  |
                          \         /
                           \_______/









Version 3.1                          3-11                               TCP/IP
















                                  CHAPTER 4

                     FIXES AND BUGS IN TCP/IP VERSION 3.1





This  chapter  describes  fixes  and  bugs in Version 3.1.  See Appendix A for
fixes and bugs in Version 3.0.


4.1  Bug Fixes


This section describes the bug fixes included in Version 3.1.  The  fixes  are
divided into several general topics.


4.1.1 Fixes for Data Corruption Problems


     o  Data  corruption problems caused by a faulty repacketization algorithm
        have been corrected. These problems occurred infrequently  during  the
        transfer  of  large  files  over noisy networks to some other vendors'
        equipment.



4.1.2 Tcp_Server Improvements


     o  The Version 3.1  tcpserver  process  is  more  robust  and  will  not
        crash.

     o  A  performance  improvement  that  removed  a  data  copy was added to
        tcpserver.

     o  We  now  have  Maximum  Time-To-Live  (MAXTTL)   and   ping   interval
        parameters for tcpserver  that can be specified by the user.

     o  We  now correctly handle Internet Type A addresses when the first byte
        is 10 or 3 and  the second byte is non-zero.






Version 3.1                          4-1                                TCP/IP









4.1.3 Fixes for Routing Problems


     o  Ripserver now correctly handles broadcast packets.

     o  Routing code caused  incorrect  routing  table  entries  for  gateways
        between  networks  with  different  address  masks  (e.g., Class A and
        Class B)  or  between  subnetted  and  non-subnetted  networks.   This
        problem has been fixed.

     o  The routing table now handles up to 512 routes.



4.1.4 Fixes For Window Problems


     o  We  no  longer  timeout  a  connection when the remote host is sending
        0-windows.

     o  We now send one-character data packets, known as 0-window  probes,  at
        intervals which range from 2 to 30 seconds.

     o  We now ACK 0-window probes.



4.1.5 Fixes to Socket Problems


     o  The  problem  of  user  applications  (e.g.,  ftp,  telnet) hanging or
        crashing when tcpserver needed to manage  large  numbers  of  sockets
        quickly has been fixed.

     o   Socket connections no longer hang on client nodes.

     o  A  bug in Version 3.0 that affects error status returns from socket(2)
        calls has been fixed in Version 3.1. (This bug fix  first  appeard  in
        SR9.6.)  Some transient errors were returned more than once in Version
        3.0.  In Version 3.1, transient errors  are  returned  by  the  socket
        interface  only  once.   Permanent  error  conditions  are reported on
        every call.

     o  Version 3.1 allows a program to  reconnect  to  a  connected  datagram
        socket.   The  socket  is reconnected to the new target socket address
        (sockaddr).  However, a second connect(2) to a stream  socket  returns
        an error.  (This feature first appeard in SR9.6)









TCP/IP                               4-2                           Version 3.1









4.1.6 Initialization Problems


     o  The  problem  of  properly synchronizing the startup of TCP/IP servers
        was partially fixed by causing  the  tcpserver  to  detach  from  the
        window  at startup. To ensure proper initialization, users must change
        their startup files as suggested in Section 3.3.1 of this document.



4.1.7 UDP Problems


     o  A bug in Version 3.0 that affects IP User Data Protocol  (UDP)  -based
        server  processes (such as routed and rwhod) has been fixed in Version
        3.1.  This bug caused some incoming UDP  datagrams  to  be  discarded,
        even  though  a  socket  was  open  on  the  port  to  which they were
        addressed, if the process  owning the socket was calling  sendto()  at
        the time the incoming datagrams arrived.

     o  UDP reads and writes up to 8K bytes are now allowed.



4.1.8 FTP Problems


     o  Bugs that caused ftp sessions to hang have been fixed.

     o  Hash  marks  are  now printed during data transfer when requested with
        the ftp hash option.

     o  Using the ftp command mget to get non-existent files no longer  causes
        ftp to crash.



4.1.9 Other Bug Fixes


     o  The  socket  ioctls  for  SIOCGPGRP  (get process group) and SIOCSPGRP
        (set process group) do not work at TCP/IP Version  3.0.   The  process
        group  is  not  set or returned correctly.  Use of the SIOCGPGRP ioctl
        actually  returns  to  the  caller  8  bytes  of   information   which
        improperly  overwrites  part  of the caller's data area.  These ioctls
        are fixed in TCP/IP Version 3.1.

     o  You can now receive asynchronous notification of pending  input  on  a
        socket by  establishing a signal handler for SIGIO.  You must call

                 ioctl (s, FIOASYNC, &on)

        Note  that fcntl (s, F_SETFL, FASYNC) does not work.  You must use the



Version 3.1                          4-3                                TCP/IP









        ioctl so that  input on the socket generates the SIGIO signal.

     o  TCP/IP now accepts all valid broadcast addresses.

     o  /sys/tcp/setroute supports gateway.g_flags GWSTATIC, GWPRIMARY

     o  In Version 3.1, large ICMP  packets  (e.g.  ICMP  echo  requests)  are
        fragmented as required.

     o  Version  3.1  recognizes  the "dr1" physical interface type.  This fix
        allows  Version  3.1  to  support  TCP/IP   in   a   Domain   internet
        environment.   This  capability  was not properly supported in Version
        3.0.  See Chapter 3 for descriptions of the physical interfaces.

     o  Multiple problems that caused X windows to hang have been fixed.

     o  Bug that caused tcpreset hang has been fixed.

     o  Bug that caused TCP to hang if you <ctrl>-Q'd out of  an  FTP  session
        has been fixed.

     o  A  DSEE  bug  has  been  fixed  in  this  release  of TCP/IP software.
        Interbase users who used DSEE to build  software  received  the  error
        message  "EOF  reached  but  not  expected"  from  the  Interbase GFRE
        pre-processor while  building  a  reserved  element.   This  has  been
        fixed.

     o  Htable now handles the new, larger NIC tables.



4.2  Bugs



     o  Under   tcp3.1,   urgent  data  is  not  handled  correctly  on  LOCAL
        connections, i.e. on connections to an address assigned to one  of  my
        local  interfaces.   Urgent  data  to address 127.0.0.1, LOCALHOST, is
        handled correctly.  This will be fixed in an upcoming release.

     o  When a telnet connection is made to a Cray 2 computer  from  an  Aegis
        or  Unix  window,  keystrokes  are not echoed unless you use the VT100
        emulator.

     o  When the Aegis ftp and telnet server processes are started  on  a  DSP
        (running  spm  instead  of dm), they have an extra uid associated with
        them.

     o  You must set the acls on /sys/node_data  so  that  files  get  created
        with   open   acls.    If  your  sys/node_data  acls  are  restricted,
        /sys/tcp/tcp_server will not be able to create necessary data files.





TCP/IP                               4-4                           Version 3.1

































































Version 3.1                          4-5                                TCP/IP
















                                  APPENDIX A

                        FIXES AND BUGS IN RELEASE 3.0





This appendix documents known  bugs  and  fixes  in  the  Version__3.0__TCP/IP
product for the benefit of users updating to Version 3.1 from Version 2.1.


A.1  Bugs in TCP/IP Version 3.0 Software


The following bugs existed in the TCP/IP Version 3.0 software:

     o  If  you  send  two  telnet  ip  (^ip)  commands  in  a  row,  with  no
        intervening input,  the second one is received by the foreign host  as
        the character 't'.

     o  The  telnet  ^S  sequence  and  ^Q  sequence  do not work well because
        Domain TCP/IP allows the remote system to transmit up to 8K  bytes  of
        data at a time for performance reasons.



A.2  Bug Fixes Since Version 2.1


The following TCP/IP bugs have been corrected since TCP/IP Version 2.1:

     o  Version  3.0 supports Trailer Encapsulations as defined by Request for
        Comment (RFC) 893, so you can communicate with TCP/IP  implementations
        that  support  trailers. This version corrects a problem with trailers
        that occurred in Version 2.1.

     o  Prior to this release, the telnetserver and ftpserver would try   to
        initialize  before  the  tcpserver started running and so the servers
        failed  to  start.    Version   3.0   corrects   this   problem.   The
        telnetserver  and  ftpserver   now  wait until tcpserver is running
        before they start initializing.

     o  The telnetserver now negotiates echo switches correctly.

     o  Version 3.0 fixes a problem with the telnetserver that caused  it  to



Version 3.1                          A-1                                TCP/IP









        hang  if  you  tried  to  log  in to a Domain TCP/IP node,  but exited
        before you completed the log in procedure.

     o  Prior to this release, if you passed a bad data buffer  address  to  a
        get   or    put  operation,  the  tcpserver  would  hang  and  become
        unuseable. Version 3.0 corrects this problem.

     o  telnet  now  exits  (correctly)  when  the  other  side   resets   the
        connection.

     o  If  you  logged  in from a remote host to a Domain node running Domain
        telnet and then tried to run in a C shell, the  C  shell  would  hang.
        Version 3.0 corrects this.

     o  If  you  logged in to a remote system using telnet, and the other side
        sent null  characters, the null characters would show up as  triangles
        on  our  side.  Version  3.0 now ignores null characters, so you won't
        see any triangles.

     o  Version 3.0 can now handle TCP/IP windows larger than 32K bytes.

     o  The ripserver would sometimes stop  working  properly  after  it  had
        been  running for a while.  That is, it would be running, but wouldn't
        do anything. Version 3.0 corrects this.

     o  Conditional put operations of  4K  bytes  or  more  wouldn't  work  at
        times. Version 3.0 corrects this.

     o  For  BSD4.2 TCP/IP users, you can now specify a backlog of 0 in a call
        to listen().  This is equivalent to setting a backlog of 1.


























TCP/IP                               A-2                           Version 3.1




Typewritten Software • bear@typewritten.org • Edmonds, WA 98026