The Datafile PD-CD 5/DATAFILE_PDCD5.iso/internet/arcuserman/USERMAN

Text File | 1992-03-23 | 269.0 KB | 6,264 lines

                        The KA9Q Internet Software Package









                          Updated for 890421.1 Revision

                                   May 8, 1989












                                        by

                               Bdale Garbee, N3EUA



                         Copyright 1989 by Bdale Garbee.
                               All Rights Reserved.

                     This Document may be reproduced in whole
                    or in part for any non-commercial purpose,
                      as long as credit is given the author.
















                                      - 2 -


                                  Caveat Emptor

     This document is a major rewrite of the document included with  871225.0
     release  of the KA9Q package, but it is in the author's opinion very far
     from perfect. I believe that the bulk of the material here is  factually
     correct,  but the formatting is rough, and there are no doubt some juicy
     tidbits missing that should have been included.

     I would greatly appreciate reports of problems with  the  documentation,
     particularly  if  they are accompanied by suggested fixes!  I promise to
     back up the document sources this time  around,  so  that  disk  crashes
     won't  force  me to start over from scratch (which is what happened this
     time...).

     If you have comments or suggestions about the documentation, contact  me
     via  email  at  [e-mail]  on the Internet, ...!winfree!bdale via
     UUCP, or as 76430,3323 on Compuserve.

     My profound thanks to the folks who contributed to this release, partic-
     ularly Bob Hoffman N3CVL and Ron Henderson WA7TAS, without whom it would
     have been impossible.
                                                          Bdale Garbee, N3EUA









































                                      - 3 -


     1.  Introduction to TCP/IP and the KA9Q Software

     This document describes the KA9Q Internet Package, which is an implemen-
     tation  of the network protocol family originally created as part of the
     Arpanet project. The protocol family is commonly refered to as "TCP/IP",
     acronyms for two of the many protocols included.

     The KA9Q package is the result of several years of development  by  Phil
     Karn,  KA9Q,  and  his "merry band of implementors". The "TCP group" has
     grown to include hundreds of individuals worldwide, many  of  whom  have
     contributed  ideas  and  software to this release. All of the sources to
     the software are included, and  interested  parties  are  encouraged  to
     experiment  and  contribute changes resulting from their efforts back to
     the group. This is discussed further in the technical appendix.

     1.1.  An Overview of the TCP/IP Protocol Family

     Following is an overview of the protocol family supported  by  the  KA9Q
     package.   While reading this section will give you a wonderful overview
     of what's going on, you can feel free to skip ahead and try out the pro-
     gram  first,  then  come  back  and  read this section to flesh out your
     understanding.

     1.1.1.  Acknowledgement

     The material in this section was adapted  from  a  document  written  by
     Charles L. Hedrick, of RUTGERS, The State University of New Jersey.  The
     original document was Copyright 1987 by  Charles  L.  Hedrick,  and  the
     material excerpted for this section is used by permission.

     1.1.2.  Introduction

     This document is a brief introduction to TCP/IP, followed by  advice  on
     what  to  read  for more information. This  is  not  intended  to  be  a
     complete  description. It  can  give  you   a  reasonable  idea  of  the
     capabilities  of  the  protocols. But if you need to know any details of
     the  technology, you  will  want  to  read   the   standards   yourself.
     Throughout  the  text, you will find references to the standards, in the
     form of "RFC" or "IEN" numbers. These are document  numbers.  The  final
     section  of  this   document  tells  you how  to  get  copies  of  those
     standards.

     1.1.3.  What is TCP/IP?

     TCP/IP  is a set of protocols developed to allow  cooperating  computers
     to share resources across a network. It was developed by a  community of
     researchers centered around the ARPAnet. Certainly the  ARPAnet  is  the
     best-known  TCP/IP  network. However as of June, 87, at  least  130 dif-
     ferent  vendors  had products that support TCP/IP, and thousands of net-
     works  of  all  kinds  use  it. Over time, the original ARPAnet has been
     phased out, and is being replaced by a variety of networks  running  the
     same protocols loosely referred to as "The Internet".

     First some basic definitions. The most accurate name for  the   set   of









                                      - 4 -


     protocols we are describing is the "Internet protocol suite". TCP and IP
     are two of the protocols in this  suite.   (They   will   be   described
     below.)  Because  TCP and IP are the best known of the protocols, it has
     become common to use the term TCP/IP or IP/TCP  to  refer  to  the whole
     family.  It  is probably not worth fighting this habit. However this can
     lead to some oddities. For example, I  find  myself  talking about   NFS
     as  being  based  on  TCP/IP, even though it doesn't use TCP at all. (It
     does use IP. But it  uses  an  alternative  protocol,  UDP, instead   of
     TCP.  All  of  this  alphabet  soup will be unscrambled in the following
     pages.)

     The Internet is a  collection  of  networks,  including   the   Arpanet,
     NSFnet,  regional  networks such as NYsernet, local networks at a number
     of University and research institutions,  and  a  number   of   military
     networks.  The  term  "Internet" applies to this entire set of networks.
     The subset of them that is managed by the  Department  of   Defense   is
     referred   to   as  the "DDN" (Defense Data Network). This includes some
     research-oriented networks, such as  the  Arpanet,  as  well   as   more
     strictly  military  ones. (Because much of the funding for Internet pro-
     tocol developments is done via   the   DDN   organization,   the   terms
     Internet  and  DDN  can  sometimes  seem  equivalent.) All of these net-
     works are connected to each other. Users can  send  messages   from  any
     of  them  to  any other, except where there are security or other policy
     restrictions on access. Officially  speaking,   the   Internet  protocol
     documents   are   simply  standards  adopted  by  the Internet community
     for its own use. More recently, the Department   of   Defense  issued  a
     MILSPEC  definition  of  TCP/IP.  This  was intended to be a more formal
     definition, appropriate for use in  purchasing  specifications.  However
     most  of  the  TCP/IP community continues to use the Internet standards.
     The MILSPEC version is intended to be consistent with it.

     Whatever it is called, TCP/IP is a family of protocols.  A  few  provide
     "low-level"  functions  needed  for many applications. These include IP,
     TCP, and UDP. (These will be described in a bit  more   detail   later.)
     Others  are  protocols for doing specific tasks, e.g. transferring files
     between computers, sending mail, or finding out who is  logged   in   on
     another    computer. Initially  TCP/IP  was  used  mostly  between mini-
     computers or mainframes. These machines had their own disks,   and  gen-
     erally   were  self-contained.  Thus  the  most  important "traditional"
     TCP/IP services are:

        - file transfer.  The file transfer protocol (FTP) allows a user on
          any computer to get files from another computer, or to send files
          to another computer.  Security is handled by requiring  the  user
          to  specify  a  user  name  and  password for the other computer.
          Provisions are made for handling file transfer  between  machines
          with different character set, end of line conventions, etc.  This
          is not quite the same thing as more recent "network file  system"
          or  "netbios"  protocols, which will be described below.  Rather,
          FTP is a utility that you run any time you want to access a  file
          on  another  system.    You  use  it to copy the file to your own
          system.  You then work with the local copy.   (See  RFC  959  for
          specifications for FTP.)










                                      - 5 -


        - remote  login.    The network terminal protocol (TELNET) allows a
          user to log in on any other computer on the network.  You start a
          remote session by specifying a computer to connect to.  From that
          time until you finish the session, anything you type is  sent  to
          the  other  computer.   Note that you are really still talking to
          your own computer.  But the telnet program effectively makes your
          computer invisible while it is running.  Every character you type
          is sent directly to the other system.  Generally, the  connection
          to  the  remote  computer  behaves much like a dialup connection.
          That is, the remote system will ask you to  log  in  and  give  a
          password, in whatever manner it would normally ask a user who had
          just dialed it up.  When you log off of the other  computer,  the
          telnet  program exits, and you will find yourself talking to your
          own computer.  Microcomputer implementations of telnet  generally
          include  a  terminal  emulator  for some common type of terminal.
          (See RFC's 854 and 855 for specifications for  telnet.    By  the
          way,  the  telnet protocol should not be confused with Telenet, a
          vendor of commercial network services.)

        - computer mail.  This allows you to  send  messages  to  users  on
          other  computers.    Originally, people tended to use only one or
          two specific computers.  They  would  maintain  "mail  files"  on
          those machines.  The computer mail system is simply a way for you
          to add a message to another user's mail file.    There  are  some
          problems  with  this  in  an environment where microcomputers are
          used.  The most serious is that a micro is  not  well  suited  to
          receive  computer  mail.    When you send mail, the mail software
          expects to be able  to  open  a  connection  to  the  addressee's
          computer, in order to send the mail.  If this is a microcomputer,
          it may be turned off, or it may be running an  application  other
          than  the mail system.  For this reason, mail is normally handled
          by a larger system, where it is practical to have a  mail  server
          running all the time.  Microcomputer mail software then becomes a
          user interface that retrieves mail from the mail  server.    (See
          RFC  821  and  822 for specifications for computer mail.  See RFC
          937 for a protocol designed for microcomputers to use in  reading
          mail from a mail server.)

     These  services  should  be  present  in any implementation  of  TCP/IP,
     except  that  micro-oriented implementations may  not  support  computer
     mail. These traditional applications still play a very important role in
     TCP/IP-based  networks. However more recently,  the  way  in  which net-
     works  are  used has been changing. The  older  model  of  a  number  of
     large,  self-sufficient  computers  is  beginning  to  change. Now  many
     installations    have    several   kinds   of    computers,    including
     microcomputers, workstations, minicomputers, and  mainframes. These com-
     puters  are  likely  to be  configured  to  perform  specialized  tasks.
     Although  people  are still likely to work with one  specific  computer,
     that  computer  will  call on other systems on the net  for  specialized
     services.  This  has   led  to  the  "server/client"  model  of  network
     services. A server is a system that provides a specific service for  the
     rest  of  the network. A client is another system  that  uses  that ser-
     vice. (Note  that the server and client need not be on different comput-
     ers.   They  could  be   different   programs   running   on   the  same









                                      - 6 -


     computer.) Here  are  the  kinds  of  servers  typically  present  in  a
     modern  computer  setup.  Note that these computer services can  all  be
     provided within the framework of TCP/IP.

        - network  file  systems.   This allows a system to access files on
          another computer in a somewhat more  closely  integrated  fashion
          than FTP.  A network file system provides the illusion that disks
          or other devices from one system are directly connected to  other
          systems.    There  is no need to use a special network utility to
          access a file on another system.  Your computer simply thinks  it
          has  some  extra disk drives.  These extra "virtual" drives refer
          to the other system's disks.    This  capability  is  useful  for
          several different purposes.  It lets you put large disks on a few
          computers, but still give others access to the disk space.  Aside
          from the obvious economic benefits, this allows people working on
          several computers  to  share  common  files.    It  makes  system
          maintenance  and  backup  easier, because you don't have to worry
          about updating  and  backing  up  copies  on  lots  of  different
          machines.    A  number  of  vendors  now  offer  high-performance
          diskless computers.  These computers have no disk drives at  all.
          They  are  entirely dependent upon disks attached to common "file
          servers".   (See  RFC's  1001  and  1002  for  a  description  of
          PC-oriented   NetBIOS   over   TCP.     In  the  workstation  and
          minicomputer area, Sun's Network File System is more likely to be
          used.    Protocol  specifications  for  it are available from Sun
          Microsystems.)

        - remote printing.  This allows you to  access  printers  on  other
          computers  as if they were directly attached to yours.  (The most
          commonly used protocol is the remote  lineprinter  protocol  from
          Berkeley  Unix.  Unfortunately, there is no protocol document for
          this.  However the C code is easily obtained  from  Berkeley,  so
          implementations are common.)

        - remote  execution.   This allows you to request that a particular
          program be run on a different computer.  This is useful when  you
          can  do  most  of  your work on a small computer, but a few tasks
          require the resources of a larger system.  There are a number  of
          different  kinds  of remote execution.  Some operate on a command
          by command basis.  That is, you request that a  specific  command
          or  set  of commands should run on some specific computer.  (More
          sophisticated versions will choose a system that  happens  to  be
          free.)    However  there are also "remote procedure call" systems
          that allow a program to  call  a  subroutine  that  will  run  on
          another  computer.    (There  are  many  protocols  of this sort.
          Berkeley Unix contains two servers to execute commands  remotely:
          rsh  and  rexec.   The man pages describe the protocols that they
          use.  The user-contributed software with Berkeley 4.3 contains  a
          "distributed  shell"  that  will  distribute tasks among a set of
          systems, depending upon load.  Remote procedure  call  mechanisms
          have  been  a  topic  for research for a number of years, so many
          organizations have implementations of such facilities.  The  most
          widespread commercially-supported remote procedure call protocols
          seem to be Xerox's Courier and Sun's RPC.  Protocol documents are









                                      - 7 -


          available  from  Xerox and Sun.  There is a public implementation
          of Courier over TCP as part of the user-contributed software with
          Berkeley  4.3.   An implementation of RPC was posted to Usenet by
          Sun, and also appears as part of  the  user-contributed  software
          with Berkeley 4.3.)

        - name  servers.    In  large  installations, there are a number of
          different collections of names that have to  be  managed.    This
          includes  users  and their passwords, names and network addresses
          for computers, and accounts.  It becomes  very  tedious  to  keep
          this data up to date on all of the computers.  Thus the databases
          are kept on a small number of systems.  Other systems access  the
          data over the network.  (RFC 822 and 823 describe the name server
          protocol used to keep track of host names and Internet  addresses
          on  the  Internet.    This  is  now a required part of any TCP/IP
          implementation.  IEN 116 describes an older name server  protocol
          that is used by a few terminal servers and other products to look
          up host names.  Sun's  Yellow  Pages  system  is  designed  as  a
          general  mechanism to handle user names, file sharing groups, and
          other databases commonly used by Unix  systems.    It  is  widely
          available  commercially.    Its  protocol definition is available
          from Sun.)

        - terminal servers.  Many installations no longer connect terminals
          directly  to  computers.    Instead they connect them to terminal
          servers.  A terminal server is simply a small computer that  only
          knows  how  to  run  telnet  (or some other protocol to do remote
          login).  If your terminal is  connected  to  one  of  these,  you
          simply  type the name of a computer, and you are connected to it.
          Generally it is possible to have active connections to more  than
          one  computer  at  the  same time.  The terminal server will have
          provisions to switch between connections rapidly, and  to  notify
          you  when  output  is  waiting for another connection.  (Terminal
          servers use the telnet protocol, already mentioned.  However  any
          real terminal server will also have to support name service and a
          number of other protocols.)

        - network-oriented  window  systems.      Until   recently,   high-
          performance  graphics  programs had to execute on a computer that
          had  a  bit-mapped  graphics  screen  directly  attached  to  it.
          Network  window  systems  allow  a  program to use a display on a
          different computer.  Full-scale network window systems provide an
          interface  that  lets you distribute jobs to the systems that are
          best  suited  to  handle  them,  but  still  give  you  a  single
          graphically-based  user  interface.  (The most widely-implemented
          window system is X. A  protocol  description  is  available  from
          MIT's  Project  Athena.  A reference implementation is publically
          available from MIT.  A number  of  vendors  are  also  supporting
          NeWS,  a window system defined by Sun.  Both of these systems are
          designed to use TCP/IP.)

     Note that some of the  protocols  described  above  were   designed   by
     Berkeley,   Sun,   or other organizations.  Thus they are not officially
     part of the Internet protocol suite.   However  they   are   implemented









                                      - 8 -


     using   TCP/IP,  just as normal TCP/IP application protocols are.  Since
     the protocol definitions are not  considered  proprietary,   and   since
     commercially-support   implementations   are  widely  available,  it  is
     reasonable to think of these protocols as being  effectively   part   of
     the   Internet   suite.   Note that the list above is simply a sample of
     the sort of services  available  through  TCP/IP.    However   it   does
     contain    the   majority  of  the  "major"  applications.    The  other
     commonly-used protocols tend to be specialized facilities  for   getting
     information   of   various  kinds, such as who is logged in, the time of
     day, etc.  However if you need a facility that is not listed  here,   we
     encourage   you   to  look  through  the  current  edition  of  Internet
     Protocols (currently RFC 1011),  which  lists  all  of   the   available
     protocols,    and    also   to   look   at  some  of  the  major  TCP/IP
     implementations to see what various vendors have added.

     1.1.4.  General description of the TCP/IP protocols

     TCP/IP is a layered set of protocols.  In  order  to   understand   what
     this   means,   it is useful to look at an example.  A typical situation
     is sending mail.  First, there is a protocol for mail.  This  defines  a
     set   of   commands which one machine sends to another, e.g. commands to
     specify who the sender of the message is, who it is being sent  to,  and
     then   the   text  of  the  message.  However this protocol assumes that
     there is a way to communicate  reliably  between  the   two   computers.
     Mail,   like   other  application  protocols,  simply  defines  a set of
     commands and messages to be sent.  It is designed to be  used   together
     with   TCP  and IP. TCP is responsible for making sure that the commands
     get through to the other end.  It keeps track of  what  is   sent,   and
     retransmitts  anything  that did not get through.  If any message is too
     large for one datagram, e.g. the text of the mail, TCP will   split   it
     up   into   several  datagrams,  and  make  sure  that  they  all arrive
     correctly.  Since these functions are needed  for   many   applications,
     they  are  put together into a separate protocol, rather than being part
     of the specifications for sending mail.   You  can  think  of   TCP   as
     forming  a  library of routines that applications can use when they need
     reliable network communications with another computer.   Similarly,  TCP
     calls   on  the services of IP.  Although the services that TCP supplies
     are needed by  many  applications,  there  are  still  some   kinds   of
     applications   that   don't  need them.  However there are some services
     that every application needs.  So these services are put  together  into
     IP.     As   with TCP, you can think of IP as a library of routines that
     TCP calls on, but which is also available to applications   that   don't
     use   TCP.     This  strategy  of building several levels of protocol is
     called "layering".  We think of  the  applications  programs   such   as
     mail,   TCP,  and IP, as being separate "layers", each of which calls on
     the services of the layer below it.   Generally,   TCP/IP   applications
     use 4 layers:

        - an application protocol such as mail

        - a  protocol  such  as  TCP  that  provides  services need by many
          applications

        - IP, which provides the basic  service  of  getting  datagrams  to









                                      - 9 -


          their destination

        - the  protocols  needed to manage a specific physical medium, such
          as Ethernet or a point to point line.

     TCP/IP is based on the "catenet model".  (This is  described   in   more
     detail   in   IEN 48.)  This model assumes that there are a large number
     of independent networks connected together  by  gateways.     The   user
     should   be  able to access computers or other resources on any of these
     networks.   Datagrams  will  often  pass  through  a   dozen   different
     networks   before   getting  to  their  final  destination.  The routing
     needed to accomplish this should be completely invisible to  the   user.
     As   far   as  the  user  is concerned, all he needs to know in order to
     access another system is an "Internet address".  This  is   an   address
     that  looks  like 128.6.4.194.  It is actually a 32-bit number.  However
     it is normally written as 4 decimal numbers, each representing  8   bits
     of   the   address.  (The term "octet" is used by Internet documentation
     for such 8-bit chunks.  The term "byte" is not used, because  TCP/IP  is
     supported   by   some computers that have byte sizes other than 8 bits.)
     Generally the structure of the  address  gives  you   some   information
     about   how   to  get  to  the  system.  For example, 128.6 is a network
     number assigned by a central authority to Rutgers  University.   Rutgers
     uses   the   next  octet  to  indicate  which of the campus Ethernets is
     involved.  128.6.4 happens to be an  Ethernet  used  by   the   Computer
     Science   Department.     The last octet allows for up to 254 systems on
     each Ethernet.  (It is 254 because 0 and  255  are  not   allowed,   for
     reasons   that   will  be  discussed  later.)  Note that 128.6.4.194 and
     128.6.5.194 would be different systems.  The structure of  an   Internet
     address is described in a bit more detail later.

     Of  course  we  normally  refer  to  systems  by  name, rather  than  by
     Internet  address.   When we specify a name, the network software  looks
     it  up  in  a  database,  and comes up with the  corresponding  Internet
     address.   Most  of the network software deals strictly in terms of  the
     address.  (RFC 882 describes the name server technology used  to  handle
     this lookup.)

     TCP/IP is  built  on  "connectionless"  technology.     Information   is
     transfered   as   a sequence of "datagrams".  A datagram is a collection
     of data that is sent as a single message.  Each of these  datagrams   is
     sent   through   the network individually.  There are provisions to open
     connections (i.e.  to start a conversation that will continue  for  some
     time).     However  at some level, information from those connections is
     broken up into datagrams, and  those  datagrams  are  treated   by   the
     network   as   completely  separate.    For example, suppose you want to
     transfer a 15000 octet file.  Most networks can't handle a  15000  octet
     datagram.    So  the protocols will break this up into something like 30
     500-octet datagrams.  Each of these datagrams  will  be  sent   to   the
     other   end.     At  that point, they will be put back together into the
     15000-octet file.  However while those datagrams are in   transit,   the
     network  doesn't  know that there is any connection between them.  It is
     perfectly possible  that  datagram  14  will  actually   arrive   before
     datagram   13.     It is also possible that somewhere in the network, an
     error will occur, and some datagram won't get through at all.   In  that









                                      - 10 -


     case, that datagram has to be sent again.

     Note  by  the way that the terms "datagram" and "packet" often  seem  to
     be  nearly  interchangable.  Technically, datagram is the right word  to
     use  when  describing  TCP/IP.  A datagram is a unit of data,  which  is
     what  the  protocols deal with.  A packet is a physical thing, appearing
     on an Ethernet or some wire.  In most cases a packet simply  contains  a
     datagram,  so  there is  very  little  difference.    However  they  can
     differ.  When TCP/IP is used on top of X.25, the X.25  interface  breaks
     the  datagrams  up into 128-byte packets.   This  is  invisible  to  IP,
     because  the  packets  are put back together into a single  datagram  at
     the  other  end before being processed by TCP/IP.  So in this case,  one
     IP  datagram  would  be carried by several packets.  However  with  most
     media,  there  are efficiency advantages to  sending  one  datagram  per
     packet, and so the distinction tends to vanish.

     Two separate protocols are involved in handling TCP/IP  datagrams.   TCP
     (the  "transmission  control protocol") is responsible for  breaking  up
     the  message  into  datagrams,  reassembling  them  at  the  other  end,
     resending  anything  that gets lost, and  putting  things  back  in  the
     right  order.  IP (the "internet protocol") is responsible  for  routing
     individual  datagrams.   It may seem like TCP is  doing  all  the  work.
     And  in  small networks that is true.  However in the  Internet,  simply
     getting  a  datagram to its  destination  can  be  a  complex  job.    A
     connection  may require the datagram to go through several  networks  at
     Rutgers,  a  serial line to the John von Neuman Supercomputer Center,  a
     couple  of Ethernets there, a series of 56Kbaud phone lines  to  another
     NSFnet  site,  and more Ethernets on another campus.  Keeping  track  of
     the  routes  to all of the destinations and  handling  incompatibilities
     among different transport media turns out to be a complex job.    Note

     that  the  interface  between TCP and IP is fairly simple.   TCP  simply
     hands  IP  a datagram with a destination.   IP  doesn't  know  how  this
     datagram relates to any datagram before it or after it.

     It  may  have occurred to you that something is missing here.   We  have
     talked  about  Internet addresses, but not about how you keep  track  of
     multiple  connections  to  a given system.  Clearly it isn't  enough  to
     get  a  datagram to the right  destination.    TCP  has  to  know  which
     connection  this  datagram  is  part  of.  This task is referred  to  as
     "demultiplexing."   In  fact, there are several levels of demultiplexing
     going  on in TCP/IP.  The information needed to do  this  demultiplexing
     is  contained  in a series of "headers".  A header is simply a few extra
     octets  tacked  onto  the  beginning of a datagram by some  protocol  in
     order  to  keep track of it.  It's a lot like putting a letter  into  an
     envelope  and  putting  an  address  on  the  outside of  the  envelope.
     Except  with  modern networks it happens several times.  It's  like  you
     put the letter into a little envelope, your secretary puts that  into  a
     somewhat  bigger  envelope, the campus mail center  puts  that  envelope
     into a still bigger one, etc.  Here is an overview of the  headers  that
     get stuck on a message that passes through a typical TCP/IP network:

     We start with a single data stream, say a file you are trying  to   send
     to some other computer:









                                      - 11 -


        ......................................................

     TCP  breaks  it  up into manageable chunks.  (In order to do  this,  TCP
     has  to  know how large a datagram your network can handle.    Actually,
     the TCP's at each end say how big a datagram they can handle,  and  then
     they pick the smallest size.)

        ....   ....   ....   ....   ....   ....   ....   ....

     TCP puts a header at the front of each datagram.  This  header  actually
     contains   at  least 20 octets, but the most important ones are a source
     and destination "port number" and  a  "sequence  number".     The   port
     numbers   are  used to keep track of different conversations.  Suppose 3
     different people are transferring files.  Your TCP might  allocate  port
     numbers 1000, 1001, and 1002 to these transfers.  When you are sending a
     datagram, this becomes the "source" port number,  since  you   are   the
     source   of   the  datagram.    Of  course  the TCP at the other end has
     assigned a port number of its own for the conversation.  Your  TCP   has
     to   know  the port number used by the other end as well.  (It finds out
     when the connection starts, as we will explain below.)  It   puts   this
     in   the   "destination" port field.  Of course if the other end sends a
     datagram back to you, the source and destination port numbers  will   be
     reversed,   since   then  it  will  be  the  source  and you will be the
     destination.  Each datagram has a sequence number.  This  is   used   so
     that   the   other  end  can make sure that it gets the datagrams in the
     right  order,  and  that  it  hasn't  missed  any.    (See    the    TCP
     specification  for  details.)  TCP doesn't number the datagrams, but the
     octets.  So if there are 500 octets of  data  in  each   datagram,   the
     first  datagram  might be numbered 0, the second 500, the next 1000, the
     next 1500, etc.  Finally, I will mention the  Checksum.    This   is   a
     number   that   is  computed by adding up all the octets in the datagram
     (more or less - see the TCP spec).  The result is put in   the   header.
     TCP   at   the other end computes the checksum again.  If they disagree,
     then something bad happened to the datagram in transmission, and  it  is
     thrown away.  So here's what the datagram looks like now.

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |          Source Port          |       Destination Port        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    Acknowledgment Number                      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Data |           |U|A|P|R|S|F|                               |
         | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
         |       |           |G|K|H|T|N|N|                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Checksum            |         Urgent Pointer        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   your data ... next 500 octets                               |
         |   ......                                                      |

     If  we abbreviate the TCP header as "T", the whole file now  looks  like
     this:









                                      - 12 -


        T....   T....   T....   T....   T....   T....   T....

     You will note that there are items in  the  header  that  I   have   not
     described   above.     They  are  generally  involved  with managing the
     connection.  In order to make sure the datagram  has  arrived   at   its
     destination,   the   recipient  has  to  send back an "acknowledgement".
     This is a datagram whose "Acknowledgement number" field is  filled   in.
     For   example,   sending  a  packet  with  an  acknowledgement  of  1500
     indicates that you have received all the data up to octet  number  1500.
     If   the   sender  doesn't  get  an  acknowledgement within a reasonable
     amount of time, it sends the data  again.    The  window  is   used   to
     control   how   much  data can be in transit at any one time.  It is not
     practical to wait for each datagram to be acknowledged  before   sending
     the   next   one.    That would slow things down too much.  On the other
     hand, you can't just keep sending, or a fast  computer   might   overrun
     the   capacity   of  a slow one to absorb data.  Thus each end indicates
     how much new data it is currently prepared to absorb  by   putting   the
     number   of   octets  in  its  "Window" field.  As the computer receives
     data, the amount of space left in its window decreases.  When  it   goes
     to   zero,  the sender has to stop.  As the receiver processes the data,
     it increases its window, indicating that it is ready  to   accept   more
     data.   Often  the same datagram can be used to acknowledge receipt of a
     set of data and to give permission for  additional  new  data   (by   an
     updated   window).   The "Urgent" field allows one end to tell the other
     to skip ahead in its processing to a particular octet.  This  is   often
     useful   for   handling asynchronous events, for example when you type a
     control character or other command that interrupts output.   The   other
     fields are beyond the scope of this document.

     1.1.5.  The IP level

     TCP  sends each of these datagrams to IP.  Of course it has to  tell  IP
     the  Internet  address of the computer at the other end.  Note that this
     is  all  IP  is concerned about.  It doesn't care about what is  in  the
     datagram,  or  even in the TCP header.  IP's job is  simply  to  find  a
     route for the datagram and get it to the other end.  In order  to  allow
     gateways  or  other intermediate systems to  forward  the  datagram,  it
     adds  its  own  header.  The main things in this header are  the  source
     and  destination  Internet address (32-bit addresses, like 128.6.4.194),
     the  protocol  number,  and  another  checksum.    The  source  Internet
     address  is  simply the address of your machine.  (This is necessary  so
     the  other  end  knows where the datagram came from.)   The  destination
     Internet  address  is the address  of  the  other  machine.    (This  is
     necessary  so  any  gateways  in  the  middle  know where you  want  the
     datagram  to  go.)  The protocol number tells IP at  the  other  end  to
     send  the  datagram  to TCP.  Although most IP traffic uses  TCP,  there
     are  other  protocols that can use IP, so you  have  to  tell  IP  which
     protocol  to send the datagram to.  Finally, the checksum allows  IP  at
     the  other  end to verify that the header  wasn't  damaged  in  transit.
     Note  that TCP and IP have separate checksums.  IP needs to be  able  to
     verify that the header didn't get damaged in transit, or it could send a
     message to the wrong place.  For reasons not worth discussing  here,  it
     is  both  more  efficient  and  safer to have  TCP  compute  a  separate
     checksum  for  the  TCP  header  and  data.  Once IP has tacked  on  its









                                      - 13 -


     header, here's what the message looks like:

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |Version|  IHL  |Type of Service|          Total Length         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         Identification        |Flags|      Fragment Offset    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Time to Live |    Protocol   |         Header Checksum       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                       Source Address                          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    Destination Address                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  TCP header, then your data ......                            |
         |                                                               |

     If we represent the IP header by an "I",  your  file  now   looks   like
     this:

        IT....   IT....   IT....   IT....   IT....   IT....   IT....

     Again,  the  header contains some additional fields that have  not  been
     discussed.   Most  of them are beyond the scope of this document.    The
     flags  and fragment offset are used to keep track of the pieces  when  a
     datagram  has  to be split up.   This  can  happen  when  datagrams  are
     forwarded through a network for which they are too big.  (This  will  be
     discussed  a  bit more below.)  The time to live is  a  number  that  is
     decremented  whenever  the  datagram passes through a system.   When  it
     goes  to  zero, the datagram is discarded.  This is done in case a  loop
     develops  in the system somehow.  Of course this should  be  impossible,
     but   well-designed   networks  are  built  to  cope  with  "impossible"
     conditions.

     At this point, it's possible that no more headers are needed.   If  your
     computer  happens  to have a direct phone  line  connecting  it  to  the
     destination  computer,  or  to  a  gateway,  it  may  simply   send  the
     datagrams  out  on the line (though likely a synchronous  protocol  such
     as  HDLC  would be used, and it would add at least a few octets  at  the
     beginning and end).

     1.1.6.  The Ethernet level

     However most of our networks these days use Ethernet.  So now  we   have
     to   describe   Ethernet's headers.  Unfortunately, Ethernet has its own
     addresses.  The people who designed Ethernet wanted to make  sure   that
     no   two   machines  would  end  up  with  the  same  Ethernet  address.
     Furthermore, they  didn't  want  the  user  to  have  to   worry   about
     assigning   addresses.     So  each  Ethernet  controller  comes with an
     address builtin from the factory.  In order to  make  sure   that   they
     would   never  have to reuse addresses, the Ethernet designers allocated
     48 bits for the Ethernet address.  People who make  Ethernet   equipment
     have   to   register  with  a  central  authority, to make sure that the
     numbers they assign don't overlap any other manufacturer.  Ethernet is a
     "broadcast  medium".   That  is,  it is in effect like an old party line









                                      - 14 -


     telephone.  When you send a packet out on the Ethernet,  every   machine
     on   the   network sees the packet.  So something is needed to make sure
     that the right machine gets it.  As you might guess, this  involves  the
     Ethernet   header.     Every  Ethernet packet has a 14-octet header that
     includes the source and destination Ethernet address, and a  type  code.
     Each  machine  is supposed to pay attention only to packets with its own
     Ethernet address in the destination field.  (It's   perfectly   possible
     to   cheat,   which  is  one reason that Ethernet communications are not
     terribly secure.)  Note  that  there  is  no  connection   between   the
     Ethernet  address  and the Internet address.  Each machine has to have a
     table of what Ethernet address corresponds to what   Internet   address.
     (We   will   describe  how  this  table is constructed a bit later.)  In
     addition to the addresses, the header contains a type code.   The   type
     code  is  to allow for several different protocol families to be used on
     the same network.  So you can use TCP/IP, DECnet, Xerox  NS,   etc.   at
     the   same   time.   Each of them will put a different value in the type
     field.  Finally,  there  is  a  checksum.    The   Ethernet   controller
     computes  a  checksum of the entire packet.  When the other end receives
     the packet, it recomputes the checksum, and throws the packet  away   if
     the   answer   disagrees  with the original.  The checksum is put on the
     end of the packet, not in the header.  The final result is   that   your
     message looks like this:

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Ethernet destination address (first 32 bits)            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Ethernet dest (last 16 bits)  |Ethernet source (first 16 bits)|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       Ethernet source address (last 32 bits)                  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |        Type code              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  IP header, then TCP header, then your data                   |
         |                                                               |
             ...
         |                                                               |
         |   end of your data                                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                       Ethernet Checksum                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     If  we  represent  the  Ethernet  header  with  "E",  and  the  Ethernet
     checksum with "C", your file now looks like this:

        EIT....C   EIT....C   EIT....C   EIT....C   EIT....C

     When these packets are received by the other end, of  course   all   the
     headers   are   removed.    The  Ethernet interface removes the Ethernet
     header and the checksum.  It looks at the type code.  Since   the   type
     code   is  the one assigned to IP, the Ethernet device driver passes the
     datagram up to IP.  IP removes the IP header.   It  looks  at   the   IP
     protocol   field.     Since  the  protocol  type  is  TCP, it passes the
     datagram up to TCP.  TCP now looks at the sequence number.     It   uses
     the   sequence   numbers  and  other  information  to  combine  all  the









                                      - 15 -


     datagrams into the original file.

     The ends our initial summary of TCP/IP.  There are still  some   crucial
     concepts  we  haven't gotten to, so we'll now go back and add details in
     several areas.  (For detailed descriptions of the items  discussed  here
     see,   RFC   793  for  TCP,  RFC  791  for IP, and RFC's 894 and 826 for
     sending IP over Ethernet.)

     1.1.7.  Well-known sockets and the applications layer

     So far, we have described how a stream  of  data  is  broken   up   into
     datagrams,   sent   to another computer, and put back together.  However
     something more is needed  in  order  to  accomplish   anything   useful.
     There   has   to  be  a  way for you to open a connection to a specified
     computer, log into it, tell it what file you  want,  and   control   the
     transmission   of   the  file.   (If you have a different application in
     mind, e.g. computer mail, some analogous protocol is needed.)   This  is
     done   by   "application  protocols".  The application protocols run "on
     top" of TCP/IP.  That is, when they want to send a message,  they   give
     the   message   to  TCP.   TCP makes sure it gets delivered to the other
     end.  Because TCP and IP take care of all the networking  details,   the
     applications   protocols  can treat a network connection as if it were a
     simple byte stream, like a terminal or phone line.

     Before going into more details about applications programs, we  have  to
     describe  how  you find an application.  Suppose you want to send a file
     to a computer whose Internet address  is  128.6.4.7.    To   start   the
     process,   you   need  more than just the Internet address.  You have to
     connect to the FTP server at the  other  end.    In   general,   network
     programs   are   specialized  for a specific set of tasks.  Most systems
     have separate programs  to  handle  file  transfers,   remote   terminal
     logins,  mail,  etc.  When you connect to 128.6.4.7, you have to specify
     that you want to talk to the FTP server.    This  is  done   by   having
     "well-known   sockets"   for  each  server.    Recall that TCP uses port
     numbers to keep track of  individual  conversations.     User   programs
     normally   use  more or less random port numbers.  However specific port
     numbers are assigned to the programs that sit  waiting   for   requests.
     For   example,   if  you  want  to send a file, you will start a program
     called "ftp".  It will open a connection using some random  number,  say
     1234,   for   the  port number on its end.  However it will specify port
     number 21 for the other end.  This is the official port number  for  the
     FTP  server.   Note that there are two different programs involved.  You
     run ftp on your side.  This is a program designed to   accept   commands
     from   your   terminal  and  pass them on to the other end.  The program
     that you talk to on the other machine  is  the  FTP  server.     It   is
     designed   to   accept commands from the network connection, rather than
     an interactive terminal.  There is no need for your program to   use   a
     well-known   socket   number  for  itself.  Nobody is trying to find it.
     However the servers have to have well-known numbers,  so   that   people
     can   open   connections  to  them and start sending them commands.  The
     official  port  numbers  for  each  program  are  given   in   "Assigned
     Numbers".

     Note  that  a  connection is actually described by a set of  4  numbers:









                                      - 16 -


     the  Internet  address at each end, and the TCP port number at each end.
     Every  datagram  has  all  four of those numbers in it.   (The  Internet
     addresses  are  in the IP header, and the TCP port numbers  are  in  the
     TCP header.)  In order to keep things straight, no two  connections  can
     have  the  same set of numbers.  However it is enough for any one number
     to  be  different.    For  example,  it  is perfectly possible  for  two
     different  users  on a machine to be sending files  to  the  same  other
     machine.    This  could  result  in  connections  with   the   following
     parameters:

                        Internet addresses         TCP ports
         connection 1  128.6.4.194, 128.6.4.7      1234, 21
         connection 2  128.6.4.194, 128.6.4.7      1235, 21

     Since the same machines are involved, the Internet addresses   are   the
     same.     Since   they  are  both  doing  file transfers, one end of the
     connection involves the well-known port number  for  FTP.     The   only
     thing   that   differs is the port number for the program that the users
     are running.  That's enough of a difference.  Generally, at  least   one
     end   of   the  connection asks the network software to assign it a port
     number that is guaranteed to be unique.   Normally,  it's   the   user's
     end, since the server has to use a well-known number.

     Now  that  we  know  how  to  open  connections, let's get back  to  the
     applications  programs.   As mentioned earlier, once TCP  has  opened  a
     connection,  we  have  something  that might as well be a  simple  wire.
     All  the  hard parts are handled by TCP and IP.  However we  still  need
     some  agreement  as  to  what we send over this connection.   In  effect
     this  is  simply an agreement on what set of  commands  the  application
     will  understand,  and  the  format  in  which  they  are  to  be  sent.
     Generally,  what  is sent is a combination of commands and data.    They
     use  context  to  differentiate.  For example, the mail  protocol  works
     like  this:  Your mail program opens a connection to the mail server  at
     the  other end.  Your program gives it your machine's name,  the  sender
     of the message, and the recipients you want it sent to.  It then sends a
     command saying that it is starting the  message.   At  that  point,  the
     other  end   stops  treating  what  it  sees  as  commands,  and  starts
     accepting  the  message.  Your end then starts sending the text  of  the
     message.   At  the end of the message, a special mark is sent (a dot  in
     the first column).  After that, both ends understand that  your  program
     is  again  sending commands.  This is the simplest way to do things, and
     the one that most applications use.

     File  transfer  is  somewhat more complex.  The file  transfer  protocol
     involves  two  different connections.  It starts  out  just  like  mail.
     The user's program sends commands like "log me in as this  user",  "here
     is  my  password", "send me the file with this name".  However once  the
     command  to  send  data is sent, a second connection is opened  for  the
     data  itself.   It would certainly be possible to send the data  on  the
     same  connection,  as  mail does.  However file transfers often  take  a
     long  time.   The designers of the  file  transfer  protocol  wanted  to
     allow  the  user  to  continue  issuing commands while the  transfer  is
     going  on.   For example, the user might make an inquiry,  or  he  might
     abort  the  transfer.    Thus  the designers felt it was best to  use  a









                                      - 17 -


     separate  connection  for  the  data  and  leave  the  original  command
     connection  for  commands.    (It  is  also  possible  to  open  command
     connections  to  two different computers, and tell them to send  a  file
     from  one  to  the other.  In that case, the data couldn't go  over  the
     command connection.)

     Remote terminal connections use another mechanism still.    For   remote
     logins,   there   is just one connection.  It normally sends data.  When
     it is necessary to send a command (e.g. to set the terminal type  or  to
     change   some   mode),  a special character is used to indicate that the
     next character is a command.  If the user happens to type  that  special
     character as data, two of them are sent.

     We  are  not  going to describe the application protocols in  detail  in
     this  document.   It's better to read the RFC's yourself.  However there
     are  a  couple of common conventions used by applications that  will  be
     described  here.   First, the common network representation:  TCP/IP  is
     intended  to  be  usable  on  any  computer.    Unfortunately,  not  all
     computers  agree  on how data is represented.  There are differences  in
     character  codes  (ASCII  vs.  EBCDIC),  in  end  of   line  conventions
     (carriage  return,  line feed, or a representation using counts), and in
     whether  terminals expect characters to be sent individually or  a  line
     at  a  time.   In  order  to  allow  computers  of  different  kinds  to
     communicate,   each   applications   protocol   defines    a    standard
     representation.     Note   that  TCP  and  IP  do  not  care  about  the
     representation.    TCP  simply  sends octets.  However the  programs  at
     both  ends  have to agree on how the octets are to be interpreted.   The
     RFC  for  each  application  specifies the standard  representation  for
     that  application.   Normally it  is  "net  ASCII".    This  uses  ASCII
     characters,  with end of line denoted by a carriage return followed by a
     line  feed.   For  remote  login,  there  is  also  a  definition  of  a
     "standard terminal", which turns out to be a half-duplex  terminal  with
     echoing  happening  on the local machine.  Most applications  also  make
     provisions  for  the  two  computers to agree on  other  representations
     that  they  may find more convenient.  For example, PDP-10's have 36-bit
     words.    There  is a way that two PDP-10's can agree to send  a  36-bit
     binary  file.   Similarly, two systems that prefer full-duplex  terminal
     conversations  can  agree  on  that.    However each application  has  a
     standard representation, which every machine must support.

     1.1.8.  An example application: SMTP

     In order to give a bit better idea what is involved in  the  application
     protocols,   I'm   going  to  show an example of SMTP, which is the mail
     protocol.  (SMTP is "simple mail transfer protocol.)  We assume  that  a
     computer called TOPAZ.RUTGERS.EDU wants to send the following message.

       Date: Sat, 27 Jun 87 13:26:31 EDT
       From: [e-mail]
       To: [e-mail]
       Subject: meeting

       Let's get together Monday at 1pm.










                                      - 18 -


     First,  note  that the format of the message itself is described  by  an
     Internet  standard  (RFC 822).  The standard specifies the fact that the
     message  must be transmitted as net ASCII (i.e. it must be  ASCII,  with
     carriage  return/linefeed  to delimit lines).   It  also  describes  the
     general  structure, as a group of header lines, then a blank  line,  and
     then  the  body of the message.  Finally, it describes the syntax of the
     header  lines in detail.  Generally they consist of a keyword and then a
     value.

     Note  that  the  addressee  is  indicated    as    [e-mail].
     Initially,   addresses  were simply "person at machine".  However recent
     standards have made things more flexible.  There  are   now   provisions
     for   systems   to handle other systems' mail.  This can allow automatic
     forwarding on behalf of computers not connected to the  Internet.     It
     can  be  used to direct mail for a number of systems to one central mail
     server.  Indeed there is no requirement that an actual computer  by  the
     name   of  RED.RUTGERS.EDU even exist.  The name servers could be set up
     so that you mail to department names, and each  department's   mail   is
     routed   automatically  to an appropriate computer.  It is also possible
     that the part before the @ is something other than a user name.   It  is
     possible   for   programs  to be set up to process mail.  There are also
     provisions  to  handle  mailing  lists,  and  generic  names   such   as
     "postmaster" or "operator".

     The  way  the  message is to be sent to another system is  described  by
     RFC's  821  and 974.  The program that is going to be doing the  sending
     asks  the  name server several queries to determine where to  route  the
     message.   The  first query is to find out which  machines  handle  mail
     for  the  name RED.RUTGERS.EDU.  In this case, the server  replies  that
     RED.RUTGERS.EDU  handles  its own mail.  The program then asks  for  the
     address of RED.RUTGERS.EDU, which is 128.6.4.2.  Then the  mail  program
     opens  a  TCP connection to port 25  on  128.6.4.2.    Port  25  is  the
     well-known  socket  used  for receiving mail.  Once this  connection  is
     established,  the  mail program starts sending  commands.    Here  is  a
     typical  conversation.  Each line is labelled as to whether it  is  from
     TOPAZ or RED.  Note that TOPAZ initiated the connection:

              RED    220 RED.RUTGERS.EDU SMTP Service at 29 Jun  87  05:17:18
          EDT
              TOPAZ  HELO topaz.rutgers.edu
              RED    250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
              TOPAZ  MAIL From:<[e-mail]>
              RED    250 MAIL accepted
              TOPAZ  RCPT To:<[e-mail]>
              RED    250 Recipient accepted
              TOPAZ  DATA
              RED    354 Start mail input; end with <CRLF>.<CRLF>
              TOPAZ  Date: Sat, 27 Jun 87 13:26:31 EDT
              TOPAZ  From: [e-mail]
              TOPAZ  To: [e-mail]
              TOPAZ  Subject: meeting
              TOPAZ
              TOPAZ  Let's get together Monday at 1pm.
              TOPAZ  .









                                      - 19 -


              RED    250 OK
              TOPAZ  QUIT
              RED    221 RED.RUTGERS.EDU Service closing transmission channel

     First, note that commands all use normal text.  This is typical  of  the
     Internet   standards.     Many  of  the  protocols  use  standard  ASCII
     commands.  This makes it easy  to  watch  what  is  going  on   and   to
     diagnose   problems.   For example, the mail program keeps a log of each
     conversation.  If something goes wrong, the log  file  can   simply   be
     mailed   to   the  postmaster.  Since it is normal text, he can see what
     was going on.  It also allows a human to interact  directly   with   the
     mail   server,   for  testing.  (Some newer protocols are complex enough
     that this is not practical.  The commands would have to have  a   syntax
     that  would  require a significant parser.  Thus there is a tendency for
     newer protocols to use binary formats.  Generally they  are   structured
     like   C  or Pascal record structures.)  Second, note that the responses
     all begin with numbers.  This is also typical of   Internet   protocols.
     The   allowable   responses  are  defined  in the protocol.  The numbers
     allow the user program to respond unambiguously.    The  rest   of   the
     response   is   text,  which is normally for use by any human who may be
     watching or looking at a log.  It has no effect on  the   operation   of
     the   programs.   (However there is one point at which the protocol uses
     part of the text of the response.)   The  commands   themselves   simply
     allow   the   mail  program  on  one  end  to  tell  the mail server the
     information it needs to know in order to deliver the message.   In  this
     case,   the   mail  server  could  get the information by looking at the
     message itself.  But for more complex cases, that would not   be   safe.
     Every   session   must  begin  with  a HELO, which gives the name of the
     system that initiated the connection.  Then the sender  and   recipients
     are  specified.   (There can be more than one RCPT command, if there are
     several recipients.)  Finally the data itself is sent.  Note  that   the
     text   of  the message is terminated by a line containing just a period.
     (If such a line appears in the message, the period is  doubled.)   After
     the   message   is  accepted,  the  sender  can send another message, or
     terminate the session as in the example above.

     Generally, there is a pattern to the response numbers.    The   protocol
     defines   the   specific set of responses that can be sent as answers to
     any given command.  However programs that don't want to   analyze   them
     in   detail   can  just  look at the first digit.  In general, responses
     that begin with a 2  indicate  success.    Those  that  begin   with   3
     indicate   that  some further action is needed, as shown above.  4 and 5
     indicate errors.  4 is a "temporary" error, such as  a   disk   filling.
     The   message  should be saved, and tried again later.  5 is a permanent
     error, such as a  non-existent  recipient.    The  message   should   be
     returned to the sender with an error message.

     (For  more  details about the protocols mentioned in this  section,  see
     RFC's  821/822  for mail, RFC 959 for file transfer, and  RFC's  854/855
     for  remote  logins.  For the well-known port numbers, see  the  current
     edition of Assigned Numbers, and possibly RFC 814.)












                                      - 20 -


     1.2.  Protocols other than TCP: UDP and ICMP

     So far, we have described only connections that use TCP.   Recall   that
     TCP   is   responsible  for  breaking  up  messages  into datagrams, and
     reassembling them properly.  However in  many  applications,   we   have
     messages   that   will  always  fit in a single datagram.  An example is
     name lookup.  When a user attempts to make  a  connection   to   another
     system,   he   will  generally  specify  the system by name, rather than
     Internet address.  His system has to translate that name to  an  address
     before   it   can  do  anything.  Generally, only a few systems have the
     database used to translate names to addresses.  So the   user's   system
     will  want  to send a query to one of the systems that has the database.
     This query is going to be very short.  It will certainly  fit   in   one
     datagram.     So   will the answer.  Thus it seems silly to use TCP.  Of
     course TCP does more than just break things up  into   datagrams.     It
     also   makes   sure  that  the  data  arrives, resending datagrams where
     necessary.  But for a question that fits  in  a  single   datagram,   we
     don't   need   all the complexity of TCP to do this.  If we don't get an
     answer after a few seconds, we can just ask again.    For   applications
     like this, there are alternatives to TCP.

     The most common alternative is UDP ("user datagram protocol").   UDP  is
     designed  for  applications where you don't need  to  put  sequences  of
     datagrams  together.  It fits into the system much like TCP.  There is a
     UDP  header.  The network software puts the UDP header on  the  front of
     your  data, just as it would put a TCP header on the front of your data.
     Then  UDP sends the data  to  IP,  which  adds  the  IP  header, putting
     UDP's  protocol number in the protocol field instead of  TCP's  protocol
     number.   However  UDP  doesn't do as much  as  TCP  does.    It doesn't
     split data into multiple datagrams.  It doesn't keep track  of  what  it
     has  sent so it can resend if necessary.  About  all  that  UDP provides
     is  port  numbers,  so  that several programs can use UDP at once.   UDP
     port  numbers  are used just like TCP port  numbers.    There are  well-
     known  port numbers for servers that use UDP.  Note that the UDP  header
     is  shorter than a TCP header.   It  still  has  source  and destination
     port  numbers,  and  a checksum,  but  that's  about  it.   No  sequence
     number, since it is not needed.  UDP is used by the protocols that  han-
     dle  name  lookups (see IEN 116, RFC 882, and RFC 883), and a number  of
     similar protocols.

     Another  alternative  protocol  is  ICMP  ("Internet   control   message
     protocol").     ICMP   is  used  for  error messages, and other messages
     intended for the TCP/IP software itself, rather  than   any   particular
     user   program.   For example, if you attempt to connect to a host, your
     system may get back an ICMP message saying "host  unreachable".     ICMP
     can   also  be used to find out some information about the network.  See
     RFC 792 for details of ICMP.  ICMP is  similar  to  UDP,  in   that   it
     handles  messages  that fit in one datagram.  However it is even simpler
     than UDP.  It doesn't even have port numbers in its header.   Since  all
     ICMP   messages  are interpreted by the network software itself, no port
     numbers are needed to say where a ICMP message is supposed to go.












                                      - 21 -


     1.3.  Keeping track of names and information: the domain system

     As we indicated earlier, the network software generally needs  a  32-bit
     Internet   address   in  order  to open a connection or send a datagram.
     However users prefer to deal with computer names rather  than   numbers.
     Thus   there   is  a database that allows the software to look up a name
     and find the corresponding number.  When the Internet was  small,   this
     was   easy.   Each system would have a file that listed all of the other
     systems, giving both their name and number.  There are  now   too   many
     computers   for   this  approach to be practical.  Thus these files have
     been replaced by a set of name servers that keep track of   host   names
     and   the  corresponding Internet addresses.  (In fact these servers are
     somewhat more general than that.  This is just one kind  of  information
     stored  in  the domain system.)  Note that a set of interlocking servers
     are used, rather than a single central one.  There  are  now   so   many
     different   institutions   connected  to  the  Internet that it would be
     impractical for them to  notify  a  central  authority   whenever   they
     installed   or  moved a computer.  Thus naming authority is delegated to
     individual institutions.  The name servers form a  tree,   corresponding
     to   institutional   structure.    The names themselves follow a similar
     structure.  A typical example is the name BORAX.LCS.MIT.EDU.  This  is a
     computer   at   the  Laboratory  for  Computer Science (LCS) at MIT.  In
     order to find its Internet address,  you  might  potentially   have   to
     consult   4   different  servers.  First, you would ask a central server
     (called the root) where the EDU server is.  EDU is a server  that  keeps
     track  of  educational institutions.  The root server would give you the
     names and Internet addresses of several servers for EDU.    (There   are
     several   servers   at  each  level,  to allow for the possibly that one
     might be down.)  You would then ask EDU where the server for   MIT   is.
     Again,   it   would  give  you  names  and Internet addresses of several
     servers for MIT.  Generally, not all of those servers would be  at  MIT,
     to   allow  for the possibility of a general power failure at MIT.  Then
     you would ask MIT where the server for LCS is, and finally   you   would
     ask  one  of the LCS servers about BORAX.  The final result would be the
     Internet address for BORAX.LCS.MIT.EDU.    Each  of  these   levels   is
     referred   to   as  a  "domain".  The entire name, BORAX.LCS.MIT.EDU, is
     called a "domain name".    (So  are  the  names  of   the   higher-level
     domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.)

     Fortunately,  you  don't really have to go through all of this  most  of
     the  time.   First of all, the root name servers also happen to  be  the
     name  servers  for  the  top-level domains such as EDU.  Thus  a  single
     query  to  a root  server  will  get  you  to  MIT.    Second,  software
     generally  remembers answers that it got before.  So once we look  up  a
     name  at  LCS.MIT.EDU, our software remembers where to find servers  for
     LCS.MIT.EDU,  MIT.EDU,  and EDU.  It also remembers the  translation  of
     BORAX.LCS.MIT.EDU.   Each  of these pieces of information has a "time to
     live"  associated with it.  Typically this is a few days.   After  that,
     the  information  expires and has to be looked up again.    This  allows
     institutions to change things.

     The  domain  system  is not limited to finding out  Internet  addresses.
     Each  domain  name is a node in a database.  The node can  have  records
     that  define  a number of different properties.  Examples  are  Internet









                                      - 22 -


     address,  computer  type, and a list of services provided by a computer.
     A  program  can  ask  for  a  specific  piece  of  information,  or  all
     information  about  a given name.  It is possible  for  a  node  in  the
     database  to  be  marked as an "alias" (or nickname) for  another  node.
     It  is  also possible to use the  domain  system  to  store  information
     about users, mailing lists, or other objects.

     There  is  an  Internet  standard  defining  the  operation   of   these
     databases,  as  well as the protocols used  to  make  queries  of  them.
     Every  network utility has to be able to make such queries,  since  this
     is  now  the official way to evaluate host names.   Generally  utilities
     will talk to a server on their own system.  This server will  take  care
     of  contacting  the other servers for them.  This keeps down the  amount
     of code that has to be in each application program.

     The  domain  system  is  particularly  important for  handling  computer
     mail.  There are entry types to define what computer handles mail  for a
     given  name, to specify where an individual is to receive mail,  and  to
     define mailing lists.

     (See RFC's 882, 883, and 973 for specifications of the  domain   system.
     RFC 974 defines the use of the domain system in sending mail.)

     1.4.  Routing

     The   description  above  indicated  that  the  IP   implementation   is
     responsible  for  getting datagrams to the destination indicated by  the
     destination address, but little was said about how this would  be  done.
     The  task  of finding how to  get  a  datagram  to  its  destination  is
     referred to as "routing".  In fact many of the details depend  upon  the
     particular implementation.  However some general things can be said.

     First, it is necessary to understand the model on which IP   is   based.
     IP  assumes  that a system is attached to some local network.  We assume
     that the system can send datagrams to any  other  system  on   its   own
     network.     (In   the  case  of  Ethernet, it simply finds the Ethernet
     address of the destination system, and puts the datagram  out   on   the
     Ethernet.)     The   problem  comes  when  a  system  is asked to send a
     datagram to a system on a different network.  This problem  is   handled
     by   gateways.    A gateway is a system that connects a network with one
     or more other networks.  Gateways  are  often  normal   computers   that
     happen  to have more than one network interface.  For example, we have a
     Unix machine that has two different Ethernet  interfaces.   Thus  it  is
     connected   to  networks 128.6.4 and 128.6.3.  This machine can act as a
     gateway between those two networks.  The software on that  machine  must
     be   set   up  so that it will forward datagrams from one network to the
     other.  That is, if a machine on network 128.6.4 sends a   datagram   to
     the   gateway,   and  the  datagram is addressed to a machine on network
     128.6.3, the gateway will forward the  datagram  to   the   destination.
     Major  communications  centers often have gateways that connect a number
     of different  networks.    (In  many  cases,   special-purpose   gateway
     systems  provide  better performance or reliability than general-purpose
     systems acting as gateways.  A number of vendors sell such systems.)










                                      - 23 -


     Routing in IP is  based  entirely  upon  the  network  number   of   the
     destination   address.     Each computer has a table of network numbers.
     For each network number, a gateway is listed.  This is the  gateway   to
     be  used  to get to that network.  Note that the gateway doesn't have to
     connect directly to the network.  It just has to be the best  place   to
     go   to   get there.  For example at Rutgers, our interface to NSFnet is
     at the John von Neuman Supercomputer Center (JvNC). Our  connection   to
     JvNC   is   via  a  high-speed  serial line connected to a gateway whose
     address is 128.6.3.12.  Systems on net 128.6.3 will list  128.6.3.12  as
     the   gateway   for  many  off-campus  networks.  However systems on net
     128.6.4 will list 128.6.4.1 as the gateway to  those   same   off-campus
     networks.     128.6.4.1   is  the  gateway  between networks 128.6.4 and
     128.6.3, so it is the first step in getting to JvNC.

     When a computer wants to send a datagram, it first checks  to   see   if
     the   destination  address is on the system's own local network.  If so,
     the datagram can be sent directly.  Otherwise, the system   expects   to
     find  an  entry for the network that the destination address is on.  The
     datagram is sent to the gateway listed in that entry.  This  table   can
     get  quite  big.  For example, the Internet now includes several hundred
     individual networks.  Thus various strategies have been   developed   to
     reduce   the  size of the routing table.  One strategy is to depend upon
     "default routes".  Often, there is only one gateway out of  a   network.
     This   gateway  might connect a local Ethernet to a campus-wide backbone
     network.  In that case, we don't need to have  a  separate   entry   for
     every   network   in  the  world.    We  simply define that gateway as a
     "default".  When no specific  route  is  found  for  a   datagram,   the
     datagram   is   sent to the default gateway.  A default gateway can even
     be used when there are several gateways  on  a  network.     There   are
     provisions   for   gateways  to  send a message saying "I'm not the best
     gateway -- use this one instead."  (The message is sent via  ICMP.   See
     RFC   792.)   Most network software is designed to use these messages to
     add entries to their routing tables.  Suppose network 128.6.4  has   two
     gateways,  128.6.4.59  and 128.6.4.1.  128.6.4.59 leads to several other
     internal Rutgers networks.  128.6.4.1 leads indirectly to  the   NSFnet.
     Suppose   we   set  128.6.4.59  as  a default gateway, and have no other
     routing table entries.  Now what  happens  when  we  need  to   send   a
     datagram   to   MIT?    MIT  is  network 18.  Since we have no entry for
     network 18, the datagram will be sent to the default,  128.6.4.59.    As
     it   happens,   this  gateway  is the wrong one.  So it will forward the
     datagram to 128.6.4.1.  But it will also send back an error  saying   in
     effect:  "to  get to network 18, use 128.6.4.1".  Our software will then
     add an entry to the routing table.  Any future datagrams to   MIT   will
     then   go   directly to 128.6.4.1.  (The error message is sent using the
     ICMP protocol.  The message type is called "ICMP redirect.")

     Most IP experts recommend that individual computers should not  try   to
     keep   track   of  the  entire network.  Instead, they should start with
     default gateways, and let the gateways tell them the routes,   as   just
     described.    However  this doesn't say how the gateways should find out
     about the routes.  The gateways can't depend upon this  strategy.   They
     have   to   have fairly complete routing tables.  For this, some sort of
     routing protocol is needed.  A routing protocol is simply  a   technique
     for   the   gateways  to  find each other, and keep up to date about the









                                      - 24 -


     best way to get to every network.   RFC  1009  contains  a   review   of
     gateway   design   and  routing.    However rip.doc is probably a better
     introduction to the subject.  It contains some tutorial material,  and a
     detailed description of the most commonly-used routing protocol.

     1.5.  Details about Internet addresses: subnets and broadcasting

     As  indicated earlier, Internet addresses are 32-bit  numbers,  normally
     written as 4 octets (in decimal), e.g. 128.6.4.7.  There are  actually 3
     different types of address.  The problem is  that  the  address  has  to
     indicate  both  the network and the host within the  network.    It  was
     felt  that  eventually  there would be lots of networks.  Many  of  them
     would  be  small, but probably 24 bits would be needed to represent  all
     the  IP  networks.  It was also felt that some very big  networks  might
     need  24  bits to represent all of their hosts.  This would seem to lead
     to  48  bit  addresses.  But the designers really wanted to use  32  bit
     addresses.   So  they adopted a kludge.  The assumption is that most  of
     the  networks will be small.  So they set up three different  ranges  of
     address.   Addresses  beginning with 1 to 126 use only the  first  octet
     for  the network number.  The other three octets are available  for  the
     host  number.   Thus 24 bits are available for hosts.  These numbers are
     used  for large networks.  But there can only be 126 of these  very  big
     networks.   The  Arpanet is one, and there are a  few  large  commercial
     networks.    But  few  normal organizations get one of these  "class  A"
     addresses.   For  normal large organizations, "class  B"  addresses  are
     used.    Class  B  addresses  use the first two octets for  the  network
     number.   Thus  network numbers are 128.1 through 191.254.  (We avoid  0
     and  255,  for  reasons  that  we  see below.  We also  avoid  addresses
     beginning  with  127, because that is used by some systems  for  special
     purposes.)    The  last  two  octets  are available for  host  addesses,
     giving  16  bits of host address.   This  allows  for  64516  computers,
     which should be enough for most organizations.  (It is possible  to  get
     more  than  one class B address, if you run  out.)    Finally,  class  C
     addresses  use  three  octets,  in  the  range 192.1.1  to  223.254.254.
     These  allow  only 254 hosts on each network, but there can be  lots  of
     these  networks.   Addresses above 223 are reserved for future  use,  as
     class D and E (which are currently not defined).

     Many large organizations find it convenient to  divide   their   network
     number into "subnets".  For example, Rutgers has been assigned a class B
     address, 128.6.  We find it convenient to use the  third  octet  of  the
     address  to  indicate which Ethernet a host is on.  This division has no
     significance outside of Rutgers.  A computer  at   another   institution
     would  treat  all datagrams addressed to 128.6 the same way.  They would
     not look at the third octet of the address.   Thus   computers   outside
     Rutgers   would   not have different routes for 128.6.4 or 128.6.5.  But
     inside Rutgers, we treat 128.6.4 and 128.6.5 as separate  networks.   In
     effect,  gateways  inside Rutgers have separate entries for each Rutgers
     subnet, whereas gateways outside  Rutgers  just  have  one   entry   for
     128.6.   Note   that  we  could  do  exactly  the  same thing by using a
     separate class C address for each Ethernet.   As  far  as   Rutgers   is
     concerned,   it   would be just as convenient for us to have a number of
     class C addresses.  However using class C addresses would  make   things
     inconvenient  for  the rest of the world.  Every institution that wanted









                                      - 25 -


     to talk to us would have to have a separate entry for each one  of   our
     networks.    If  every institution did this, there would be far too many
     networks for any reasonable gateway to keep track of.  By  subdividing a
     class  B network, we hide our internal structure from everyone else, and
     save  them  trouble.    This  subnet  strategy  requires  special provi-
     sions in the network software.  It is described in RFC 950.

     0  and  255  have  special  meanings.  0 is reserved for  machines  that
     don't know their address.  In certain circumstances it is possible for a
     machine not to know the number of the network it is on, or even its  own
     host  address.   For  example, 0.0.0.23 would be a machine that  knew it
     was host number 23, but didn't know on what network.

     255  is  used for "broadcast".  A broadcast is a message that  you  want
     every  system  on the network to see.    Broadcasts  are  used  in  some
     situations  where you don't know who to talk to.  For  example,  suppose
     you  need  to look  up  a  host  name  and  get  its  Internet  address.
     Sometimes  you  don't know the address of the nearest name  server.   In
     that  case,  you might send the request as a broadcast.  There are  also
     cases  where a number of systems are interested in information.   It  is
     then  less  expensive to send a single broadcast than to send  datagrams
     individually  to  each host that is interested in the  information.   In
     order  to  send a broadcast, you use an address that is  made  by  using
     your  network  address, with all ones in the part of the  address  where
     the  host  number goes.  For example, if you are on network 128.6.4, you
     would   use   128.6.4.255  for  broadcasts.    How  this   is   actually
     implemented  depends  upon the medium.   It  is  not  possible  to  send
     broadcasts  on the Arpanet, or on point to point lines.  However  it  is
     possible  on  an Ethernet.  If you use an Ethernet address with all  its
     bits  on (all ones), every machine on the Ethernet is supposed  to  look
     at that datagram.

     Although the official broadcast address for  network  128.6.4   is   now
     128.6.4.255,   there   are  some  other addresses that may be treated as
     broadcasts by certain implementations.  For convenience,  the   standard
     also   allows   255.255.255.255 to be used.  This refers to all hosts on
     the local network.  It is often simpler to use  255.255.255.255  instead
     of   finding  out the network number for the local network and forming a
     broadcast address such as 128.6.4.255.   In  addition,   certain   older
     implementations   may   use  0  instead  of  255  to  form the broadcast
     address.    Such  implementations  would  use  128.6.4.0   instead    of
     128.6.4.255   as   the  broadcast  address on network 128.6.4.  Finally,
     certain older implementations may not understand about  subnets.    Thus
     they  consider  the network number to be 128.6.  In that case, they will
     assume a broadcast address  of  128.6.255.255  or   128.6.0.0.     Until
     support   for   broadcasts is implemented properly, it can be a somewhat
     dangerous feature to use.

     Because 0 and 255 are used for unknown and broadcast  addresses,  normal
     hosts   should  never be given addresses containing 0 or 255.  Addresses
     should never begin with 0, 127, or any number above   223.     Addresses
     violating  these  rules are sometimes referred to as "Martians", because
     of rumors that the Central University of Mars is using network 225.










                                      - 26 -


     1.6.  Datagram fragmentation and reassembly

     TCP/IP is designed for use  with  many  different  kinds   of   network.
     Unfortunately,   network   designers  do not agree about how big packets
     can be.  Ethernet packets can be 1500 octets long.     Arpanet   packets
     have   a   maximum  of around 1000 octets.  Some very fast networks have
     much larger packet sizes.  At first, you might think  that   IP   should
     simply   settle   on  the  smallest  possible size.  Unfortunately, this
     would cause serious performance problems.    When   transferring   large
     files,  big  packets are far more efficient than small ones.  So we want
     to be able to use the largest packet size possible.  But we  also   want
     to   be   able  to  handle  networks  with  small limits.  There are two
     provisions for this.  First, TCP has the ability to  "negotiate"   about
     datagram   size.   When a TCP connection first opens, both ends can send
     the maximum datagram size they can  handle.    The  smaller   of   these
     numbers   is   used  for  the  rest  of the connection.  This allows two
     implementations that can handle big datagrams to use  them,   but   also
     lets   them   talk  to  implementations that can't handle them.  However
     this doesn't completely solve the problem.  The most   serious   problem
     is   that  the two ends don't necessarily know about all of the steps in
     between.  For example, when sending data between Rutgers  and  Berkeley,
     it  is  likely that both computers will be on Ethernets.  Thus they will
     both  be  prepared  to  handle  1500-octet  datagrams.     However   the
     connection  will  at some point end up going over the Arpanet.  It can't
     handle packets of that size.  For this reason, there are  provisions  to
     split    datagrams    up   into   pieces.    (This  is  referred  to  as
     "fragmentation".)  The IP header  contains  fields  indicating   the   a
     datagram   has   been split, and enough information to let the pieces be
     put back together.  If a gateway connects an Ethernet to  the   Arpanet,
     it  must  be prepared to take 1500-octet Ethernet packets and split them
     into pieces that will fit on the Arpanet.    Furthermore,   every   host
     implementation   of   TCP/IP  must  be prepared to accept pieces and put
     them back together.  This is referred to as "reassembly".

     TCP/IP implementations differ in the approach they take to  deciding  on
     datagram   size.     It  is  fairly  common  for  implementations to use
     576-byte datagrams whenever they can't verify that the entire  path   is
     able   to   handle larger packets.  This rather conservative strategy is
     used because of the number of implementations with bugs in the  code  to
     reassemble   fragments.     Implementors  often try to avoid ever having
     fragmentation occur.  Different implementors take  different  approaches
     to   deciding   when  it  is safe to use large datagrams.  Some use them
     only for the local network.  Others will use them for any   network   on
     the    same    campus.    576  bytes  is  a  "safe"  size,  which  every
     implementation must support.

     1.7.  Ethernet encapsulation: ARP

     There was a brief discussion earlier about what IP datagrams  look  like
     on   an   Ethernet.    The  discussion  showed  the  Ethernet header and
     checksum.  However it left one hole: It didn't say how to   figure   out
     what  Ethernet  address to use when you want to talk to a given Internet
     address.  In fact, there is a separate protocol for this,   called   ARP
     ("address   resolution  protocol").  (Note by the way that ARP is not an









                                      - 27 -


     IP protocol.  That is, the ARP datagrams  do  not  have   IP   headers.)
     Suppose   you   are  on  system  128.6.4.194  and you want to connect to
     system 128.6.4.7.  Your system will first verify that 128.6.4.7  is   on
     the   same  network, so it can talk directly via Ethernet.  Then it will
     look up 128.6.4.7 in its ARP table, to see if  it  already   knows   the
     Ethernet   address.     If  so, it will stick on an Ethernet header, and
     send the packet.  But suppose this system is not  in  the   ARP   table.
     There   is   no  way  to  send the packet, because you need the Ethernet
     address.  So it  uses  the  ARP  protocol  to  send  an   ARP   request.
     Essentially   an   ARP  request  says  "I  need the Ethernet address for
     128.6.4.7".  Every system listens to ARP requests.  When a  system  sees
     an   ARP   request  for itself, it is required to respond.  So 128.6.4.7
     will see the request, and will respond with an  ARP  reply   saying   in
     effect  "128.6.4.7  is 8:0:20:1:56:34".  (Recall that Ethernet addresses
     are 48 bits.  This is 6 octets.  Ethernet addresses  are  conventionally
     shown   in   hex,  using  the punctuation shown.)  Your system will save
     this information in its ARP table, so future packets will  go  directly.
     Most   systems   treat the ARP table as a cache, and clear entries in it
     if they have not been used in a certain period of time.

     Note by the way that ARP requests must be sent as  "broadcasts".   There
     is   no   way  that  an  ARP  request  can be sent directly to the right
     system.  After all, the whole reason for sending  an  ARP   request   is
     that   you   don't know the Ethernet address.  So an Ethernet address of
     all ones is  used,  i.e.  ff:ff:ff:ff:ff:ff.    By   convention,   every
     machine   on   the Ethernet is required to pay attention to packets with
     this as an address.  So every system sees every ARP   requests.     They
     all   look  to see whether the request is for their own address.  If so,
     they respond.  If not, they could just ignore it.   (Some   hosts   will
     use   ARP   requests  to update their knowledge about other hosts on the
     network, even if the request isn't for them.)  Note that  packets  whose
     IP   address   indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255)
     are also sent with an Ethernet address that is all ones.

     1.8.  Getting more information

     This directory contains  documents  describing  the   major   protocols.
     There   are  literally hundreds of documents, so we have chosen the ones
     that seem most important.  Internet standards are called  RFC's.     RFC
     stands   for   Request  for  Comment.   A proposed standard is initially
     issued as a proposal, and given an RFC number.   When  it   is   finally
     accepted,   it  is added to Official Internet Protocols, but it is still
     referred to by the RFC number.   We  have  also  included   two   IEN's.
     (IEN's   used   to  be  a  separate  classification  for  more  informal
     documents.  This classification no longer exists -- RFC's are  now  used
     for   all   official  Internet documents, and a mailing list is used for
     more informal reports.)  The convention is that  whenever  an   RFC   is
     revised,  the  revised version gets a new number.  This is fine for most
     purposes, but it causes problems with two documents:  Assigned   Numbers
     and   Official   Internet  Protocols.  These documents are being revised
     all the time, so the RFC number keeps changing.  You will have  to  look
     in  rfc-index.txt  to find the number of the latest edition.  Anyone who
     is seriously interested in TCP/IP should read the  RFC   describing   IP
     (791).     RFC  1009 is also useful.  It is a specification for gateways









                                      - 28 -


     to be used by NSFnet.  As such, it contains an overview of  a   lot   of
     the   TCP/IP  technology.  You should probably also read the description
     of at least one of the application protocols, just to get a   feel   for
     the   way   things  work.    Mail is probably a good one (821/822).  TCP
     (793) is of course a very basic specification.  However  the   spec   is
     fairly   complex,   so  you should only read this when you have the time
     and patience to think about it carefully.  Fortunately, the  author   of
     the   major   RFC's  (Jon Postel) is a very good writer.  The TCP RFC is
     far easier to read than you would expect, given the complexity  of  what
     it   is   describing.    You  can  look at the other RFC's as you become
     curious about their subject matter.

     Here is a list of the documents you are more likely to want:

          rfc-index list of all RFC's

          rfc1012   somewhat fuller list of all RFC's

          rfc1011   Official Protocols.  It's useful to scan  this  to  see
                    what tasks protocols have been built for.  This defines
                    which  RFC's  are  actual  standards,  as  opposed   to
                    requests for comments.

          rfc1010   Assigned  Numbers.  If you are working with TCP/IP, you
                    will probably want a hardcopy of this as  a  reference.
                    It's  not  very  exciting  to  read.   It lists all the
                    offically defined well-known ports and  lots  of  other
                    things.

          rfc1009   NSFnet  gateway  specifications.  A good overview of IP
                    routing and gateway technology.

          rfc1001/2 netBIOS: networking for PC's

          rfc973    update on domains

          rfc959    FTP (file transfer)

          rfc950    subnets

          rfc937    POP2: protocol for reading mail on PC's

          rfc894    how IP is to be put on Ethernet, see also rfc825

          rfc882/3  domains (the database used to go  from  host  names  to
                    Internet  address  and back -- also used to handle UUCP
                    these days).  See also rfc973

          rfc854/5  telnet - protocol for remote logins

          rfc826    ARP - protocol for finding out Ethernet addresses

          rfc821/2  mail










                                      - 29 -


          rfc814    names and ports - general  concepts  behind  well-known
                    ports

          rfc793    TCP

          rfc792    ICMP

          rfc791    IP

          rfc768    UDP

          rip.doc   details of the most commonly-used routing protocol

          ien-116   old  name  server  (still  needed  by  several kinds of
                    system)

          ien-48    the  Catenet  model,   general   description   of   the
                    philosophy behind TCP/IP

     The following documents are somewhat more specialized.

          rfc813    window and acknowledgement strategies in TCP

          rfc815    datagram reassembly techniques

          rfc816    fault isolation and resolution techniques

          rfc817    modularity and efficiency in implementation

          rfc879    the maximum segment size option in TCP

          rfc896    congestion control

          rfc827,888,904,975,985
                    EGP and related issues

     To those of you who may be reading this document remotely   instead   of
     at   Rutgers:   The  most  important  RFC's  have  been collected into a
     three-volume set, the DDN Protocol Handbook.  It is available  from  the
     DDN   Network   Information  Center,  SRI  International, 333 Ravenswood
     Avenue, Menlo Park, California 94025 (telephone:  [phone]).     You
     should  be able to get them via anonymous FTP from sri-nic.arpa.

     rip.doc is available  by  anonymous  FTP  from   topaz.rutgers.edu,   as
     /pub/tcp-ip-docs/rip.doc.

     IBM PC 360k floppies with ARC'ed versions of the  RFC's  and  IEN's  are
     also available from the TAPR office, thanks to Andy Freeborn, N0CCZ.

     1.9.  Overview of the KA9Q Internet Package

     The software associated with this document represents the culmination of
     what might be described as a first phase of implementaton.  The emphasis
     to date has been on building a robust platform on which  to  build  real









                                      - 30 -


     networks.   To this end, the core protocols have been extensively tested
     and verified.  In addition, great emphasis has been placed on increasing
     the  portability  of  the  software,  supporting  more and more hardware
     interfaces, and making it possible to use as many  networking  technolo-
     gies (asynch or RS-232 lines, Ethernet, various packet radio interfaces,
     digipeaters, NET/ROM, etc) as possible.

     The down side is that the user interface can be  described  at  best  as
     "terse".   The good news is that many individuals are working on improv-
     ing the interface, and great strides have been  made  in  the  Macintosh
     implementation.   In the meantime, we ask only that you realize what our
     priorities have been, and understand that even the  implementors  aren't
     always proud of "how it looks".

     This release provides support for the IP, ICMP, TCP, UDP, FTP, SMTP, and
     Telnet  protocols from the basic Arpanet set.  In addition, the ARP pro-
     tocol is available for address resolution on AX.25 and  Ethernet  inter-
     faces,  and  support  is provided for NET/ROM used as a transport. It is
     unfortunately necessary, as a result of the ongoing  NET/ROM  vs  TheNet
     debate,  to mention that the NET/ROM implementation included here is the
     original work of Dan Frank, W9NK, working  solely  from  documents  pub-
     lished by Software 2000.

     This release includes sources that are known to compile and run well  on
     PC  clones using MS-Dos, several flavors of System V Unix, including HP-
     UX and Microport on AT clones, the HP Portable Plus, the Atari  ST,  and
     the NEC PC-9801.

     Binaries are available on floppy for the PC and clones as part  of  this
     release.  Floppies  are  available  for the Mactintosh version, which is
     maintained separately but in parallel with the mainstream release.

     Other machines for which code is provided that may or may not  (probably
     not) work include the Amiga and BSD Unix.





























                                      - 31 -


     2.  Installation


     2.1.  What an IP Address Is, and How to Get One

     IP Addresses are 32 bit numbers that uniquely identify a  given  machine
     (or  "host")  running  the TCP/IP protocol suite. All of the possible 32
     bit numbers are coordinated by an entity known as the  Network  Informa-
     tion  Center,  or  NIC.  Amateur Radio operators are fortunate in that a
     "Class A Subnet"  consisting  of  24  bits  of  address,  in  the  range
     44.X.X.X,  has  been  reserved  for our use. By general concensus, Brian
     Kantor, WB6CYT, of San Diego, CA, now serves as the top  level  adminis-
     trator of the 44.X.X.X address space, and assigns blocks of addresses to
     regional coordinators from around the world.

     You need to have a unique address before you can link in with  the  rest
     of  the  networked  world.  The best way to get one is to ask around the
     local packet community and find out who your local  address  coordinator
     is.  Your  local  coordinator  will  then assign you an address from the
     block for your area.

     Brian Kantor can be reached as [e-mail] on  the  Internet  if  you
     need help locating your local address coordinator.

     2.2.  Configuring a TNC for TCP/IP Operation

     This section describes the  procedure  for  configuring  various  packet
     radio Terminal Node Controller units (TNC's) for operation with the KA9Q
     package.  Readers who will be using the package with only SLIP or Ether-
     net (wired) connections can feel free to skip ahead to section 2.2.

     There are now several choices for TNCs to be  used   with   the   TCP/IP
     network  code.  Versions  of  the  Keep  It  Simple Stupid TNC interface
     software (KISS) are available for the TNC-1, the TNC-2, the VADCG  board
     and   clones  (Ashby),  the Kantronics  family  of  TNCs,  and  the  AEA
     TNCs. Following are the different setup/configuration modes for the dif-
     ferent TNCs.

     2.2.1.  TAPR TNC-1 and Clones

     The firmware for the TNC-1 is available in either a downloadable version
     or   a  stand  alone  version.   I  will  describe  only the stand alone
     version here.  Locate the ROM labeled E000 and remove  it.   Insert  the
     KISS  PROM  in  its  place making  sure  that you orient the prom in the
     same direction (failure to do so will result in smoked  PROM).   Connect
     your  TNC-1  to   your   computer  using  an RS-232 cable.  A cable that
     passes the signals from pins 2, 3, and 7 is suffi- cient.

     Since the TNC-1 has no switches for setting the baud rate  to  the  com-
     puter   the  firmware has been "hard wired" to 4800 baud.  See the docu-
     mentation that comes with the TNC-1 version of KISS for instructions  on
     how to patch the .HEX  file for other baud rates.

     There is also a newer  version  of  the  TNC-1  KISS  firmware  that  is









                                      - 32 -


     documented in the TNC_TNC1.ARC file in the distribution.

     TAPR can provide programmed TNC-1 KISS EPROMs.

     2.2.2.  TAPR TNC-2 and Clones

     The  standard firmware for the TNC-2 now supports a  'KISS'  command  to
     turn  on  KISS support.  If you wish to use the KISS command included in
     1.1.6 firmware, read your TNC documentation for more info.

     If you want to run KISS only, or have an older TNC-2  without  the  KISS
     command,  dig out the TNC_TNC2.ARC package and read the docs included on
     how to program an EPROM with the firmware (or buy a ROM from TAPR),  and
     then proceed.

     Open up your TNC and locate the ROM.  It is in the socket labeled "U23."
     Using  a   small   nail  file  or screwdriver gently pry up the existing
     EPROM. Carefully press the new EPROM into  place  being  sure  that  the
     orientation   is  the  same.  If  you  are  installing  the 2764 type of
     EPROM you will need to make a small modification to the TNC.  There is a
     location  on  the  board  just  above  the first RAM socket labeled JMP-
     6.  Turn the board over and cut the trace joining the two pads.   Solder
     a  two-pin  jumper  header  in  place.    When  using  a  type 2764  the
     jumper  at  JMP-6 should be removed and  installed  when  a  type  27256
     EPROM  is  being  used.   That  should complete the hardware part of the
     installa- tion.  As an alternative you may choose to burn the KISS  code
     into a 27256 and not bother with jumpers.

     Attach your TNC to your PC using an RS-232C cable.  You can use the same
     cable  that  you  were using to connect your PC to your TNC.  If you are
     doing this for the first time and are not sure  about  your  cabling,  a
     cable  with  just  pins  2, 3, and 7 passed through is sufficient.  Some
     PCs like to see the signals Clear To Send (CTS, pin 5), Data  Set  Ready
     (DSR,  pin 6),  and  Data  Carrier  Detect (DCD,  pin  8) asserted.  You
     can set this up by jumpering pin 4 to 5, and pin 20 to pins 6 and  8  at
     the female DB-25 connector that goes to the PC.

     Now to verify that the TNC still works.  Apply power  to  the  TNC   and
     turn   it  on. The  STA,  CON,  and  PWR LEDs should come on and the STA
     and CON lights should go out again about 1 second later.   If  you  have
     the   type   2764  EPROM with  the  KISS  code  in it one or both of the
     STA and CON LEDs will begin to flash.  If the CON LED flashes  you  have
     8Kb  of  RAM  in the TNC.  If the STA LED flashes  you have 16Kb of RAM.
     If both LEDs flash you have 32 Kb of RAM.  The flashing of the LEDs ver-
     ifies the proper operation of the TNC.

     2.2.3.  AEA PK-232

     If you have one of these boxes, congratulations!  You do not   have   to
     change  PROMS!   KISS  is already installed as a standard feature if you
     have a recent release of the firmware, 4-MAR-87 or later  for  the   PK-
     232,   or   21-JAN-87  or later for the PK-87, you have KISS in your TNC
     already.  To make it work first ensure that your computer  can  communi-
     cate  with   the   TNC   in  standard  packet mode.   This  will  ensure









                                      - 33 -


     that the computer, TNC, cabling, and radio are all operating properly.

     [Please note that one of the commands "PACKET" is not valid on the   PK-
     87   and  will only elicit a "Huh?" response.  Please note that comments
     have been added to the commands.  Do not type the information  following
     the  double  dash  or type the double dash itself.]

     Here is the sequence of commands that will turn on  the  KISS  mode  for
     the  AEA products:

             AWLEN 8         -- ensure it can speak 8 bit data
             PARITY 0        -- no parity
             RESTART         -- warm reset; make commands take effect
             PACKET          -- PK-232 or Heath only
             TONE 3          -- PK-87 only
             START 0         -- disable software flow control
             STOP 0
             XON 0
             XOFF 0
             XFLOW off
             CONMODE trans   -- pass through all characters
             HPOLL off       -- disable host polling
             KISS on         -- enable KISS version of host mode
             RAWHDLC on      -- turn off AX25L2 (now handled by the PC)
             PPERSIST on     -- turn off DWAIT and enable p-persistence
             HOST on         -- start KISS running

     The PK-87 or the PK-232 will remain in the KISS mode until you  send   a
     break  (~200ms of spacing) or until you send the command character three
     times (^C ^C ^C) in quick succession.  Beware!  Some terminal  emulators
     (like   YAPP)   will  send   a   break  signal  when you exit from them.
     That will undo your work and cause all manner of confusion.  The  termi-
     nal  program   PROCOMM  seems  to  work just  fine.  The TNC may also be
     switched back to ordinary AX.25 mode by issuing  the  following  command
     from within NET.EXE:

             param ax0 255

     AEA is rumored to be reworking their software so that entering just  the
     "KISS" command will do all of the above. Check your documentation to see
     how your version works.

     2.2.4.  Kantronics TNC's

     Kantronics includes KISS support in their products. It is  the  simplest
     of the commercial implementations of KISS to configure and use.

     First setup and operate your KAM, KPC-II, or KPC-4 for  standard  packet
     operation.   This will ensure that the computer, TNC, cabling, and radio
     are operating properly. Use your terminal program to send the  following
     commands:

             ABAUD 4800      -- baud rate to what you will be using when
                                net is running (set by the attach command)









                                      - 34 -


             DWAIT 0         -- disable DWAIT
             PERSIST 50      -- enable persistence and set it to about 20%
             SLOTTIME 16     -- set the slot time to 160 ms
             KISS ON         -- Enable KISS mode at the next reset
             PERM            -- make above command permanent so that KISS
                                will be entered whenever TNC is powered up
             RESET           -- start KISS

     If you wish to have the the TNC revert back to ordinary AX.25  mode   of
     opera- tion  you  should  omit the PERM command from the above sequence.
     That way the TNC will revert back  to  ordinary  AX.25  mode  when   the
     power   is  removed  and restored  to  the TNC.  The TNC may be switched
     back to ordinary AX.25 mode by issuing the command:

             param ax0 255

     This command will work even if the PERM command has been  used  to  make
     KISS the default mode of operation.

     2.3.  IBM PC and Clones

     2.3.1.  Installing the Plug'N'Play Disk

     For users of IBM PC's and Clones, we try to make life as simple as  pos-
     sible.   There is a 360k floppy disk available from TAPR (see the appen-
     dices for contact information) that is almost ready to go.   You  "Plug"
     the  disk in, edit a couple of files with your favorite text editor, and
     then you're ready to "Play". Instructions  on  editting  the  files  are
     embedded as comments in the files, with a readme file on the disk to get
     you started. For completeness, information about the files  is  included
     here as well.

     2.3.1.1.  The AUTOEXEC.NET File

     The AUTOEXEC.NET file (called STARTUP.NET under Unix, and  other  things
     elsewhere)  works  a  lot  like  the AUTOEXEC.BAT file in Dos, hence the
     name.  When NET first starts up, it reads AUTOEXEC.BAT and executes  all
     of  the  commands  as  if they had been typed in to the program from the
     keyboard. This provides an easy mechanism for  setting  up  the  initial









                                      - 35 -


     system  configuration, including setting the hostname, AX.25 parameters,
     interfaces used, servers to start, and protocol variables.

     The suggested procedure is to start with the AUTOEXEC.NET file  included
     on  the  plug  and  play disk, and go from there.  If you don't have the
     plug and play disk, review the command summary elsewhere in  this  docu-
     ment, and wing it...

     2.3.1.2.  The FTPUSERS File

     Since MS-DOS was designed as a single-user operating system,   it   pro-
     vides  no access  control;  all files can be read, written or deleted by
     the local user.  It is usually undesirable to give such open access to a
     system  to  remote network  users. The FTP server therefore provides its
     own access control mechan- ism.

     The file "/ftpusers" is used to control remote FTP access.  The  default
     is   NO access; if  this  file  does  not  exist, the FTP server will be
     unusable. A remote user must first "log in" to  the  system,  giving   a
     valid   name  and  password  listed  in  /ftpusers, before he or she can
     transfer files.

     Each entry in /ftpusers consists of a single line of the form

             username password path1 permissions1 path2 permissions2 ...

     There must be exactly one space between each  field. Comment  lines  are
     begun with "#" in column one.

     "username" is the user's login name.

     "password" is the required password. Note  that  this   is   in   plain-
     text; therefore  it  is  not a good idea to give general read permission
     to the root directory. A password of "*" (a single asterisk) means  that
     any  password  is acceptable.

     "/pathN" is an allowable prefix on accessible files.  Before  any   file
     or  directory   operation,  the current directory and the user specified
     file name are joined to form an absolute path name in "canonical"   form
     (i.e.,   a  full path  name  starting  at  the root, with "./" and "../"
     references, as well as  redundant  /'s,  recognized  and  removed).  The
     result  MUST  begin with an allowable  path  prefix; if  not, the opera-
     tion is denied. NB! Under MS-DOS, this field must use backslashes ("/"),
     NOT  forward  slashes  ("/").  This field  must always begin with a "/",
     i.e., at the root directory.

     "permissionsN" is a decimal number granting permission for read,  create
     and  write   operations.  If the low order bit (0x1) is set, the user is
     allowed to read a file subject to the path name prefix  restriction.  If
     the   next   bit  (0x2)  is  set,  the  user  is  allowed  to  create  a
     new file if it does not overwrite an existing file. If  the  third   bit
     (0x4)   is   set,   the   user   is allowed  to  write a file even if it
     overwrites an existing file, and in addi-  tion  he  may  delete  files.
     Again,  all  operations  are  allowed  subject  to  the path name prefix









                                      - 36 -


     restrictions. Permissions may be combined by adding bits,  for  example,
     0x3  (=  0x2  + 0x1) means that the user is given read and  create  per-
     mission, but not overwrite/delete permission.

     For example, suppose /ftpusers on machine  "pc.ka9q.ampr"  contains  the
     line

             friendly test /testdir 7

     A session using this account would look like this:

             net> ftp pc.ka9q.ampr
             SYN Sent
             Established
             250 pc.ka9q.ampr FTP  version  871225.5  ready  at  Wed  Jan  20
     16:27:18 1988
             user friendly
             331 Enter PASS command
             pass test
             230 Logged in

     The user now has read, write, overwrite and delete  privileges  for  any
     file under /testdir; he may not access any other files.

     Here are some more sample entries in /ftpusers:

         karn foobar / 7         # User "karn" password "foobar" may read,
                                 # write, overwrite and delete any file on
                                 # system.

         guest bletch /g/bogus 3 # User "guest" password "bletch" may read
                                 # any file under /g/bogus and its subdirs,
                                 # and may create new files that do not
                                 # overwrite existing files. He may NOT
                                 # delete any files.

         anonymous * /public 1   # User "anonymous" (any password) may read
                                 # files under /public and subdir; he may
                                 #  not  create,  overwrite  or  delete   any
                                 # files.

     The last entry is a standard convention for  keeping  a   repository  of
     downloadable   files;  in   particular,  the  username "anonymous" is an
     established ARPAnet convention.  Every system providing an FTP server is
     encouraged to provide restricted access to an 'anonymous' user.

     2.3.1.3.  The HOSTS.NET File

     The file HOSTS.NET provides a mapping  between  internet  addresses  and
     symbolic  hostnames.  It  is used by NET to look up a hostname to figure
     out the correct IP address to use. This version of NET does not  include
     nameserver support (see the discussion earlier in this document), and so
     uses this static file for name lookups.  Tabs  are  recommended  between
     the  host  number  and  host name.  Here is an example of some HOSTS.NET









                                      - 37 -


     entries:

             44.96.0.2       wb2sef xt.wb2sef
             44.96.0.16      n8fjb
             44.96.0.17      ka3lyq

     Note that the domain name .AMPR.ORG has been assigned for amateur radio.
     By  default,  we  assume that the hostname is the user's callsign in the
     case where a user has one system online, and so  <callsign>.AMPR.ORG  is
     the  implied official hostname. If you have more than one machine on the
     air, distinguish them by prefixing a familiar name followed by a period,
     as in "winfree.n3eua" or "at.n0ccz".

     Note that the use of a callsign as a host name has nothing  to  do  with
     the "mycall" parameter.  It is convenient to use the callsign as a host-
     name, and required to use the callsign for "mycall" to properly identify
     a station according to FCC rules.

     2.3.2.  Installing on a Hard Disk

     To install the software on a hard disk, just clone the directory  struc-
     ture  and  file  layout from the floppy disk.  All paths are relative to
     the root directory of the current drive.

     2.4.  Unix

     To run NET under Unix, you'll need to compile the program from  sources.
     To do so, unpack the source archive into a directory, edit the beginning
     of makefile.unx to pick your Unix variant, edit config.h to  enable  the
     appropriate interface hardware (slip and kiss are probably all that will
     work), the run 'make -f makefile.unx'.  There's nothing wrong with copy-
     ing  the  makefile.unx  file to makefile and doing the editting there...
     personal preference.

     The basic requirements are that the serial ports to be used by net  must
     have  their  permissions  set so that they are read-write for the userid
     that will run net. For example, you can define a user  named  'net'  and
     make that user own tty000 and tty001. The protection for the ttys should
     be crw------- (600). Logins must be turned off  for  those  ports,  i.e.
     there  must not be any other process, such as a getty or init, trying to
     access them. The attach line is virtually the same as for the PC, except
     that  the I/O address argument is ignored and the I/O vector argument is
     now the tty name. For example:

             attach asy 0 /dev/tty000 ax25 ax0 2048 256 4800

             attach asy 0 /dev/tty001 ax25 ax1 2048 256 4800

     The Unix version of Net uses  two  environment  variables,  NETHOME  and
     NETSPOOL. A possible configuration might be

             NETHOME=/usr/net         NETSPOOL=/usr/spool

     The directories needed are /usr/net, /usr/net/finger,  /usr/spool/mail/,









                                      - 38 -


     and  /usr/spool/mqueue.  See  also  the  documentation  on  the W2XO BBS
     (sources and documentation are included in the NET source distribution),
     as  there  are some important interactions if you intend to run the PBBS
     code with NET under Unix.

     The Unix version of NET currently supports only serial ports,  with  the
     KISS and SLIP protocols.

     2.5.  Macintosh

     This release does not include Macintosh code.  A separate group is work-
     ing  on  the  Macintosh,  using  the  same  system  independent protocol
     modules, but with a user interface that is much more closely related  to
     the expected Macintosh environment.

     Installation documentation for the Mac is included with the Mac  version
     of the software, available from <insert contact info here>.

     2.6.  Atari ST

     Installation for the Atari version of NET is not  yet  available.   Your
     best bet is to stare at the sources, in config.h and files.h, as well as
     st.c and st.h. We hope to include documentation in the next revision  of
     this manual.

     2.7.  NEC PC-9801

     Installation on the NEC PC-98 family is the same as for the IBM  PC  and
     clones,  except  that  you  need  to  have  the  version of NET.EXE that
     includes handling for the serial port(s) in the NEC machine.

     2.8.  Hewlett-Packard Portable Plus

     Installation on the Portable Plus is the same as  for  the  IBM  PC  and
     clones,  except  that  you  need  to have the version of NET.EXE that is
     designed for the Portable Plus.



























                                      - 39 -


     3.  Taking NET for a Test Drive

     For the quick introduction to NET provided in this  section,  we  assume
     that you are using an IBM PC or clone with the Plug'n'Play disk. We also
     assume that you've already configured the disk per in  the  installation
     instructions.   Finally,  we  assume  a TNC has been set up as interface
     'ax0'.

     3.1.  Trying out the AX.25 Support

     Start by typing 'NET' to get the program up and running.  You should  be
     presented  with  a banner including revision information and a copyright
     statement, followed by a prompt of 'net>'. If you don't get this,  some-
     thing is horribly wrong. Find a friend and ask for help.

     Once you have the program going at all, the first thing you'll  probably
     want  to  do  is  to  figure  out if the TNC is hooked up correctly, and
     whether you're getting out at all.  To get connected, you  do  basically
     the  same thing you'd do with a raw TNC.  Type 'connect ax0 <callsign>',
     where <callsign> is someone's callsign who is known to be  on  the  air.
     You  can  also  specify a digipeater string. For example, you could type
     one of:

          connect ax0 n3eua              (connect using the ax0 TNC to N3EUA)
          connext ax0 n3eua n1fed n0ccz  (conn to N3EUA via N1FED and N0CCZ)

     If all is well, you should get "Conn Pending" and then "Connected"  mes-
     sages.  At this point, you're connected just like using a plain old TNC.
     Kind of boring, huh?  It'll get more exciting soon!

     When you're ready to disconnect, use the <F10> key to  escape  from  the
     session back to the 'net>' prompt, and then type 'disconnect'.  You will
     discover that all commands can be abbreviated, and you can type a

     If things don't work, watch the lights on  the  TNC  to  see  if  you're
     transmitting  at  all, then go read up on the "trace" command so you can
     see what the program thinks it's doing.  Even easier, if there's someone
     else using TCP in your area, ask for help!

     3.2.  The Telnet Command

     If there's someone else on the air in your area  already  using  TCP/IP,
     then  the  next  most  easy  thing to do is to try a keyboard connection
     using the Telnet protocol. The end result will be the same as  doing  an
     AX.25  connect in most cases, but you'll be taking advantage of a couple
     of neat attributes of having more protocol horsepower to help you out.

     First, you need to either know the numeric IP address of  your  friend's
     system, or you need to have updated HOSTS.NET to include the system name
     and the numeric address.  Then all you have to do is type:

          telnet n3eua            (talk to N3EUA, address in HOSTS.NET)  tel-
          net [44.32.0.4]      (use the numeric address directly)










                                      - 40 -


     Now you can type back and forth just as if you  were  connected  with  a
     normal  TNC.  When you're done, use the <F10> key to escape back to com-
     mand mode, and then type 'close' to close the connection gracefully,  or
     'reset' if you're really in a hurry.

     3.3.  The FTP Command

     So far, all we've done is to use more software and work harder to do the
     same  things we can do with a plain old TNC.  The FTP command isn't like
     that!  If you want to get a file from your  friends'  machine,  you  can
     type the command:

          ftp n3eua
     to start a file transfer session to the N3EUA machine.  When the connec-
     tion is opened, you'll get a banner from the remote machine, followed by
     a prompt for your user name.  If you've negotiated with your  friend  to
     have  a  special  username  and  password set up for you in his FTPUSERS
     file, use that. If not, many machines allow arbitrary users to get  lim-
     ited  access to the files available with a special username 'anonymous'.
     If you want to use the 'anonymous' login, when  you're  prompted  for  a
     password  enter  your  callsign  or something else recognizable, as many
     folks keep a log of FTP's so they know what files people care about, and
     being able to associate your activities with you sometimes helps.

     3.4.  The Mail System

     The mail system is a subject unto itself. It is also one  of  the  truly
     nifty  things about running TCP/IP.  Look elsewhere in the documentation
     for a complete rundown on how to install and operate the BM mailer,  and
     the portions of NET related to it.

     3.5.  Tracing and Status Commands

     The tracing and status commands provide  a  great  deal  of  information
     about  what  is  going on in the system. All we'll attempt to do here is
     raise your interest level.

     If you want to find out what  sessions  are  active  to  and  from  your
     machine,  you can type 'sessions' and you'll get a list.  If you want to
     get information about all of the TCP connections open to and  from  your
     machine,  including  mail transfers and other things that don't directly
     interact with your keyboard and screen, you can type  "tcp  status"  and
     you'll get a list of connections.

     If you're not sure what's happening on an interface, or  you'd  like  to
     "read  the mail" (watch what other folks are doing ont he channel), then
     use the "trace" command.  The form is descibed in the command  reference
     elsewhere in this document.  For example:

          trace ax0 111         (activity on ax0, including ASCII dump) trace
          ax0  211         (activity on ax0, including hex dump) trace ax0 11
          (activity on ax0, printing only the headers)

     Note that you also have control over whether tracing can bother you in a









                                      - 41 -


     session, see the trace command summary for more details.






























































                                      - 42 -


     4.  The Mail System

     As is typical with networking  software,  handling  electronic  mail  is
     often  as  big a job as coping with all other applications combined.  In
     order to make full use of the mail system in the KA9Q package, you  will
     need to spend a little time getting things configured for your system.

     4.1.  Installing and Using BM

     The BM.EXE mail user interface program  was  created  by  Bdale  Garbee,
     N3EUA,  and  despite  popular  belief,  'BM'  really stands for "Bdale's
     Mailer".  Gerard van der Grinten  PA0GRI  extended  the  mailer  with  a
     number  of new features that resulted in version 2.  More recently, Dave
     Trulli NN2Z has extended the mailer creating revision 3.   All  comments
     or suggestions about BM should be directed to Dave.

     BM provides a full set of mail services to the user which allow  sending
     and  receiving electronic mail, as well as a variety of local mail mani-
     pulation commands.

     4.1.1.  Installation

     To install BM requires the modification  of  the  supplied configuration
     files  and  the  creation  of  the  proper directory structure. The fol-
     lowing sections describe  the file and directory structure  used  by  BM
     and SMTP.

     4.1.1.1.  Directory Structure

     /spool/mqueue   This directory  holds  the  outbound  mail
                     jobs  for  SMTP.  Each  job  consists of 2
                     files a xxxx.txt and xxxx.wrk  file  where
                     xxxx  is  a  unique numerical prefix.  The
                     format of the files  are  described  in  a
                     later section.

     /spool/rqueue   This directory is used by  SMTP  for  jobs
                     that   have  been  received  and  will  be
                     processed by a user defined  mail  routing
                     program.    This  directory  is  not  used
                     directly by BM.

     /spool/mail     This  directory   holds   the   individual
                     mailboxes  for  each  user  name  on  your
                     system. The extension .txt is add  to  the
                     user  name  to form the mailbox name. Mail
                     received by the SMTP server is appended to
                     the mailbox file.

     4.1.1.2.  Configuration File

     The /bm.rc file provides  BM  with  the  configuration  needed  for  the
     operation of the mailer.










                                      - 43 -


     The format for the /bm.rc file is:

             variable <space>  value <newline>

     The following variables are valid in the bm.rc file:


     4.1.1.2.1.  smtp <path>

     Defines the path to the directory containing  the  mailbox files.    The
     default  directory  is  /spool/mail  on  the current drive.

     4.1.1.2.2.  host <your hostname>

     Is used to set the local hostname for use  in  the  RFC822 mail headers.
     This  is a required field.  This should match the hostname definition in
     autoexec.net.

     4.1.1.2.3.  user <username>

     Defines the user name of the person who is  sending  mail.  This is also
     used  as  the  default mailbox for reading mail.  On the AMPRNET this is
     usually set to your call.  There is a DOS limit of 8 characters for  the
     user name.

     4.1.1.2.4.  edit <path of your editor>

     Defines the name of your favorite editor which can be used to  construct
     and  edit the text of outgoing messages.  The use of edit is optional.

     4.1.1.2.5.  fullname <your full name>

     Is used to provide your full name to the mailer for use in the   comment
     portion  of "From:" header line.  The use of fullname is optional.

     4.1.1.2.6.  reply <return address>

     Defines the address where you wish  to  receive   replies   to  messages
     sent.   This  option  is  useful if you are operating your pc on a local
     area network and would like  your  mail replies  sent  to  a  more "well
     known  host".  The address specified by reply  is  used  to  generate  a
     "Reply-To:" header  in outbound mail. The "Reply-To:"  header  overrides
     the  "From:"  header  which  is  the address normally  used  to reply to
     mail. This field is optional.

     4.1.1.2.7.  maxlet <number of messages>

     defines  the  maximum  number  of  messages  that  can  be processed  by
     BM  in one mailbox file. The default value of maxlet is 100.

     4.1.1.2.8.  mbox <filename>

     Specifies the default file  to  be   used   for   the   "save"  command.
     This  file  is  in  the same format as a mailbox and may later be viewed









                                      - 44 -


     using the -f option  of  BM.  If  this  option  is  not  used  then  the
     default is set to mbox.

     4.1.1.2.9.  record <filename>

     If defined a copy of each message sent will  be  saved  in <filename>.

     4.1.1.2.10.  folder <directory name>

     If defined folder contains  the  path  used  by  the  save command.

     4.1.1.2.11.  screen [bios|direct]

     In the Turboc compiled version  of  BM,  screen  sets  the display  out-
     put  mode to use either direct writes to screen memory or the ROM  BIOS.
     The  default  is  direct  which provides  the   fastest   output   mode.
     If  you are using a windowing system such as Desqview you should set the
     mode to bios.

     4.1.1.2.12.  Example BM.RC File

          host nn2z.ampr user dave fullname Dave Trulli # send my replies  to
          the  Sun  reply  [e-mail] screen  direct edit /bin/vi
          mbox c:/folder/mbox record c:/folder/outmail folder c:/folder  max-
          let 200

     4.1.1.3.  The ....lias File

     The alias file provides  an  easy way to  maintain  mailing  lists.   An
     alias  can  be  any  string of characters not containing the "@" symbol.
     The  format for the alias file is:

                    alias   recip1 recip2 recip3
                    <tab>   recip4

     Note that a long list of aliases can be  continued   on   an  additional
     line  by  placing  a  tab  or  space  on  the continuation line.

     Some examples aliases are:

                    dave    [e-mail]

                    phil    [e-mail]

                    # mail to local nnj users
                    nnj     [e-mail] [e-mail]
                            [e-mail] [e-mail]

     In  the  above  example,  when  specifying  nnj    as    the  recipient,
     BM  will  expand  the  alias  into the list of recipients from the alias
     file.  At this time an alias may not contain any other aliases.












                                      - 45 -


     4.1.1.4.  /spool/mqueue/sequence.seq The sequence file maintains a  mes-
     sage  counter  which  is used by BM and SMTP to generate message ids and
     unique filenames. This file is created if not already present by BM.

     4.1.2.  Environment

     The timezone used in mail headers is obtained from the  DOS  environment
     variable TZ. An example TZ setting is:

             set TZ=EDT4

     It  is  set  in  your  AUTOEXEC.BAT  file.  The   first    3  characters
     are   the  timezone and the fourth character is the number of hours from
     GMT time. If TZ is not  set,  GMT is assumed.

     4.2.  Commands

     All BM commands are single letters  followed   by   optional  arguments.
     The  command  list  has been designed to make those familiar with Berke-
     ley mailers comfortable with BM.

     4.2.1.  Main Menu Commands

     4.2.1.1.  m [userlist]

     The mail command is used to send a message to one or   more  recipients.
     All  local  recipient  names  (  those  which don't contain an '@' ) are
     checked for possible aliases.  If  no  arguments    are   supplied   you
     will   be   prompted   for   a recipient list.  While entering a message
     into  the  text buffer several commands are available such as:  invoking
     an  editor,  and reading in text from other messages or  files.  See the
     section below for a description of these commands.   To  end  a  message
     enter a line containing a single period.

     It is important to remember that the input line buffer has a  128  char-
     acter   limit.   You   should  format  your  text by entering a carriage
     return at the end of each line. Typing excessively    long   lines   may
     cause   data   loss  due  to truncation when passing the message through
     other  hosts.  Keeping  lines  less  than  80  characters  is  always  a
     good idea.

     4.2.1.2.  d [msglist]

     Mark messages for deletion.  Messages marked for  deletion are   removed
     when   exiting  BM  via the 'q' command or when changing to an alternate
     mailbox with the 'n' command.

     4.2.1.3.  h

     Display message headers.  The  message  headers   contain   the  message
     number,  the  status indicating whether it has been read or deleted, the
     sender, size, date, and subject.











                                      - 46 -


     4.2.1.4.  u [msglist]

     Undelete a message that is marked for deletion. The status of   a   mes-
     sage   can  be  determined by looking at the status field of the message
     using the 'h' command.

     4.2.1.5.  n [mailbox]

     Display or change mailbox.  The  'n'  command  with  no  arguments  will
     display   a   list  of mailboxes containing mail. If an argument is sup-
     plied, then the current mailbox  is  closed and a new mailbox is opened.

     4.2.1.6.  ! cmd

     Run a DOS command from inside BM. An  error   message   will  result  if
     there is not enough memory available to load the command.

     4.2.1.7.  ?

     Print a help menu for BM commands.

     4.2.1.8.  s [msglist] [file]

     The 's' command is used to save messages in a  file.   If   no  filename
     is   given  the default from the mbox variable in /bm.rc is used.  If no
     message number is supplied then the current  message   is   saved.   The
     message  is  stored  in  the same format as a mailbox file with all mail
     headers  left intact.

     4.2.1.9.  p [msglist]

     The 'p' command is used to send  messages  to  the  printer.  This  com-
     mand   uses  the  DOS device PRN for output.  This command is equivalent
     to:
          s [ msglist ] PRN

     4.2.1.10.  w [msglist] file

     The 'w' command is used to save messages in a  file.  Only  the  message
     body   is  saved. All mail headers are removed.  If no message number is
     supplied then the current message  is saved.

     4.2.1.11.  f [msg]

     The 'f' command is used to forward a mail message to another  recipient.
     If  no message number is supplied the current message is used.  The user
     is prompted for the  recipients and  a  subject. The  RFC822  header  is
     added  to the message text while retaining the complete original message
     in  the body.  Also see the ~m command.

     4.2.1.12.  b [msg]

     Bounce a message. Bounce  is  similar  to  forwarding  but  instead   of
     your    user    information,    the   original  sender  information   is









                                      - 47 -


     maintained.   If  no  message  number  is supplied the  current  message
     is used.

     4.2.1.13.  r [msg]

     Reply to a message. Reply reads the header  information   in  order   to
     construct  a  reply  to the sender. The destination information is taken
     from  the  "From:"  or  the  "Reply-To:" header,  if  included.   If  no
     message number is supplied the current message is used.

     4.2.1.14.  msg#

     Entering  a message number from the  header   listing   will  cause  the
     message text to be displayed.

     4.2.1.15.  l

     List outbound messages.  The job number, the  sender,  and the  destina-
     tion  for  each message is displayed. A status of "L" will appear if the
     SMTP sender has the file locked.

     4.2.1.16.  k [msglist]

     Remove an outbound message from the mqueue.  A message can  be   removed
     from   the  send  queue  by specifying the job number obtained by the  l
     command.   If  the  message  is locked  you will be warned that you  may
     be  removing  a  file  that  is  currently being sent by SMTP. You  will
     asked  if this job should still be killed.

     4.2.1.17.  $

     Update the mailbox.  This   command   updates   the   mailbox,  deleting
     messages   marked for deletion and reading in any new mail that may have
     arrived since entering BM.

     4.2.1.18.  x

     Exit to DOS without changing the data in the mailbox.

     4.2.1.19.  q

     Quit to DOS updating the mailbox.

     4.2.2.  Text Input Commands

     The  following  commands  are  available  while   entering message  text
     into the message buffer.

          ~r <filename>  read <filename> into the message buffer.

          ~m <msg #>     read <msg #> into the message buffer.

          ~p             display the text in the message buffer.










                                      - 48 -


          ~e             invoke the editor defined in /bm.rc with  a
                         temporary  file  containing the text in the
                         message buffer.

          ~q             Abort the current message. No data is sent.

          ~~             Insert a single tilda  character  into  the
                         message.

          ~?             Display help menu of tilda escape commands.

     4.2.3.  Command Line Options BM may be invoked as follows:

     To send mail:
          bm [ -s subject ] recip1 .. .. recipN

     To read mail:
          bm [ -u mailbox | -f file ]

               -s subject     This option sets the subject to the text on
                              the command line.

               -u mailbox     Specify  which  mailbox  to   read.   This
                              overides the default from the bm.rc.

               -f file        Read  message  from  "file"  instead  of  a
                              mailbox.

     4.3.  Technical Information

     4.3.1.  Outbound Mail Queue File Formats

     Outgoing mail messages consist of two files each in  the   /spool/mqueue
     direc-  tory.    The   names   of   the  two  files  will be of the form
     <integer>.WRK and <integer>.TXT, where integer is the sequence number of
     the message relative to this  machine.   The  file  sequence.seq  in the
     mqueue directory contains the current sequence number for  reference  by
     the  mail user  interface.   The  .TXT file contains the data portion of
     the SMTP transaction, in full RFC822 format.  The .WRK file consists  of
     3 or more lines, as follows:

          the hostname of the destination system

          the full sender address, in user@host format.

          some number of full destination addresses, in user@host format.

     4.3.2.  Standards Documents

     The SMTP specification is RFC821. The Format for text messages  (includ-
     ing  the headers) is in RFC822. RFC819 discusses hostname naming conven-
     tions, particularly domain naming.











                                      - 49 -


     4.4.  Bug Reports

     Please send any comments, suggestions or bug reports about BM to:

          Dave  Trulli  Usenet:  [e-mail]   packet:   nn2z@nn2z
          AMPRNET: [e-mail] [44.64.0.10]

























































                                      - 50 -


     5.  NET/ROM Support

     5.1.  Introduction The NET/ROM support for the KA9Q package serves three
     purposes:

             1) Existing NET/ROM networks may be used to send IP traffic.

             2) NET may be used as a NET/ROM packet switch.

             3) NET may be used to communicate with NET/ROM  nodes,  and  its
                 mailbox  facility  can accept connects over the NET/ROM net-
     work.

     5.2.  Setting up the NET/ROM Interface

        No physical interface is completely dedicated to net/rom, which is as
     it  should  be.  You attach all your AX.25 interfaces, of whatever sort.
     Then you attach the net/rom pseudo-interface  ("attach  netrom").   Then
     you  identify to the net/rom software those interfaces you want to allow
     it to use, with the "netrom interface" command.  The format of this com-
     mand is:

             netrom interface ax0 #ipnode 192

     The first argument is the name of the previously attached interface  you
     want  to use.  The second argument is the alias of your node, to be used
     in your routing broadcasts.  The alias is never used for  anything  else
     (as  you  will  see!).   The  last number is the net/rom quality figure.
     This is used in computing the route qualities; it represents the contri-
     bution  of  this  interface to the overall computation.  For a 1200 baud
     half-duplex connection, 192 is the right number.

        You need a netrom interface command for every interface you're  going
     to use with net/rom.

     5.3.  Tracing on the NET/ROM Interface

        If you want to trace your NET/ROM datagrams,  don't  try  turning  on
     trace  mode for the "netrom" interface.  Nothing will break, but nothing
     will happen.  You should trace the individual AX.25 interfaces instead.

     5.4.  Routing Broadcasts

        Once you have set up your interfaces, you need to  set  some  timers.
     There are two:  the nodes broadcast interval timer, and the obsolescence
     timer.  These are set in seconds, like the smtp timer.  You should  usu-
     ally  set  them to an hour.  You can set them to something different, if
     you want.  If your local net/rom nodes broadcast  every  hour,  but  you
     want to do so every ten minutes, you can say:

             netrom nodetimer 600         netrom obsotimer 3600

     Every time the obsotimer kicks, the obsolescence  counts  for  all  non-
     permanent  entries  are decremented by one.  When the count for an entry









                                      - 51 -


     falls below five, it is no longer broadcast.  When it falls to 0, it  is
     removed.  The count is initialized at 6.  These will eventually be sett-
     able parameters; you can adjust them now by  changing  the  initializers
     for the variables in the source file.

        When you first come on the air, you can send out nodes broadcasts  to
     tell the local nodes that you are available.  Use the command:

             netrom bcnodes ax0

     where ax0 is the interface on which you want to send the broadcast.   Do
     this for every interface on which you want to do this.

        By default, the NET/ROM code does not broadcast the contents of  your
     routing  table.   This is as it should be, since usually we just want to
     be the endpoints of communications rather than relaying NET/ROM traffic.
     If you want to be a switch station, include the command:

             netrom verbose yes

     in your autoexec.

        Sometimes you can hear broadcasts from nodes that can't hear you.  If
     your  routing  table  gets  filled with these unusable routes, your node
     will grind to a halt.  The solution to this is node broadcast filtering,
     via  the  netrom nodefilter command.  There is a filter list, which con-
     tains a list of callsigns and interfaces.  Then there is a filter  mode,
     which indicates what to do with the list.

        If the filter mode is  "none",  no  filtering  is  done.   If  it  is
     "accept",  then only broadcasts from the indicated stations on the indi-
     cated interfaces are accepted.  If it is "reject", then  all  broadcasts
     except  those  from  the  listed  stations  on the listed interfaces are
     accepted.

        Because the net/rom code  cannot  at  this  time  recognize  unusable
     routes  and  try alternates, I strongly recommend use of the filter com-
     mand to restrict broadcast acceptance to those nodes which you know  you
     can reach.

     5.5.  The NET/ROM Routing Table

        The next net/rom commands are those used for maintaining the  routing
     table.   They  fall  under  the "netrom route" subcommand.  "netrom add"
     adds a permanent entry to the routing table.  Its format is:

             netrom route add #foo w9foo ax0 192 w9rly

     This command adds an entry for w9foo, whose alias is #foo, route quality
     192,  via  w9rly  on  interface  ax0.  Let's talk about what this means.
     w9foo is the *destination* node, the one to whom you  want  the  packets
     routed  by  the  net/rom network.  w9rly is your *neighbor*, the net/rom
     node to which you pass the packet to  be  forwarded.   Since  w9rly  may
     appear on more than one interface (the callsign may be used by more than









                                      - 52 -


     one net/rom node on different bands), we specify that we are to use  ax0
     to send the packet.

        With net/rom, like IP, we don't know exactly what route a packet will
     take  to its destination.  We only know the name of a neighbor which has
     indicated a willingness to forward that packet (of course, the  neighbor
     may  be the destination itself, but that's unlikely in our application).
     Net/rom sends the packet to the neighbor, with a network header specify-
     ing  our  callsign  and  that  of the ultimate destination (in this case
     w9foo).

        We can use the netrom route add command  to  establish  a  digipeater
     path to the neighbor.  For example:

             netrom route add #foo w9foo ax0 192 w9rly wd9igi

     This will cause us to use wd9igi as a  digipeater  in  establishing  our
     connection to the net/rom node w9rly.

        To drop the route to w9foo, you would type

             netrom route drop w9foo w9rly ax0

        To see the contents of your routing table, you may type

             netrom route

     and to see the routing entries for an individual station you can type

             netrom route info <callsign>

     You may not use an alias as an argument to the netrom  route  info  com-
     mand.

        I can not stress enough that "route add" and "netrom route  add"  are
     two  different  commands, with different purposes.  In general, you only
     need a "netrom route add" if you need to add a route to a  net/rom  node
     via  a  digipeater  path.   If you find yourself using this command, ask
     yourself, "Why am I doing this?"  Many people  do  not  understand  that
     net/rom does automatic routing (well, sort of :-)).

     5.6.  The Importance of the Routing Table

        The NET/ROM routing table is analogous to the IP routing  table:   if
     there  is nothing in it, your NET/ROM traffic will not go out.  You must
     either manually enter a list of routes (perhaps via  your  autoexec.net)
     or  wait  to  receive routing broadcasts from your neighbors before your
     NET/ROM traffic will leave your station.

        If you go to send packets via NET/ROM and nothing  happens,  even  if
     you  have  trace mode on, make sure that the destination node is in your
     NET/ROM routing table.  If sending IP  traffic,  double  check  the  ARP
     table for an appropriate NET/ROM ARP entry for the destination node (see
     below for more information on the use of the ARP table).  The ARP  table









                                      - 53 -


     is not used for NET/ROM transport routing.

     5.7.  Interfacing with NET/ROMs Using Your Serial Port

        What if you have a net/rom node or nodes, and you'd  like  to  attach
     them  to  your  computer  via  their serial interfaces, and use net as a
     packet switch?  It's very easy:  you have to  attach  those  interfaces,
     using  the  "attach  asy"  command, but specifying type "nrs" instead of
     "slip" or "kiss".  "nrs" is the net/rom serial framing  protocol,  which
     is  like  KISS,  but  uses different framing characters and has an 8-bit
     checksum.

        When you attach an nrs interface, it  can  be  used  for  passing  IP
     datagrams  or  AX.25  frames over serial lines or modems.  To use it for
     net/rom, you have to identify it to the netrom code just like any  other
     interface, with the "netrom interface" command.

     5.8.  The Time to Live Initializer

        The "netrom ttl" command allows setting of the time-to-live  initial-
     izer  for  NET/ROM  datagrams.   I recommend a value of 16 for most net-
     works.  Use more if you expect to go more than 16 hops.  The default  is
     64.

        The purpose of the ttl initializer is to prevent a packet  from  get-
     ting  caught  forever  in  routing  loops.  Every router who handles the
     packet decrements the ttl field of the network datagram  before  sending
     it on, and when it reaches 0 it is discarded.

     5.9.  Using NET/ROM Support for IP

        Now you know all the commands, but how do we actually use net/rom for
     IP communications?  This takes two steps:

        Step one:  update the routing table.  In all likelihood, you will use
     net/rom to gateway two IP subnets.  So, you'll probably want to identify
     a station on each end as a gateway.  Let's say we're  on  the  Milwaukee
     subnet,  and  we  want  to talk to someone in Madison.  If we're not the
     gateway, we just have a routing table entry like this:

             route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr

     This specifies that wg9ate should get all packets for the 44.92.0.x sub-
     net via interface ax0.

        Wg9ate has this routing table entry:

             route add [44.92.0.0]/24 netrom w9mad-pc.ampr

     (presuming that w9mad is the Madison gateway).  Now, when the  IP  layer
     at  wg9ate gets datagrams for Madison, it knows that they have to go via
     net/rom to w9mad.  Notice that we don't specify a "real" interface, like
     ax1 or nr0, in the route entry.  The net/rom network layer will pick the
     right interface based on its net/rom routing tables.









                                      - 54 -


        We're not done yet, though.  w9mad-pc.ampr is not an ax.25  callsign.
     The net/rom send routine called by the IP layer needs to map from the IP
     address to an ax.25 address.  It does this  via  a  manually  added  arp
     entry:

             arp add w9mad-pc.ampr netrom w9mad

     [We kind of fudged by using the arp table for this purpose, since  there
     is  no  way to do automatic address resolution for net/rom, and arp mes-
     sages are never sent or received for net/rom nodes.   However,  the  arp
     table  does  contain  precisely  what  we  have  here:  mappings from IP
     addresses to callsigns, and it saved a lot of code to do it this way.]

     Notice also that no digipeaters are ever specified in the arp entry  for
     a net/rom node.  Also, the callsign to which we are mapping is the final
     destination of the  packet,  not  the  non-destination  neighbor.   That
     neighbor will be picked based on the net/rom routing tables.

        So, as a summary, let's look at what happens to a packet that reaches
     the IP layer on wg9ate, destined for Madison.  The IP routing code looks
     the destination IP address up in the table, and discovers that it should
     go  via  net/rom  to  w9mad-pc.ampr.   So,  it  passes the packet to the
     net/rom send routine.  That routine uses  the  arp  table  to  translate
     w9mad-pc's  IP  address  to  the  callsign  "w9mad".  Then it passes the
     packet to the net/rom routing code.  That code checks to see if the des-
     tination  callsign  (w9mad)  is  the same as that of any of its assigned
     net/rom interfaces.  Since it isn't, it  puts  a  network  layer  header
     (a.k.a.  net/rom level 3 header) on it, and looks for w9mad in its rout-
     ing tables.  Presumably,  it  finds  an  appropriate  neighbor  for  the
     packet, and sends in out via ax.25.  The net/rom network does the job of
     actually getting the packet to its destination.

        At w9mad, the packet's protocol ID causes it to be sent to  the  same
     net/rom  routing code that handled the outgoing packet from wg9ate (run-
     ning on a different computer, of course).  Now the destination  callsign
     matches, so the net/rom network layer header is stripped off, and packet
     is passed up to the IP layer.  (Net/rom network  headers  don't  have  a
     protocol  ID  byte,  so  we  just  hope for the best.  If a net/rom node
     addresses a net/rom transport layer packet to us, it  is  likely  to  be
     dropped by IP for any of a number of reasons.)

     5.10.  The NET/ROM Transport Layer

        NET/ROM transport is the protocol used by NET/ROM node to communicate
     end-to-end.  When a user attaches to a NET/ROM via AX.25, and asks for a
     connect to a node in the NODES list, his local NET/ROM tries to  open  a
     transport  connection  to the destination node over the NET/ROM network.
     NET/ROM transport packets are carried in NET/ROM network datagrams, just
     like IP datagrams.

        You shouldn't use NET/ROM transport when connecting to  other  TCP/IP
     stations.   TCP  is  a  much better protocol than NET/ROM transport, and
     makes better use of available bandwidth.  Also, BM  and  SMTP  are  more
     convenient  to  use  than a TCP/IP station's mailbox facility.  However,









                                      - 55 -


     for communicating with AX.25 users via the NET/ROM  network,  the  tran-
     sport  facilities  in  NET  will  work better (and more easily) than the
     traditional method of connecting to your local node via AX.25.

     5.11.  Connecting via NET/ROM Transport

        To connect to the node whose alias  is  FOO  and  whose  callsign  is
     W9FOO, you can issue either of the following two commands:

             netrom connect foo

             netrom connect w9foo

     If foo:w9foo is  in  your  NET/ROM  routing  table,  your  station  will
     transmit  a  connect  request  to the appropriate neighbor used to reach
     w9foo.

        NET/ROM transport sessions are very much like those for  AX.25.   You
     can  use  the  disconnect, reset, kick, upload, and record commands, and
     the session command to switch sessions.

     5.12.  Displaying the Status of NET/ROM Connections

        The command

             netrom status

     is used to display the status of all  NET/ROM  connections,  which  will
     include  those used in keyboard sessions as well as ones attached to the
     mailbox.  For more detailed information on a session, you  can  use  the
     address of the NET/ROM control block:

             netrom status <&nrcb>

     where <&nrcb> is the hex address given in the short form of the  command
     or in the "session" display.

     5.13.  NET/ROM Transport Parameters

        The NET/ROM transport parameters may be set with the various  NET/ROM
     subcommands.  Their meanings are listed below:

             acktime:        This is the ack delay timer,  similary  to  ax25
     t2.                                  The default is 3000 ms.

             choketime:      The time to wait before breaking  a  send  choke
     condition.                                    Choke   is  the  term  for
     NET/ROM flow control.

             irtt:           The initial round  trip  time  guess,  used  for
     timer setting.

             qlimit:         The maximum length of the receive queue for chat
     sessions.                                    This  is  similar  to  ax25









                                      - 56 -


     window.

             retries:        Maximum retries on connect, disconnect, and data
     frames.

             window:         Maximum sliding window size, negotiated down  at
     connect                                 time.


     5.14.  The Mailbox

        The AX.25 mailbox also accepts NET/ROM connections.   The  "mbox  on"
     and  "mbox  off"  commands  control whether the mailbox is turned on for
     NET/ROM as well as AX.25, and the "mbox" command displays current  mail-
     box connects of both types.

        Many people have observed that the AX.25 mailbox requires the user to
     enter  a  carriage  return  to  bring up the banner and prompt.  This is
     because of certain defects of that protocol when it is used as the  link
     layer  for several different higher level protocols, and is unavoidable.
     (So stop asking, OK? :-))  The NET/ROM mailbox does not require the car-
     riage  return,  and will be activated as soon as the incoming connection
     is completed.

     5.15.  Where to go for More Information

        The paper  "Transmission  of  IP  Datagrams  over  NET/ROM  Networks"
     appeared  in  the  Seventh  ARRL Networking Conference papers, available
     from the ARRL.  In it, I describe the more technical details of how  the
     NET/ROM network support works.

        If you want to learn about NET/ROM, talk your local NET/ROM or TheNET
     operator  out of his or her manual.  If you want to learn more, read the
     source code.  That's about it for sources, since the  NET/ROM  protocols
     originated in a commercial product.

     5.16.  About the Code

        There has been a great deal of controversy about TheNET, a  no-charge
     NET/ROM  clone  for TNCs.  This is not the place to discuss the truth of
     the charges leveled by Software  2000  against  its  authors,  but  that
     situation requires me to make the following statement:

        The NET/ROM transport support in NET.EXE was not taken  in  any  way,
     shape  or  form  from  NET/ROM  (whose source I have never seen) or from
     TheNET.  The protocol code is  based  on  protocol  6  from  Tanenbaum's
     excellent  book,  Computer  Networks, as a moderately careful reading of
     both should show.  The source code is freely distributed, so the curious
     reader  should have the opportunity to check this assertion if he or she
     so desires.

        The smoothed round trip time calculation, which is not done in "real"
     NET/ROMs  (and  should be, by the way -- they'd work a whole lot better)
     is adapted from that used by KA9Q in the TCP protocol in NET.  The dicey









                                      - 57 -


     business  of  adapting  it  to a sliding windows protocol with selective
     retransmission was done by me, all alone, after my cries for help on the
     tcp-group mailing list went unanswered :-).

        I have taken the precaution of copyrighting the NET/ROM code in  NET.
     It may be freely distributed for non-commercial purposes, in whole or in
     part, and may be used in other software packages such as BBS systems  if
     so  desired,  so  long  as  the copyright notice is not removed from the
     source files, and the program in which it is used displays "NET/ROM code
     copyright 1989 by Dan Frank, W9NK" when it starts up.

        Any person who wishes to distribute the code, or  anything  based  on
     the  code,  for  commercial  purposes  will find me very reasonable, but
     rather insistent about being compensated for the hours I've spent  work-
     ing on it.
















































                                      - 58 -


     6.  Advanced Topics

     6.1.  The Finger Server

     < there will be finger docs here someday >

     6.2.  The GRAPES Multi-Port Digipeating Code

     The  multiport digipeating code from GRAPES  will  allow  you  to  route
     frames  in  and out of LANs semi-automagically  based  on a table lookup
     maintained  by  the switch.

     To enable multi-port digipeating, there are two tables that   you   must
     build  and  place  in  the root directory. They  are named  DIGILIST and
     EXLIST. DIGILIST contains the digis that  are directly   reachable  from
     your  switch.  The  file  is  a  simple  ASCII text  file containing the
     callsign of the digi and the  interface name   of  the  port  needed  to
     reach it. The port name is  the  same name you used in the attach state-
     ment for that port. Additionally there  is a special callsign "lan" that
     tells mulport which  port feeds your LAN or default port.

     The file would look something like this:

     kd4nc-1 ax1      # kd4nc-1 is a neighbor switch on the high speed link
                      # attached to ax1 wb4gqx-1  ax3      #  wb4gqx-1  is  a
     neighbor  digi  on 145.01 (ax3) k4hal-1 ax2      # k4hal-1 is a neighbor
     digi on 440 (ax2) lan  ax0         # lan is a special name for  the  low
     speed  lan
                      # attached to the switch and is the default port
                      # used when mycall is the last call in the  digi
                      # string.

     The file EXLIST holds DESTINATION callsigns that do not obey  the rules.
     For  example,  a  user  station on the high speed link. It  is formatted
     just like DIGILIST. To understand why this file  may   be  necessary  we
     review the rules mulport obeys.  First, mulport examines the digi string
     of incoming frames. If it finds  it's  call in the string and it is  not
     already   marked   as  repeated,  it  looks at the next call in the digi
     string. If  a match  is  found between the  call  following  MYCALL   in
     the   digi string and a call in DIGILIST, then the frame is repeated out
     the port associated with that call in DIGILIST. If no  match  is   found
     then the frame is repeated out the port it came in on. If  MYCALL is the
     LAST call in the digi string then it repeats the  frame  out  the   port
     associated  with  "lan" in the DIGILIST. So you see  that if  MYCALL  is
     the last or the only call  in  the  digi   string   the  frame  will  be
     repeated  out  the lan port. This can cause a problem if the station you
     wish to connect is only one digi hop away  and is  not  on  the lan fre-
     quency. The  EXLIST  handles  this  case. Mulport  will look at the DES-
     TINATION call if MYCALL is the  last or only call in the digi string. If
     a  match  is  found with a  call in EXLIST then the port associated with
     that DESTINATION call  is used  to repeat the frame. EXLIST  is only for
     stations  who  would normally be expected to be on the lan side  but are
     operating off some other port  instead.  An  example  might  be  a  PBBS
     operating on the trunk to serve more than one lan.









                                      - 59 -


     6.3.  Multiple Serial Ports on One Interrupt

     Thanks to effort from Dan Frank, W9NK, this version of net supports  the
     idea  of  multiple  serial ports all sharing a common hardware interrupt
     line. The original motivation for this was to support the IBM PS/2  fam-
     ily,  but it turns out to be very helpful with a variety of PC/AT inter-
     face cards as well.

     There are no new commands, and  existing  autoexecs  don't  need  to  be
     changed.  All  you have to do to share interrupts is simply use the same
     interrupt in more than one attach line. This applies *only* to asy  dev-
     ices. An interrupt may not be shared between, e.g., an ethernet card and
     a serial port.

     The code has been tested on an IBM PS/2 Model 70  with  the  dual  async
     adaptor.  Any card that logical-ORs the interrupt lines from the various
     UARTS should work.

     Interrupt sharing at the bus level does not work on the AT bus, but does
     work  on  the  Micro  Channel.  The PS/2 series uses interrupt 4 for the
     motherboard async port, then interrupt 3  for  all  bus-attached  serial
     ports.

     The code is  believed  to  work  with  both  level-sensitive  and  edge-
     triggered interrupts, but hasn't been fully tested.

     As an example, the Quadram Quadport AT with the add-on daughtercard  can
     handle up to five serial ports sharing the same interrupt, and up to two
     cards may be supported in a PC, making a total of more serial ports than
     a poor little PC should be asked to handle...

































                                      - 60 -


     7.  NET Command Reference

     7.1.  Startup

     When NET.EXE is executed without arguments, it  attempts  to  open   the
     file  "AUTOEXEC.NET"  in  the root directory of the current drive. If it
     exists, it is read and executed as though its contents were typed on the
     console  as   commands.  This feature is useful for setting the local IP
     address and host name, initializing the IP routing table,  and  starting
     the  various  Internet  services.   If   NET.EXE   is  invoked  with  an
     argument, it is taken to be the name of an alternate startup file; it is
     read instead of AUTOEXEC.NET.

     7.2.  Console Mode

     The console may be in one of two  modes:  command  mode   and   converse
     mode.  In  command  mode,  the prompt "net>" is displayed and any of the
     commands described in the next section may be entered. In converse mode,
     keyboard input is  processed  according  to the "current session", which
     may be either a Telnet, FTP, or AX.25 connection. In a telnet  or  AX.25
     session,  keyboard input is sent  to the  remote  system  and any output
     from the remote system is displayed on the console. In an  FTP  session,
     keyboard  input is first examined to see if it  is a  known  local  com-
     mand; if so it is executed locally. If not, it is  "passed  through"  to
     the remote FTP server. (See  the  section  titled  "FTP  Subcommands").

     The keyboard also has "cooked" and "raw" states. In cooked  state, input
     is  line-at-a-time;  the user may use the line editing characters ^U, ^R
     and backspace to erase the line, redisplay the  line   and   erase   the
     last  character, respectively. Hitting either return or line feed passes
     the complete line up to the application. In raw mode, each character  is
     immediately  passed  to  the application as it is typed. The keyboard is
     always in cooked state in command mode. It is also  cooked  in  converse
     mode  on  an  AX25  or  FTP  session.  In a Telnet session it depends on
     whether the remote end has issued (and the local end has  accepted)  the
     Telnet "WILL ECHO" option. (See the "echo" command).

     On the IBM-PC, the user may escape back to  command  mode   by   hitting
     the   F10  key.  On the HP Portable and Portable Plus, which have only 8
     function keys, F8 is used instead.  On  other  systems,  the  user  must
     enter  the  "escape"  character,  which is by default control-] (hex 1d,
     ASCII GS). (Note that this is distinct from  the  ASCII   character   of
     the  same  name).  The escape character can be changed (see the "escape"
     command).

     7.3.  Commands

     This section describes each of the commands recognized while in  command
     mode.   Note   that  certain  FTP subcommands, e.g., put, get, dir, etc,
     are recognized only in converse mode with the appropriate  FTP  session;
     they   are   not  recognized  while in command mode. The notation "<hos-
     tid>" denotes a host or gateway, which may be specified in  one  of  two
     ways:  as  a  symbolic name  listed  in the  file  "/hosts.net", or as a
     numeric IP address in dotted  decimal  notation  enclosed  by  brackets,









                                      - 61 -


     e.g.,  [44.0.0.1].  When  domain  server  support  is  added, ARPA-style
     domain  names  (e.g., ka9q.ampr) will  also  be  accepted  if  a  domain
     server is available on the network to resolve them into IP addresses.

     7.3.1.  <cr>

     Entering a carriage return (empty line) while in command mode  puts  you
     in  converse   mode  with  the  current  session. If there is no current
     session, net remains in command mode.

     7.3.2.  !

     An alias for the "shell" command.

     7.3.3.  #

     Commands starting with the hash mark (#) are ignored. This   is   mainly
     useful for comments in the AUTOEXEC.NET file.

     7.3.4.  arp

     With no arguments, displays the Address Resolution Protocol  table  that
     maps  IP  addresses  to  their  subnet  (link)  addresses on subnetworks
     capable of broadcasting. For each  IP  address  entry  the  subnet  type
     (e.g.,  Ethernet,  AX.25),  subnet  address  and time to  expiration  is
     shown. If the link address  is  currently  unknown,  the  number  of  IP
     datagrams awaiting resolution is also shown.

     7.3.4.1.  arp add <hostid> ether|ax25|netrom <ether addr|callsign>

     The add subcommand allows manual addition of address resolution  entries
     into  the table.  This is useful for "hard-wiring" digipeater paths, and
     other paths that are not directly resolvable.

     7.3.4.2.  arp drop <hostid> ether|ax25|netrom

     The drop subcommand allows removal of entries from the table.

     7.3.4.3.  arp publish <hostid> ether|ax25|netrom <ether addr|callsign>

     The publish subcommand allows you to respond to  arp  queries  for  some
     other  host.   This  is commonly referred to as "proxy arp", and is con-
     sidered a fairly dangerous tool.  The basic idea is that if you have two
     machines,  one  of which is on the air with a TNC, and the second one of
     which is connected to the first with a slip link,  you  might  want  the
     first  machine to publish it's own AX.25 address as the right answer for
     arp queries addressing the second machine.  This way, the  rest  of  the
     world  doesn't know the second machine isn't really on the air.  Use arp
     publish with caution.

     7.3.5.  attach

     attach <hwtype> <I/O  addr>  <vector>  <mode>  <label>  <bufsize>  <mtu>
     [<speed>]"









                                      - 62 -


     Configure and attach a hardware interface to the system.

     <hw type> represents the kind of I/O device  that  is  being   attached.
     The following types are some that are supported:

     packet  FTP, Inc., compatible Packet Driver Interface 3c500   3Com 3C500
     or  3C501  Ethernet interface asy     Standard PC asynchronous interface
     using the National 8250 hapn    Hamilton Amateur Packet Network  adapter
     board (Intel 8273) eagle   Eagle Computer card (Zilog 8530) pc100   PAC-
     COMM PC-100 (Zilog 8530)

     These last two interfaces  are  still  under  development;  driver  code
     included in this package may or may not work.

     <I/O address> is the base address of the control registers for the  dev-
     ice.

     <vector> is the interrupt vector number.   Both  the  address  and   the
     vector  must  be in hexadecimal. (You may put "0x" in front of these two
     values if you wish, but note that they will be interpreted in  hex  even
     if you don't use it).

     <mode> controls how  IP  datagrams  are  to  be  encapsulated   in   the
     device's link level protocol; i.e., it selects among several link proto-
     cols that may be available.  The choices here depend on  the  interface;
     at  present,  the  3c500 interface only supports mode "arpa", which uses
     standard ARPA-style encapsula- tion.  (In the  future,  "802"  may  mean
     "use  802.3-style  encapsulation").   Two modes for the "asy" device are
     currently supported:

     slip    Encapsulates IP datagrams directly in SLIP frames without a link
             header. This is for operation on  point-to-point  lines  and  is
             compatible with 4.2BSD UNIX SLIP).

     ax25    Similar to slip, except that an AX.25 header and a KISS TNC
             control header are added to the front  of  the  datagram  before
             SLIP    encoding.     Either    UI    (connectionless)    or   I
             (connection-oriented)  AX.25  frames  can  be  used;   see   the
             "mode" command for details.

     The Address Resolution Protocol (ARP) maps IP to Ethernet  addresses  on
     Ethernet  controllers and to AX.25 addresses on "asy" lines operating in
     "ax25" mode.

     <label> gives the name by which the  interface  will  be  known  to  the
     various commands, such as "connect", "route" and "trace".

     For asynchronous ports, <bufsize> specifies the size of the ring  buffer
     in  bytes   to  be statically allocated to the receiver; incoming bursts
     larger than this may (but not necessarily) cause data to be  lost.   For
     Ethernet,  <bufsize>  specifies   how  many PACKETS may be queued on the
     receive queue at one time; if this limit is exceeded,  further  received
     packets  will  be  discarded.   This  is useful  to  prevent  the system
     from running out of memory should another node suddenly develop  a  case









                                      - 63 -


     of diarrhea.

     <mtu> is the Maximum  Transmission  Unit  size,  in  bytes.    Datagrams
     larger  than   this   limit   will  be  fragmented  at the IP layer into
     smaller pieces. For AX.25 UI frames, this limits the size of the  infor-
     mation field.  For  AX.25  I frames,  however, the ax25 paclen parameter
     is also relevant.  If the datagram or  fragment  is  still  larger  than
     paclen,  it  is  also fragmented  at  the  AX.25 level  (as  opposed  to
     the  IP  level)  before transmission.  (See the  "ax25  paclen"  command
     for further information).

     <speed> is needed only for  an  "asy"  line;  the  controller  will   be
     initial- ized to the given speed.

     Examples:

      # Attach a 3Com Ethernet controller using the standard 3Com address and
      # vector (i.e., as it comes out of the box) to use ARPA-standard
      # encapsulation.  The receive queue is limited to 5 packets, and
      # outgoing packets larger than 1500 bytes will be fragmented

     attach 3c500 0x300 3 arpa ec0 5 1500

      # Attach the PC asynch card normally known as "com1" (the first
      # controller) to operate in point-to-point slip mode at 9600 baud,
      # calling it "sl0".  A 1024 byte receiver ring buffer is allocated.
      # Outgoing packets larger than 256 bytes are fragmented.

     attach asy 0x3f8 4 slip sl0 1024 256 9600

      # Attach the secondary PC asynch card ("com2") to operate in AX.25
      # mode with an MTU of 576 bytes at 9600 baud with a KISS TNC,
      # calling it "ax0".  By default, IP datagrams are  sent  in  UI  frames
     attach asy 0x2f8 3 ax25 ax0 1024 576 9600

     (Note that you cannot use the second asynch controller  ("com2")  and  a
     3Com  Ethernet   card  with standard addressing at the same time because
     they both use interrupt vector 3).

     7.3.5.1.  HP Portable Specifics For the unwary, the  following  are  the
     correct I/O address values for the HP Portable and Portable Plus... note
     that the <vector> is unimportant, but must  be  included  for  the  line
     parsing to work correctly.

     HP  Portable  Plus  Serial   Port    0x44   HP   Portable   Plus   Modem
     Port     0xa4 HP Portable                     0xa4


     7.3.5.2.  SLIP Modem Dialing

     An extension to the attach command allows the syntax:

        attach <hw type> <I/O address> <vector> <mode> <label> <bufsiz> <mtu>
               [<speed>] [[optional '-' for  debug]  <send>  <expect>  <send>









                                      - 64 -


     [...]]

     for slip connections only. The send/expect sequences allow you to dial a
     modem  on  the  slip  port, and negotiate a remote login to setup a slip
     link.

                     - - desend carriagedreturn
                     - N s-ndsendwNULL
                  E  -  send control-D
                     -   send  space   (not really  needed as the cmdparse routine allows quoting)
                  \  -  send backslash

     Note that an expect does not have to follow the last send.  Those  fami-
     liar  with UUCP will recognize the expect/send paradigm as being similar
     to that used in the L.sys or Systems file.

     7.3.6.  ax25

     7.3.6.1.  ax25 digipeat [on|off]

     Controls whether AX.25 packets addressed to  this  station  as  a  digi-
     peater will be repeated.

     7.3.6.2.  ax25 heard [on|off]

     Works like the 'mheard' function in many  TNC's.  The  command  with  no
     parameter  dumps the list of callsigns heard, with an option you control
     whether the list is updated or not.

     7.3.6.3.  ax25 maxframe [<val]>]

     Establishes the maximum number of frames  that   will   be  allowed   to
     remain  unacknowledged at one time on new AX.25 connections. This number
     cannot be greater than 7.

     7.3.6.4.  ax25 mycall [<call>]

     Display or set the local  AX.25  address.    The   standard  format   is
     used,   e.g.,  KA9Q-0 or WB6RQN-5. This command must be given before any
     attach command using AX.25 mode are given.

     7.3.6.5.  ax25 bbscall [<call>]

     Same as mycall, but sets the callsign of the W2XO BBS.  This  subcommand
     is only accessible when you compile net with XOBBS and SID2 defined. The
     default is to use a single callsign/ssid for both NET and the PBBS.

     7.3.6.6.  ax25 paclen [<val>]

     Limits the size of  I-fields  on  new  AX.25  connections.   Note   that
     if IP datagrams or fragments larger than this are transmitted, they will
     be transparently fragmented at the AX.25 level, sent as  a   series   of
     I  frames,   and  reassembled  back into a complete IP datagram or frag-
     ment at the other end of the link. This parameter should  be  less  than









                                      - 65 -


     the MTU of the associated interface.

     7.3.6.7.  ax25 pthresh [<val>]

     Sets threshold for transmit without <cr>.

     7.3.6.8.  ax25 reset <axcb>

     Deletes the AX.25 connection control block at the  specified address.

     7.3.6.9.  ax25 retry [<val>]

     Limits the number of successive unsuccessful retransmission attempts  on
     new   AX.25  connections.  If  this  limit  is exceeded, link re- estab-
     lishment is attempted. If this fails "retry" times, then   the   connec-
     tion is abandoned and all queued data is deleted.

     7.3.6.10.  ax25 status [<axcb>]

     Without an argument, displays a one-line summary of  each AX.25  control
     block.    If   the   address  of  a  particular  control block is speci-
     fied, the contents of that control block  are  dumped  in  more  detail.
     Note that the send queue units are frames, while the receive queue units
     are bytes.

     7.3.6.11.  ax25 t1|t2|t3 [<val>]

     Display  or  set  the  AX.25 timers  to  be used for new connections. T1
     is  the  retransmission timer, T2 is the acknowledgement delay timer and
     T3 is the idle "keep alive" timer.  Values are in seconds.

     7.3.6.12.  ax25 window [<val>]

     Sets the number of bytes that can  be  pending  on   an   AX.25  receive
     queue   beyond   which  I frames will be answered with RNR (Receiver Not
     Ready) responses.  This presently applies only to suspended  interactive
     AX.25 sessions, since incoming IP datagrams are always processed immedi-
     ately and not allowed to remain on the receive queue.

     7.3.7.  close [<session #>]

     On an AX.25 session, this command initiates a  disconnect.  On a FTP  or
     Telnet  session,  this  command sends a FIN (i.e., initiates a close) on
     the session's TCP connection.  This is  an  alternative  to  asking  the
     remote server  to initiate a close ("QUIT" to FTP, or the logout command
     appropriate for the remote system in the case of Telnet).   When  either
     FTP or Telnet  sees the  incoming  half  of  a  TCP connection close, it
     automatically responds by closing the outgoing half of  the  connection.
     Close  is  more  graceful  than  the "reset"  command,  in  that  it  is
     less  likely to leave the remote TCP in a "half-open" state.

     7.3.8.  connect <interface> <callsign> [<digipeater> ... ]

     Initiates a "vanilla" AX.25 session   to   the   specified   call   sign









                                      - 66 -


     using  the  specified  interface.  Up  to  7 optional digipeaters may be
     given; note that the word  "via"  is  NOT  needed.  Data  sent  on  this
     session  goes out in conventional AX.25 packets with no upper layer pro-
     tocol.  The de-facto presentation standard format is   used,   in   that
     each  packet holds one line of text, terminated by a carriage return.  A
     single AX.25 connection may be used for both  terminal-to-terminal   and
     IP   traffic,  with  the two types of data being automatically separated
     by their AX.25 Level 3 Protocol IDs.

     7.3.9.  dir [<dirname>]

     List the contents of the specified directory on  the   console.   If  no
     argument is given, the current directory is listed.

     7.3.10.  disconnect [<session #>]

     An alias for the "close" command (for the benefit  of AX.25 users).

     7.3.11.  echo [accept|refuse]

     Displays or changes the flag controlling client  Telnet's response to  a
     remote WILL ECHO offer.

     The Telnet presentation protocol specifies that  in  the  absence  of  a
     negotiated  agreement   to   the   contrary,  neither  end  echoes  data
     received from the other.  In this mode, a Telnet client  session  echoes
     keyboard  input  locally  and  noth- ing  is  actually sent until a car-
     riage return is typed. Local line editing is also  performed:  backspace
     deletes  the last character  typed,  while  control-U deletes the entire
     line.

     When communicating from keyboard to keyboard  the  standard  local  echo
     mode  is used,  so the setting of this parameter has no effect. However,
     many timeshar- ing systems (e.g., UNIX) prefer to do their  own  echoing
     of  typed  input.   (This  makes  screen editors work right, among other
     things). Such systems send a Tel- net WILL ECHO offer  immediately  upon
     receiving  an  incoming  Telnet  connection request. If "echo accept" is
     in effect, a client Telnet session will automati- cally return a DO ECHO
     response. In this mode, local echoing  and  editing  is turned  off  and
     each  key  stroke  is sent immediately (subject to  the  Nagle  tinygram
     algorithm in TCP).  While this mode is just fine across an  Ethernet, it
     is  clearly  inefficient  and  painful across  slow  paths  like  packet
     radio  channels.  Specifying  "echo refuse" causes an incoming WILL ECHO
     offer  to  be answered with a  DONT  ECHO;  the  client  Telnet  session
     remains  in  the  local  echo mode.  Sessions already in the remote echo
     mode are unaffected. (Note:  Berke- ley  Unix has a bug in that it  will
     still  echo input even after the client has refused the WILL ECHO offer.
     To get  around  this  problem,  enter  the  "stty -echo" command to  the
     shell once you have logged in.)

     7.3.12.  eol [unix|standard]

     Displays or changes Telnet's end-of-line behavior when in  remote   echo
     mode.   In   standard   mode,  each  key  is  sent  as-is. In unix mode,









                                      - 67 -


     carriage returns are translated to line  feeds.   This  command  is  not
     necessary  with   all   UNIX   sys- tems;  use  it only  when  you  find
     that a particular  system  responds  to  line  feeds  but  not  carriage
     returns.   Only  Sun UNIX release 3.2  seems  to  exhibit this behavior;
     later releases are fixed.

     7.3.13.  escape <char>

     Without arguments, displays the current command-mode escape character in
     hex.   If   given   an   argument,  the  first character becomes the new
     escape character.  (This command is not provided on the IBM-PC;  on  the
     PC,  the  escape  char  is always F10.)

     7.3.14.  etherstat

     Display 3-Com Ethernet controller statistics (if configured).

     7.3.15.  exit

     Exit the "net" program and return to MS-DOS (or CP/M).

     7.3.16.  finger

     For information on the Finger subsystem,  see  the  information  in  the
     advanced topics section of this manual.

     7.3.17.  ftp <hostid>

     Open an FTP control channel to the specified  remote  host   and   enter
     converse mode  on  the  new  session.

     When in converse mode with an FTP server, everything typed on the   con-
     sole   is  first  examined  to  see if it is a locally-known command. If
     not, the line is passed intact to the remote server on the control chan-
     nel.   If  it  is one of the following commands, however, it is executed
     locally. (Note that this generally involves other commands being sent to
     the  remote  server on the  control  channel.) When  actively  transfer-
     ring  a  file,  the only acceptable command is "abort"; all  other  com-
     mands  will  result  in  an  error  message.  Responses  from the remote
     server are displayed directly on the screen.

     7.3.17.1.  abort

     Aborts a get, put or dir operation in progress. When receiving a   file,
     abort  simply  resets the data connection; the next incoming data packet
     will generate a TCP RST (reset) in response which will clear the  remote
     server.   When   send-  ing a file, abort sends a premature end-of-file.
     Note that in both cases abort will leave a partial copy of the  file  on
     the  destination  machine,   which   must  be  removed manually if it is
     unwanted. Abort is valid only when a transfer is in progress.

     7.3.17.2.  dir [<file>|<directory> [<localfile>]]

     Without arguments, "dir" requests that a full directory listing  of  the









                                      - 68 -


     remote server's current directory be sent to the terminal.  If one argu-
     ment is given, this is passed along in the LIST command; this can  be  a
     specific file or  sub- directory  that  is meaningful to the remote file
     system. If two arguments are given, the second is  taken  as  the  local
     file  into  which  the  directory  listing should  be  put  (instead  of
     being sent to the console).  The PORT command is used  before  the  LIST
     command is sent.

     7.3.17.3.  get <remote_file> [<local_file>]

     Asks the remote server to send the file specified in the first argument.
     The  second   argument,  if  given,  will be the name of the file on the
     local machine; otherwise it will have the same name  as  on  the  remote
     machine.  The  PORT  and RETR commands are sent on the control channel.

     7.3.17.4.  ls [<file>|<directory> [<localfile>]]

     ls is identical to the "dir" command except that the "NLST"  command  is
     sent  to the  server  instead  of  the  "LIST"  command. This results in
     an abbreviated directory listing, i.e., one showing only the file  names
     themselves  without any other information.

     7.3.17.5.  mkdir <remote_directory>

     Creates a directory on the remote machine.

     7.3.17.6.  put <local_file> [<remote_file>]

     Asks the remote server to accept data, creating the file named  in   the
     first argument.  The  second argument, if given, will be the name of the
     file on the remote machine; otherwise it will have the same name  as  on
     the  local  machine.  The PORT and STOR commands are sent on the control
     channel.

     7.3.17.7.  rmdir <remote_directory>

     Deletes a directory on the remote machine.

     7.3.17.8.  type [a|i|l<bytesize>]

     Tells both the local client and remote server the type of file  that  is
     to  be transferred.  The default is 'a', which means ASCII (i.e., a text
     file).  Type length  lines   of   text   in  ASCII  separated  by  cr/lf
     sequences;  in  IMAGE mode, files are sent exactly as they appear in the
     file system.  ASCII  mode  should be  used  whenever  transferring  text
     between dissimilar systems (e.g., UNIX and MS-DOS) because of their dif-
     ferent end-of-line and/or end-of-file conventions.  When exchanging text
     files between machines of the same type, either mode will work but IMAGE
     mode may be somewhat faster.  Naturally,  when  exchanging   raw  binary
     files  (executables,  compressed archives, etc) IMAGE mode must be used.
     Type 'l' (logical byte size) is used when exchanging binary  files  with
     remote  servers   having   oddball   word sizes (e.g., DECSYSTEM-10s and
     20s). Locally it works exactly like IMAGE, except that it  notifies  the
     remote  system  how  large the  byte size is. <bytesize> is typically 8.









                                      - 69 -


     The type command sets the local transfer mode  and  generates  the  TYPE
     command on the control channel.

     7.3.18.  help

     Display a brief summary of top-level commands.

     7.3.19.  hostname [<name>]

     Displays or sets the local host's name (an ASCII string such  as  "ka9q-
     pc",  NOT  an  IP address).  Currently this is used only in the greeting
     messages from the SMTP (mail) and FTP (file transfer) servers.

     7.3.20.  log [stop|<file>]

     Without  arguments,  indicates  whether  server   sessions   are   being
     logged.   If "stop" is given as the argument, logging is terminated (the
     servers themselves are unaffected). If a file name is given as an  argu-
     ment,  server  session  log entries will be appended to it.

     7.3.21.  ip

     7.3.21.1.  ip address [<hostid>]

     Displays or sets the local IP address.

     7.3.21.2.  ip status

     Displays Internet  Protocol  (IP)  statistics,  such  as  total   packet
     counts   and error  counters of various types.  Also displays statistics
     about the Internet Control Message Protocol (ICMP), including the number
     of ICMP messages of each type sent or received.

     7.3.21.3.  ip ttl [<val>]

     Displays or sets the default time-to-live value placed  in  each  outgo-
     ing   IP  datagram.  This  limits the number of switch hops the datagram
     will be allowed to take. The idea is  to  bound  the  lifetime  of   the
     packet   should  it  become caught  in a routing loop, so make the value
     somewhat larger than the diameter of the network.

     7.3.22.  memstat

     Displays the internal free memory list in the storage allocator.

     7.3.23.  mode <interface> [vc|datagram]

     Controls the default transmission mode on the specified   AX.25   inter-
     face.   In  "datagram"   mode,  IP  packets are encapsulated in AX.25 UI
     frames and transmit- ted without any other link level  mechanisms,  such
     as  connections  or  ack- nowledgements.

     In "vc" (virtual circuit) mode, IP packets are encapsulated in  AX.25  I
     frames  and   are  acknowledged at the link level according to the AX.25









                                      - 70 -


     protocol.  Link level connections are opened  if  necessary.   With  the
     proper   setting   of   the  AX.25  T2  (acknowledgement  delay)  timer,
     AX.25 acknowledgements can be pig- gybacked on I frames  carrying  other
     IP datagrams (e.g., TCP level acknowledge- ments),  thereby  eliminating
     the  extra overhead ordinarily incurred by link level acknowledgments.

     In both modes, ARP is used to map IP to AX.25 addresses.   The  defaults
     can   be  overridden   with   the   type-of-service (TOS) bits in the IP
     header. Turning on the "reliability" bit causes I  frames  to  be  used,
     while  turning   on  the  "low delay"  bit  uses UI frames.  (The effect
     of turning on both bits is undefined and subject to change).

     In both modes, IP-level fragmentation is done if the datagram is  larger
     than the  interface  MTU.  In virtual circuit mode, however, the result-
     ing datagram (or fragments) is further fragmented at the AX.25 layer  if
     it   (or   they)  are still  larger  than  the  AX.25  "paclen"  parame-
     ter.  In AX.25 fragmentation, datagrams are broken into several I frames
     and  reassembled  at  the  receiving end before being passed to IP. This
     is preferable to IP fragmentation whenever possible because of decreased
     overhead (the IP header isn't repeated  in  each fragment) and increased
     robustness (a lost fragment is immediately retransmit- ted by  the  link
     layer).

     7.3.24.  mulport [on|off]

     The  multiport  switch software  allows routing of frames between inter-
     faces based on a table lookup. This provides the traditional "multi-port
     digipeater" functionality.

     There are two tables that  you  must build and place in the root  direc-
     tory.  They  are named  DIGILIST and EXLIST. DIGILIST contains the digis
     that  are directly  reachable from your switch. The  file  is  a  simple
     ASCII  text  file containing the callsign of the digi and the  interface
     name  of the port needed to reach it. The port name is  the   same  name
     you used in the attach statement for that port. Additionally there  is a
     special callsign "lan" that tells mulport which  port feeds your LAN  or
     default port.

     The file would look something like this:

     kd4nc-1 ax1      # kd4nc-1 is a neighbor switch on the high speed
                      # link attached to ax1 wb4gqx-1 ax3     # wb4gqx-1 is a
     neighbor  digi  on 145.01 (ax3) k4hal-1 ax2      # k4hal-1 is a neighbor
     digi on 440 (ax2) lan  ax0         # lan is a special name for  the  low
     speed  lan
                      # attached to the switch and is the default port
                      # used when mycall is the last call in the  digi
                      # string.

     The file EXLIST holds DESTINATION callsigns that do not obey  the rules.
     EXLIST  is only for stations who would normally be expected to be on the
     lan side  but are operating off some other port instead.  A  couple   of
     reasons   that  this may be the case are that the station may be  a PBBS
     operating on the trunk to serve more than one lan.









                                      - 71 -


     7.3.25.  param <interface> [param]

     Param invokes a device-specific  control  routine.   On   a   KISS   TNC
     interface,  this   sends   control  packets  to the TNC.  Data bytes are
     treated as decimal.  For example, "param ax0 1 255" will set  the  keyup
     timer  (type field  =  1)  on the  KISS  TNC  configured  as ax0 to 2.55
     seconds (255 x .01 sec).  On a SLIP interface, the param command  allows
     the  baud  rate to be  read  (without arguments) or set. The implementa-
     tion of this command for the various interface drivers is incomplete and
     subject to change.

     7.3.26.  pwd [<dirname>]

     An alias for the cd command.

     7.3.27.  record [<filename>|off]

     Opens <filename> and appends to it all data  received  on  the   current
     session.  Data sent on the current session is also written into the file
     except for Tel- net sessions in remote echo mode.  The  command  "record
     off"   stops   recording  and  closes the file. This command is not sup-
     ported for FTP sessions.

     7.3.28.  reset [<session>]

     If an argument is given, force a local reset  (deletion)  of  the  AX.25
     (AXCB) or TCP  Control  Block  (TCB) belonging to the specified session.
     The argument is first checked for validity.  If no  argument  is  given,
     the current session,  if any,  is  used.   This  command  should be used
     with caution since it does not inform the remote end that the connection
     no  longer  exists.   (In TCP  a  reset (RST)  message will be automati-
     cally generated should the remote TCP send  any-  thing  after  a  local
     reset  has  been  done.   In  AX.25  the DM message  performs  a similar
     role.   Both  are used to get rid of a  lingering  half-open  connection
     after a remote system has crashed.)

     7.3.29.  route

     route add <dest  hostid>[/bits]|default  <interface>  [<gateway  hostid>
             [<metric>]]

     route drop <dest hostid>

     With no arguments, "route" displays the IP routing  table.  "route  add"
     adds   an entry  to  the  routing  table,  while "route drop" deletes an
     existing entry.  "route add" requires at least two more  arguments,  the
     host id  of  the  target destination and the local name of the interface
     to which its packets should be sent.  If the destination is  not  local,
     the gateway's host id should  also  be specified.  (If  the interface is
     a point-to-point link, then <gateway hostid> may be omitted even if  the
     target  is  non-local  because this field is only used to  determine the
     gateway's link level address, if any.  If the  destination  is  directly
     reachable,  <gateway  hostid>  is also unnecessary since the destination
     address is used to determine the interface link address).









                                      - 72 -


     The optional "/bits" suffix to the destination  host  id  specifies  how
     many  leading  bits  in  the host id are to be considered significant in
     the routing comparisons.  If not specified, 32 bits (i.e., full signifi-
     cance)  is  assumed.  With  this  option,  a  single routing table entry
     may refer to many hosts all sharing a common bit string prefix in  their
     IP  addresses.  For  example,  ARPA Class  A, B and C networks would use
     suffixes of /8, /16 and /24 respectively; the command

             route add [44]/8 sl0 [44.64.0.2]

     causes any IP addresses beginning with "44" in the first 8 bits  to   be
     routed to [44.64.0.2]; the remaining 24 bits are "don't-cares".

     When an IP address to be routed matches more than one   entry   in   the
     routing  table,   the   entry  with  largest "bits" parameter (i.e., the
     "best" match) is used. This allows individual hosts or blocks  of  hosts
     to be  exceptions  to  a more general rule for a larger block of hosts.

     The  special  destination  "default"  is  used  to  route  datagrams  to
     addresses   not in  the  routing table; it is equivalent to specifying a
     /bits suffix of /0 to any destination hostid.  Care must be  taken  with
     default   entries   since   two nodes  with  default entries pointing at
     each other will route packets to unk- nown addresses back and forth in a
     loop  until  their  time-to-live (TTL)  fields expire.   (Routing  loops
     for specific addresses can also be created, but this is less  likely  to
     occur accidentally).

     "route drop" deletes an entry from the table.  If   a   packet   arrives
     for   the  deleted  address and a default route is in effect, it will be
     used.

     Here are some examples of using the route command:

             # Route datagrams to IP address 44.0.0.3 to SLIP line #0.
             # No gateway is needed because SLIP is point-to point.
             route add [44.0.0.3] sl0

             # Route all default traffic to the gateway on the local Ethernet
             # with IP address [44.0.0.1]
             route add default ec0 [44.0.0.1]

             # The local Ethernet has an ARPA Class-C address assignment;
             # route all IP addresses beginning with 192.4.8 to it
             route add [192.4.8]/24 ec0

             # Station with IP address [44.0.0.10] on local AX.25 channel
             route add [44.0.0.10] ax0

     7.3.30.  session [<session #>]

     Without arguments, displays the list of  current   sessions,   including
     session number,  remote  TCP or AX.25 address and the address of the TCP
     or AX.25 control block. An asterisk (*) is shown next to  the  "current"
     session;   entering  <cr>   at  this point will put you in converse mode









                                      - 73 -


     with that session.  Entering a session number as an argument to the ses-
     sion  command  will  put  you  in converse  mode  with  that session. If
     the telnet server is enabled, the user  is  notified  of   an   incoming
     request  and  a  session  number  is  automatically assigned.   The user
     may then select the session normally to converse with the remote user as
     though the session had been locally initiated.

     7.3.31.  shell

     Suspends "net" and executes a sub  shell  ("command   processor"   under
     MS-DOS).  When  the  sub  shell  exits, net resumes (under MS-DOS, enter
     the "exit" command). Note that background activity (FTP  servers,   etc)
     is  also  suspended while the subshell executes.

     7.3.32.  smtp

     7.3.32.1.  smtp gateway [<hostid>]

     Displays or sets the host to be used as a "smart" mail relay.  Any  mail
     sent  to  a   hostid  not  in the host table will instead be sent to the
     gateway for forwarding.

     7.3.32.2.  smtp kick

     Run through the outgoing mail queue and attempt to deliver any   pending
     mail.   This  command is periodically invoked by a timer whenever net is
     running; this command allows the user to "kick" the  mail  system  manu-
     ally.

     7.3.32.3.  smtp maxclients [<val>]

     Displays or sets the maximum number  of   simultaneous   outgoing   SMTP
     sessions  that  will be allowed. The default is 10; reduce it if network
     congestion is a problem.

     7.3.32.4.  smtp timer [<val>]

     Displays or sets the interval, in seconds, between scans of the outbound
     mail queue. For example, "smtp timer 600" will cause the system to check
     for outgoing mail every 10 minutes and attempt to  deliver  anything  it
     finds,  subject  of course to the "maxclients" limit. Setting a value of
     zero disables queue scanning altogether, note that this is the  default!
     This  value is recommended for stand  alone  IP gateways that never han-
     dle mail, since it saves wear and tear on the floppy disk drive.

     7.3.32.5.  smtp trace [<val>]

     Displays or sets the trace flag in the SMTP  client,  allowing  you   to
     watch  SMTP's   conversations   as it delivers mail.  Zero (the default)
     disables tracing.

     7.3.33.  start

     Starts  the  specified  Internet  server,  allowing  remote   connection









                                      - 74 -


     requests.

     7.3.34.  stop

     Stops the specified Internet server,  rejecting   any   further   remote
     connect requests. Existing connections are allow to complete normally.

     7.3.35.  tcp

     7.3.35.1.  tcp irtt [<val>]

     Display or set the intial round trip time estimate, in  seconds,  to  be
     used  for  new  TCP  connections until they can measure and adapt to the
     actual value.  The default is 5 seconds.  Increasing this when operating
     over  slow channels  will avoid the flurry of retransmissions that would
     otherwise occur as the smoothed estimate settles  down  at  the  correct
     value.  Note  that  this command  should  be given  before  servers  are
     started in order for it to have effect on incoming connections.

     7.3.35.2.  tcp kick <tcp_addr>

     If there is data on the send queue of the specified tcb,  this   command
     forces an immediate retransmission.

     7.3.35.3.  tcp mss [<size>]

     Display or set the TCP Maximum Segment Size in bytes that will  be  sent
     on   all outgoing  TCP  connect  request (SYN segments).  This tells the
     remote end the size of the largest segment (packet) it may send.  Chang-
     ing   MSS   affects   only  future connections; existing connections are
     unaffected.

     7.3.35.4.  tcp reset <tcb_addr>

     Deletes the TCP control block at the specified address.

     7.3.35.5.  tcp rtt <tcp_addr> <rtval>

     Replaces the automatically computed round trip time in the specified tcb
     with  the   rttval  in milliseconds.  This command is useful to speed up
     recovery from a series of lost packets since it provides a manual bypass
     around  the  normal backoff retransmission timing mechanisms.

     7.3.35.6.  tcp status [<tcb_addr>]

     Without arguments, displays several TCP-level statistics, plus  a   sum-
     mary   of  all   existing  TCP  connections, including TCB address, send
     and receive queue sizes, local and remote sockets, and connection state.
     If  <tcb_addr>  is specified, a  more detailed dump of the specified TCB
     is generated, including send and  receive  sequence  numbers  and  timer
     information.












                                      - 75 -


     7.3.35.7.  tcp window [<val>]

     Displays or sets the default receive window size in bytes  to  be   used
     by   TCP  when  creating new connections. Existing connections are unaf-
     fected.

     7.3.36.  telnet <hostid>

     Creates a Telnet session to the specified host and enters converse mode.

     7.3.37.  trace [<interface> [<flags>]|allmode|cmdmode]

     Controls packet tracing by the interface drivers. Specific  bits  enable
     tracing  of   the  various interfaces and the amount of information pro-
     duced.  Tracing is controlled on a per-interface  basis;  without  argu-
     ments, trace gives a list  of all  defined  interfaces and their tracing
     status.  Output can be limited to a single interface by  specifying  it,
     and  the  control   flags  can  be  change  by specifying  them as well.
     The flags are given as a hexadecimal number which is interpreted as fol-
     lows:

        TIO
        |||--- Enable tracing of output packets if 1, disable if 0
        ||---- Enable tracing of input packets if 1, disable if 0
        |----- Controls type of tracing:
           0 - Protocol headers are decoded, but data is not displayed
           1 - Protocol headers are decoded, and data (but not the
               headers themselves) are displayed as ASCII characters,
               64 characters/line. Unprintable characters are displayed
               as periods.
           2 - Protocol headers are decoded, and the entire packet
               (headers AND data) is also displayed in hexadecimal
               and ASCII, 16 characters per line.

     There is an additional option for tracing, that  allows  you  to  select
     whether  traced packets are always displayed, or only displayed when you
     are in command mode.  Having tracing only happen in command  mode  some-
     times  provides  the  right  mix  between "knowing what's going on", and
     "keeping the garbage off the screen"  while  you're  typing.  To  select
     tracing  all  the time (the default mode), use 'trace allmode'.  To res-
     trict tracing to command mode, use 'trace cmdmode'.

     7.3.38.  udp status

     Displays the status of all UDP receive queues.

     7.3.39.  upload [<filename>]

     Opens <filename> and sends it on the current session as though it   were
     typed on the terminal. Valid only on AX.25 and Telnet sessions.

     7.3.40.  ?

     Same as the "help" command.









                                      - 76 -


     8.  Appendices

     8.1.  Obtaining Current Bits

     The KA9Q Internet software package is still evolving and growing.  As  a
     result,  we  occasionally  issue  updates  to the software that fix bugs
     and/or update functionality. Announcements are always made to the USENET
     news  group  rec.ham-radio.packet.   They  usually  also show up on Com-
     puserve within a day or two. There is never any charge for the software.
     A  small  charge  may exist for copying floppies if you want the bits on
     disk, and of course you'll have to pay the long distance if you grab the
     bits over the phone!

     If several people are running the software in your  area,  get  together
     and  decide  on one person to get the new bits, then copy it around.  We
     won't mind.

     8.1.1.  Via FTP on the Internet

     The most recent official release is usually available from  the  machine
     WSMR-SIMTEL20.ARMY.MIL  on  the Internet. Use anonymous FTP, and look in
     the directory PD3:<MISC.KA9Q-TCPIP>.

     Beta-releases are often available on the machine LOUIE.UDEL.EDU, in  the
     directory  tree  rooted  at  pub/ka9q.  Anonymous FTP's are allowed, but
     unless you're working  on  the  software,  the  bits  on  louie  can  be
     "dangerous",  as  they  often include incompletely implemented features,
     and can have serious bugs.  Caveat Emptor.

     Various bits are also available  from  TOMCAT.GSFC.NASA.GOV,  a  machine
     operated by Tom Clark W3IWI.

     8.1.2.  On PC Floppies

     The Tucson Amateur Packet Radio association (TAPR) now  provides  floppy
     copies  of  the  software on 360k PC floppies, and can provide KISS ROMs
     for various TNC's, at a nominal charge  for  duplication  and  shipping.
     Contact TAPR for more information.

          TAPR PO Box 12925 Tucson, AZ  85732 [phone]

     8.1.2.1.  WB3FFV's Phone BBS in the USA

     Howard Leadmon, WB3FFV, has placed a BBS system on-line that  is  mainly
     oriented  towards  the  Amateur  Community (but there is other stuff on-
     line). Below is the information that is needed in order  to  access  the
     BBS via Telephone -or- TCP/IP.

      System Name: WB3FFV
      Login: bbs
      Number: (301)-335-0858 -- 1200 & 2400 (Non-MNP)
      Number: (301)-335-1955 -- 2400 (MNP), 9600 & 19200 (PEP)
      Data Settings: 8 Bits, NO Parity, 1 Stop Bit
      Times: 24hrs/365days  (except for routine maintenance)









                                      - 77 -


      Software: XBBS  (UNIX/Xenix Multiuser BBS)
      IP Address: 44.60.0.1 {wb3ffv.ampr.org}  [for FTP access on 145.550 mhz
     ONLY]
      Misc. Info: Machine  is  an  80386  computer  running  UNIX  V.3.2  and
     features 300+
                  meg of on-line storage. Most transfer protocols are  avail-
     able!!

     Howard attempts to keep the latest and greatest  HAM  software  on-line,
     and encourages all to upload anything new that they come up with.

     8.1.2.2.  PA0GRI's Phone BBS in Holland

     For those outside the USA, particularly in Europe, Gerard  provides  BBS
     service  and  anonymous UUCP access to the machine 'gvdgpc'. He supports
     Xmodem and Kermit on the BBS, at 1200/2400 baud, auto baud  rate  detect
     by  hitting a carriage return, using 8 bits, NO Parity, 1 Stop Bit.  The
     telephone number is 0031-70-119549.

     For uucp, use login 'nuucp', with no password (you won't be prompted for
     one).   Request the file ~/FILES to get started.  Gerard does a good job
     of staying up to date via a link to the wb3ffv machine.

     8.1.3.  Gary Sanders' Phone BBS in the USA

     Gary Sanders, N8EMR, runs a system called HBBS (Ham Bulletin board  sys-
     tem).   The  telephone number is  614-457-4227 (457-HBBS). The system is
     online 24hrs a day and will accept 1200/2400 and 19.2k baud PEP, 8  bits
     no parity, 1 stop bit.

     Gary's system will be used to support topics of interest  to  Ham  Radio
     Operators,  Short  Wave  Listeners,  scanner  listeners, and TVRO users.
     Currently there are message and file upload/dowload sections for general
     ham radio, packet radio, the KA9Q tcp software, SWL, and scanners.

     There is also readonly access to Unix USENET and  to  the  FIDO  network
     radio related newsgroups.

     Access to the BBS files are available via FTP  from  n8emr  [44.70.0.1].
     The  system  is available via 144.97 in Central Ohio, or via the 220 and
     446 packet network within Ohio.

     8.1.4.  Michael Broqvist in Sweden

     Michael operates a BBS for the Gothenburg Amateur Club called the HamNet
     Conference  System.   It  operates  at  +46/31-30  35 25, 300-2400 baud.
     Michael  can  be  reached  as  sysop  of  Fidonet  node  2:202/301,   as
     [e-mail] on the Internet, or via uucp as enea!hamnet.se!mibro.

     He also updates the packet mailbox SK6SA in Gothenburg Sweden  which  is
     reachable as 44.140.18.2.












                                      - 78 -


     8.2.  The KISS Specification

     8.3.  The KISS Host to TNC Protocol

     8.3.1.  The Protocol Specification

     8.3.1.1.  Introduction

     The purpose of the "Raw" (aka "KISS") TNC is to facilitate  the  use  of
     amateur  packet  radio  controllers  (TNCs)  with  host  computers, par-
     ticularly in the development of experimental  protocols  and  multi-user
     servers (e.g.,  "bulletin boards").

     Current TNC software was  written  with  human  users  in  mind;  unfor-
     tunately,  commands   and  responses  well suited for human use are ill-
     adapted for host computer use, and vice versa. This is  especially  true
     for  multi-user  servers  such  as  bulletin boards which must multiplex
     data from several network connections across the single  host/TNC  link.
     In  addition,  experimentation  with   new   link  level   protocols  is
     greatly hampered because there may very well be no way at  all  to  gen-
     erate or receive frames in the desired format without  reprogramming the
     TNC.

     The Raw TNC solves these problems by eliminating  as  much  as  possible
     from   the  TNC software, giving the attached host complete control over
     and access to the contents of the HDLC frames transmitted  and  received
     over  the air.  The  AX.25 protocol is removed entirely from the TNC, as
     are all command interpreters and the  like.   The  TNC  simply  converts
     between  synchronous  HDLC,  spoken  on  the half  duplex radio channel,
     and a special asynchronous, full  duplex  frame  format  spoken  on  the
     host/TNC  link.  Every  frame  received  on   the  HDLC  link  is passed
     intact to the host once it has been translated to the asynchronous  for-
     mat;  likewise, asynchronous frames from the host are transmitted on the
     radio channel once they have been converted to HDLC format.

     Of course, this means that the bulk of AX.25 (or another protocol)  must
     now  be  implemented   on  the host system. This is acceptable, however,
     considering the greatly increased flexibility and reduced  overall  com-
     plexity  that  comes  from allowing  the  protocol to reside on the same
     machine with the applications to which it is closely coupled.

     8.3.1.2.  Asynchtronous Frame Format

     The "asynchronous packet protocol" spoken between the host  and  TNC  is
     very  simple,   since its only function is delimiting frames. Each frame
     is both preceded and followed by a special FEND (frame  end)  character,
     analogous  to  an HDLC flag.  No CRC or checksum is provided.

     The reason for both preceding and ending frames with FENDs is to improve
     performance   when  there  is  noise on the asynch line. The FEND at the
     beginning of a frame serves to "flush out" any accumulated garbage  into
     a  separate  frame (which will be discarded by the upper layer protocol)
     instead of prepending it to an otherwise good frame.  As  with  back-to-
     back   FLAGs   in   HDLC,   two   FEND characters in a row should not be









                                      - 79 -


     interpreted as delimiting an empty frame.

     8.3.1.2.1.  Transparency

     Frames are sent in 8-bit binary; if an FEND ever appears in  the   data,
     it   is  translated   into   the   two   byte sequence FESC TFEND (frame
     escape, transposed frame end).  Likewise, if  the  FESC  character  ever
     appears  in  the  user  data,  it  is  replaced  with  the two character
     sequence FESC TFESC (frame escape, transposed frame escape).

     As characters arrive at the receiver, they are appended to a buffer con-
     taining  the  current  frame.  Receiving  a  FEND  marks  the end of the
     current frame.  Receipt of a  FESC  puts  the  receiver  into   "escaped
     mode",   which   causes   the receiver to translate a following TFESC or
     TFEND back to FESC or  FEND,  respectively,  before  adding  it  to  the
     receive  buffer  and  leaving  escaped  mode.  (Receipt  of  any charac-
     ter other than TFESC or TFEND while in escaped  mode  is  an  error;  no
     action  is  taken  and  frame  assembly  continues.   A  TFEND  or  TESC
     received while not in escaped mode is treated as an ordinary data  char-
     acter.)

     This procedure may seem somewhat complicated, but it is easy  to  imple-
     ment  and recovers  quickly from errors. In particular, the FEND charac-
     ter is never sent over the channel except  as  an  actual   end-of-frame
     indication.   This   ensures that  any  intact frame (properly delimited
     by FEND characters) will always be received properly regardless  of  the
     starting state of the receiver or corruption of the preceding frame.

     The special characters are:

             FEND    (frame end)                     300 (octal)
             FESC    (frame escape)                  333 (octal)
             TFEND   (transposed frame end)          334 (octal)
             TFESC   (transposed frame escape)       335 (octal)

     (ARPA Internet hackers will recognize this  protocol  as  identical   to
     SLIP,   a popular method for sending IP datagrams across ordinary dialup
     modems).

     8.3.1.3.  Control of the Raw TNC

     Each asynchronous data frame sent to the TNC is  converted   back   into
     "pure"  form   and  queued  for  transmission  as a separate HDLC frame.
     Although removing the human interface and the AX.25  protocol  from  the
     TNC   makes  most  existing TNC  commands unnecessary (i.e., they become
     host  functions),  the  TNC  is  still  responsible   for   keying   the
     transmitter's   PTT   line   and   deferring  to  other activity  on the
     radio channel. It is therefore necessary to allow the host to control  a
     few  TNC  parameters,  namely   the  transmitter  keyup  delay  and  the
     transmitter persistence variables.

     It is therefore necessary  to  distinguish  between  command  and   data
     frames   on the  host/TNC  link. This is done by defining the first byte
     of each asynchronous frame between host and TNC as a  "type"  indicator.









                                      - 80 -


     The  following  types are defined in frames to the TNC:

     Type    Function        Comments

     0       Data frame      Rest of frame is data destined for HDLC channel

     1       TXDELAY         Second byte is TX keyup delay in 10 ms units

     2       P               Second byte is persistence parameter, p:
                             0: p = (0+1)/256, 255: p = (255+1)/256 = 1.0]

     3       SLOTTIME        Second byte is slot interval in 10 ms units

     4       TXtail          Second byte is time to hold up the TX after
                             the FCS has been sent (time allowed to send the
                             HDLC flag character; should be at  least  2  for
                             1200 bps operation).  In 10 ms units.

     The following types are defined in frames to the host:

     Type    Function        Comments

     0       Data frame      Rest of frame is data from the HDLC channel

     (No other types are defined; in particular, there is  no  provision  for
     ack- nowledging data or command frames sent to the TNC.)

     8.3.1.4.  Persistence

     The P and SLOTTIME parameters are used to implement  true   p-persistent
     CSMA.  This works as follows:

     Whenever the host has queued data for transmission, the TNC begins  mon-
     itoring the  carrier detect signal from the modem. It waits indefinitely
     for this sig- nal to go inactive. Once the channel is clear,   the   TNC
     generates   a  random number  between  0 and 255. If this number is less
     than or equal to P, the TNC asserts the transmitter PTT line, waits  .01
     *  TXDELAY  seconds,   and  transmits all  frames  in its queue. The TNC
     then releases PTT and goes back to the idle state.  If the random number
     is  greater  than  P, the  TNC  delays  signal  has gone  active  in the
     meantime, the TNC again waits for it  to  clear  before  con-  tinuing).
     Note   that   P=255   means   always   transmit  as  soon  as  possible,
     regardless of the random number.

     The result is that the  TNC  waits  for   an   exponentially-distributed
     random  interval  after  sensing  that the channel has gone clear before
     attempting to transmit. The idea here is that with proper tuning of  the
     parameters  P  and SLOTTIME,  several  stations with traffic to send are
     much less likely to col- lide with each other when  they  simultaneously
     see the channel go clear.

     8.3.2.  The TNC-2 Implementation

     See the files included in the TNC-2 KISS Distribution.









                                      - 81 -


     8.3.3.  The TNC-1 Implementation

     See the files included in the TNC-1 KISS Distribution.

     8.3.4.  The VADCG/ASHBY Implementation

     See the files included in the VADCG/ASHBY KISS Distribution.

     8.3.5.  The AEA Implemenation

     All PK-232 units with WEFAX, and PC-87 units of a similar  vintage,  are
     capable of KISS operation.  See the installation instructions earlier in
     this document for more information.

     8.3.6.  The Kantronics Implemenation

     See your Kantronics TNC Documentation.


     8.5.  Information for Software Developers


                                      - 94 -

     8.6.  Technical Information for Client/Server Developers

     First things first.  The program has been tested out with  the  Turbo  C
     2.0  compiler under MS-Dos, the HP-UX 5.21 and 6.2 compilers, the Micro-
     port 286 compiler, and the Mark  Williams  compiler  on  the  Atari  ST.
     There  is  a  known  problem compiling under Aztec C 4.10d on the PC, if
     someone can figure out what is going  wrong  it  would  be  appreciated.
     With that out of the way...

     This section describes the "guts" of the Internet package for the  bene-
     fit   of  programmers   who   wish  to  write their own applications, or
     adapt the code to different hardware environments. Potential application
     developers should consider strongly writing new applications for the NOS
     version of the package, which is currently in development. Contact  Phil
     Karn  KA9Q or Bdale Garbee N3EUA for more information.  There will *not*
     be another release of the software based on the internal structure  used
     through this release.

     The code as distributed includes both the  functions  of  an  IP  packet
     switch  and an  end-host  system,  including several servers. The imple-
     mentation is highly modular, however. For example, if one wants to build
     a  dedicated packet switch without  any  local applications, the various
     applications and the TCP and UDP modules may easily be omitted  to  save
     space.

     The package allows multiple simultaneous applications,  each  supporting
     multi-  ple   simultaneous   users,  each using TCP and/or UDP. The only
     limit is memory space, which is getting quite tight on the  820;  the  C
     compiler  for  the  IBM   PC seems  to  generate  much more compact code
     (typically 1/2 as large as for the Z-80) so the PC seems more  promising
     as a large-scale server.

     8.6.1.  Data Structures

     To increase portability, the pseudo-types "int16" and "int32"  are  used
     to  mean  an   unsigned   16-bit  integer  and  a signed 32-bit integer,
     respectively.  Ordi- narily these types are defined in machdep.h  to  be
     "unsigned int" and "long".

     The various modules pass data  in  chained  structures   called   mbufs,
     with  the following format:

     struct mbuf {
         struct mbuf *next;      /* Link mbufs belonging to single packets */
         struct mbuf *anext;     /* Link packets on queues */
         char *data;             /* Ptr to start of actual data in buffer */
         int16 cnt;              /* Length of data in buffer */ };

     Although somewhat cumbersome to work with, mbufs make  it  possible   to
     avoid  memory-to-memory copies that limit performance. For example, when
     user data is transmitted it must first traverse several protocol  layers
     before  reaching  the  transmitter hardware. With mbufs, each layer adds
     its protocol header by allo- cating an mbuf and linking it to  the  head
     of the mbuf "chain" given it by  the higher layer, thus avoiding several









                                      - 95 -


     copy operations.

     A number of primitives operating on mbufs are available in mbuf.c.   The
     user  may   create,   fill,   empty  and  free  mbufs  himself  with the
     alloc_mbuf and free_mbuf primitives, or at the cost of a single  memory-
     to-memory  copy  he  he may use the more convenient qdata() and dqdata()
     primitives.

     8.6.2.  Timer Services

     TCP and IP require timers. A timer package  is  included,  so  the  user
     must  arrange  to call the single entry point "tick" on a regular basis.
     The constant MSPTICK in  timer.h  should  be  defined  as  the  interval
     between   ticks   in  milliseconds.  One  second resolution is adequate.
     Since it can  trigger  a  considerable  amount  of  activity,  including
     upcalls  to user level, "tick" should not be called  from  an  interrupt
     handler. A clock interrupt should set  a  flag  which  will  then  cause
     "tick" to be called at user level.

     8.6.3.  Internet Type-of-Service

     One of the features of the Internet  is  the  ability  to  specify  pre-
     cedence  (i.e.,  priority)  on  a per-datagram basis. There are 8 levels
     of precedence, with the bottom 6 defined by the DoD as  Routine,  Prior-
     ity,  Immediate,  Flash, Flash  Override  and  CRITICAL.  (Two  more are
     available for internal network functions). For amateur use  we  can  use
     the  lower  four  as  Routine,  Welfare, Priority  and  Emergency. Three
     more bits specify class of  service,  indicating  that  especially  high
     reliability,  high  throughput or low delay is  needed  for this connec-
     tion. Constants for this field are defined in internet.h.

     8.6.4.  The Internet Protocol Implementation.

     While the user does not ordinarily see  this  level  directly,   it   is
     described here  for sake of completeness. Readers interested only in the
     interfaces seen by the applications programmer should skip  to  the  TCP
     and UDP sections.

     The IP implementation  consists  of  three  major  functions:  ip_route,
     ip_send and ip_recv.

     8.6.5.  IP Gateway (Packet Router) Support

     The first, ip_route, is the IP packet switch. It takes a  single   argu-
     ment,  a pointer to the mbuf containing the IP datagram:

             void
             ip_route(bp,rxbroadcast)
             struct mbuf *bp;        /* Datagram pointer */
             int rxbroadcast;        /* Don't forward */

     All IP datagrams, coming or going, pass through this   function.   After
     option  processing,   if   any,   the  datagram's destination address is
     extracted. If it corresponds to the local host, it is "kicked  upstairs"









                                      - 96 -


     to  the upper half of IP and  thence to the appropriate protocol module.
     Otherwise, an internal routing table consulted to  determine  where  the
     datagram   should   be   forwarded.    The routing  table  uses  hashing
     keyed on IP destination addresses, called "tar-  gets".  If  the  target
     address is not  found,  a  special  "default"  entry,  if available,  is
     used. If a default entry is not available either, an ICMP "Des- tination
     Unreachable" message containing the offending IP header  is  returned to
     the sender.

     The "rxbroadcast" flag is used to prevent forwarding of broadcast  pack-
     ets,   a  practice  which  might otherwise result in spectacular routing
     loops. Any subnet interface driver receiving a packet addressed  to  the
     broadcast address  within that  subnet  MUST  set  this flag.  All other
     packets (including locally ori- ginated packets) should  have  "rxbroad-
     cast" set to zero.

     ip_route ignores the IP destination address in broadcast packets,  pass-
     ing them up  to the appropriate higher level protocol which is also made
     aware of their broadcast nature. (TCP and ICMP ignore them; only UDP can
     accept them).

     Entries are added to the IP routing table with the rt_add function:

     int      rt_add(target,gateway,metric,interface)      int32      target;
     /* IP address of target */ int32 gateway;                  /* IP addr of
     gateway to reach  this  target  */  int  metric;                      /*
     "cost"  metric,  for  routing  decisions */ struct interface *interface;
     /* device interface structure */

     "target" is the IP address of  the  destination;  it  becomes  the  hash
     index   key for subsequent packet destination address lookups. If target
     == 0, the default entry is modified. "metric" is simply  stored  in  the
     table;  it  is  available  for  routing   cost   calculations   when  an
     automatic  routing protocol is written.  "interface" is the address of a
     control  structure  for  the  particular  device to which  the  datagram
     should  be sent; it is defined in the section "IP Inter- faces".

     rt_add returns 0 on success, -1 on failure (e.g., out of memory).

     To remove an entry from the routing table,  only  the   target   address
     need  be specified to the rt_drop call:

             int
             rt_drop(target)
             int32 target;

     rt_drop returns 0 on success, -1 if the target could not be found.

     8.6.6.  IP Interfaces

     Every lower level interface used to transmit IP datagrams must  have  an
     "inter- face" structure, defined as follows:

     /* Interface control structure */









                                      - 97 -


      struct interface {
             struct interface *next; /* Linked list pointer */
             char *name;             /* Ascii string with interface name */
             int16 mtu;              /* Maximum transmission unit size */
             int (*send)();          /* Routine to call to send datagram */
             int (*output)();        /* Routine to call to send raw packet */
             int (*recv)();          /* Routine to kick to process input */
             int (*stop)();          /* Routine to call before detaching */
             int16 dev;              /* Subdevice number to pass to send */
             int16 flags;            /* State of interface */
      #define IF_ACTIVE       0x01
      #define IF_BROADCAST    0x04    /* Interface is capable of broadcasting
     */ };

     Part of the interface structure is for the private use  of  the   device
     driver.  "dev"  is  used to distinguish between one of several identical
     devices (e.g., serial links or radio channels) that might share the same
     send routine.

     A pointer to this structure kept in the  routing   table.   Two   fields
     in   the  interface   structure   are   examined  by ip_route: "mtu" and
     "send". The  maximum  transmission  unit  size  represents  the  largest
     datagram that  this  device  can handle; ip_route will do IP-level frag-
     mentation as required to meet this  limit  before  calling  "send",  the
     function to  queue  datagrams  on  this  interface.  "send" is called as
     follows:

      (*send)(bp,interface,gateway,precedence,delay,throughput,reliability)
      struct mbuf *bp;                /* Pointer to datagram */
      struct interface *interface;    /* Interface structure */
      int32 gateway;                  /* IP address of gateway */
      char precedence;                /* TOS bits from IP header */
      char delay;
      char throughput;
      char reliability;

     The "interface" and "gateway"  arguments  are  kept   in   the   routing
     table   and  passed  on  each  call  to  the send routine. The interface
     pointer is passed again because several interfaces might share the  same
     output driver  (e.g.,  several identical  physical channels).  "gateway"
     is the IP address of the neighboring IP gateway on the other end of  the
     link;  if  a  link-level  address is  required, the  send  routine  must
     map  this address either dynamically (e.g., with the Address  Resolution
     Protocol,  ARP)  or with a static lookup table.  If the  link is  point-
     to-point, link-level addresses are unnecessary, and the send routine can
     therefore ignore the gateway address.

     The Internet Type-of-Service (TOS) bits  are  passed  to  the  interface
     driver   as  separate  arguments.  If  tradeoffs exist within the subnet
     between these various classes of service, the driver may use these argu-
     ments  to  control  them   (e.g., optional use of link level acknowledg-
     ments, priority queuing, etc.)

     It is expected that the send routine will put a link level header on the









                                      - 98 -


     front of  the  packet, add it an internal output queue, start output (if
     not already active) and return. It must  NOT  busy-wait  for  completion
     (unless it is a  very fast device, e.g., Ethernet) since that blocks the
     entire system.

     Any interface that uses ARP must also provide an "output"  routine.   It
     is   a  lower  level  entry  point that allows the caller to specify the
     fields in the link header. ARP uses it to  broadcast  a  request  for  a
     given  IP  address. It may be  the  same  routine used internally by the
     driver to send IP datagrams once the link level fields have been  deter-
     mined. It is called as follows:

      (*output)(interface,dest,src,type,bp)
      struct interface *interface;    /* Pointer to interface structure */
      char dest[];                    /* Link level destination address */
      char src[];                     /* Link level source address */
      int16 type;                     /* Protocol type field for  link  level
     */
      struct mbuf *bp;                /* Data field (IP datagram) */

     8.6.7.  IP Host Support

     All of the modules described thus far are  required  in   all   systems.
     However,  the  routines  that  follow  are  necessary  only  if the sys-
     tem is to support higher-level applications. In a standalone IP  gateway
     (packet  switch)  without servers  or clients, the following modules (IP
     user level, TCP and UDP) may be omitted to allow  additional  space  for
     buffering;  define  the  flag  GWONLY  when compiling iproute.c to avoid
     referencing the user level half of IP.

     The following function  is  called  by  iproute()  whenever  a  datagram
     arrives that is addressed to the local system.

      void
      ip_recv(bp,rxbroadcast)
      struct mbuf *bp;                /* Datagram */
      char rxbroadcast;               /* Incoming broadcast */

     ip_recv reassembles IP datagram fragments, if necessary, and calls   the
     input  function   of   the   next   layer   protocol  (e.g.,  tcp_input,
     udp_input) with the appropriate arguments, as follows:

      (*protrecv)(bp,protocol,source,dest,tos,length,rxbroadcast);
      struct mbuf *bp;        /* Pointer to packet minus IP header */
      char protocol;          /* IP protocol ID */
      int32 source;           /* IP address of sender */
      int32 dest;             /* IP address of destination (i.e,. us) */
      char tos;               /* IP type-of-service field in datagram */
      int16 length;           /* Length of datagram minus IP header */
      char rxbroadcast;       /* Incoming broadcast */

     The list of protocols is contained in a  switch()   statement   in   the
     ip_recv  function.  If  the  protocol  is  unsupported, an ICMP Protocol
     Unreachable message is returned to the sender unless the packet came  in









                                      - 99 -


     as  a  broadcast.   Higher  level  protocols such as TCP and UDP use the
     ip_send routine to generate  IP  datagrams.  The  arguments  to  ip_send
     correspond  directly  to fields in the IP header, which is generated and
     put in front of the user's  data  before  being handed to ip_route:

      ip_send(source,dest,protocol,tos,ttl,bp,length,id,df)
      int32 source;           /* source address */
      int32 dest;             /* Destination address */
      char protocol;          /* Protocol */
      char tos;               /* Type of service */
      char ttl;               /* Time-to-live */
      struct mbuf *bp;        /* Data portion of datagram */
      int16 length;           /* Optional length of data portion */
      int16 id;               /* Optional identification */
      char df;                /* Don't-fragment flag */

     This interface is modeled very closely after the example given  on  page
     32  of RFC-791.  Zeros  may be passed for id or ttl, and system defaults
     will be pro- vided. If zero is passed for length, it will be  calculated
     automatically.

     8.6.8.  The Transmission Control Protocol (TCP)

     A TCP connection is  uniquely  identified  by   the   concatenation   of
     local   and remote  "sockets".  In  turn,  a  socket  consists of a host
     address (a 32-bit integer) and a TCP port (a 16-bit integer), defined by
     the C structure

      struct socket {
             long address;   /* 32-bit IP address */
             short port;     /*16-bit TCP port */
      };

     It is therefore possible to have several simultaneous but distinct  con-
     nections  to   the  same  port on a given machine, as long as the remote
     sockets are dis- tinct. Port numbers are assigned either through  mutual
     agreement,  or more com- monly  when  a  "standard" service is involved,
     as a "well known port"  number.   For  example,   to   obtain   standard
     remote  login  service  using  the  TELNET presentation-layer  protocol,
     by  convention you initiate a connection to TCP port 23;  to  send  mail
     using  the Simple Mail Transfer Protocol (SMTP) you  con- nect  to  port
     25. ARPA maintains port number lists and  periodically  publishes  them;
     the latest revision is RFC-960,  "Assigned  Numbers".   They  will  also
     assign  port  numbers  to  a new application on request if it appears to
     be of general interest.

     TCP connections are best modeled as a pair  of  one-way  paths  (one  in
     each  direction)  rather  than  single  full-duplex paths. A TCP "close"
     really means "I have no more data to send". Station A may close its path
     to  station  B   leaving the  reverse  path  from  B  to A unaffected; B
     may continue to send data to A indefinitely until it too closes its half
     of the  connection.   Even  after  a user initiates a close, TCP contin-
     ues to retransmit any unacknowledged data if necessary to ensure that it
     reaches  the  other  end. This is known as  "graceful close" and greatly









                                     - 100 -


     simplifies certain applications such as FTP.

     This package is written as a "module" intended to be compiled and linked
     with  the  application(s)  so that they can be run as one program on the
     same machine.  This greatly simplifies  the  user/TCP  interface,  which
     becomes  just   a   set   of  internal   subroutine   calls  on a single
     machine. The internal TCP state (e.g.,  the  address   of   the   remote
     station)   is   easily  accessed.  Reliability  is improved,  since  any
     hardware  failure  that  kills TCP will  likely  take  its  applications
     with  it  anyway.  Only  IP  datagrams  flow  out of the machine  across
     hardware  interfaces  (such  as asynch RS-232 ports or whatever else  is
     avail-  able)  so  hardware flow control or  complicated  host/front-end
     protocols  are unnecessary.

     The TCP supports five basic  operations  on  a   connection:   open_tcp,
     send_tcp,  receive_tcp,  close_tcp  and  del_tcp. A sixth, state_tcp, is
     provided mainly for debugging. Since this TCP module cannot  assume  the
     presence  of a  sleep/wakeup facility from the underlying operating sys-
     tem, functions that would ordinarily block (e.g., recv_tcp when no  data
     is  available)  instead  set  net_error to  the constant  EWOULDBLK  and
     immediately return -1.  Asynchronous notification of events such as data
     arrival   can   be   obtained   through  the  upcall  facility described
     earlier.

     Each TCP function is summarized in the following section  in  the   form
     of  C declarations and descriptions of each argument.

     int net_error;

     This global variable stores the specific cause of an error from  one  of
     the  TCP  or  UDP functions. All functions returning integers (i.e., all
     except open_tcp) return -1 in the  event  of  an  error,  and  net_error
     should  be  examined  to determine  the  cause. The  possible errors are
     defined as constants in the header file netuser.h.

      /* Open a TCP connection */
      struct tcb *
      open_tcp(lsocket,fsocket,mode,window,r_upcall,t_upcall,s_upcall,tos,user)
      struct socket *lsocket; /* Local socket */
      struct socket *fsocket; /* Remote socket */
      int mode;               /* Active/passive/server */
      int16 window;           /* Receive window (and send buffer) sizes */
      void (*r_upcall)();     /* Function to call when data arrives */
      void (*t_upcall)();     /* Function to call when ok to send  more  data
     */
      void (*s_upcall)();     /*  Function  to  call  when  connection  state
     changes */
      char tos;               /* Internet Type-of-Service */
      int *user;              /* Pointer for convenience of user */

     "lsocket" and "fsocket" are pointers to the local and  foreign  sockets,
     respec- tively.

     "mode" may take on three  values,  all   defined   in   net.user.h.   If









                                     - 101 -


     mode   is  TCP_PASSIVE,  no packets are sent, but a TCP control block is
     created that will accept a subsequent active open from another TCP. If a
     specific  foreign  socket is  passed  to  a  passive  open, then connect
     requests from any other foreign socket will be rejected. If the  foreign
     socket  fields  are  set  to  zero,  or  if fsocket  is  NULLSOCK,  then
     connect requests from any foreign socket will be accepted.  If  mode  is
     TCP_ACTIVE,  TCP  will  initiate a connection to  a  remote socket  that
     must already have been created in the LISTEN state by its  client.   The
     foreign  socket  must  be  completely specified in an active open.  When
     mode is TCP_SERVER, open_tcp behaves as  though  TCP_PASSIVE  was  given
     except  that  an internal "clone" flag is set. When a connection request
     comes in, a fresh copy of  the  TCP  control  block  is created and  the
     original  is  left intact. This allows multiple sessions to exist simul-
     taneously;  if  TCP_PASSIVE  were  used instead only the  first  connect
     request would be accepted.

     "r_upcall", "t_upcall" and  "s_upcall"  provide   optional   upcall   or
     pseudo-  interrupt   mechanisms  useful  when running in a non operating
     system environ- ment.  Each of the  three  arguments,  if  non-NULL,  is
     taken  as  the address of  a user-supplied function to call when receive
     data arrives, transmit queue space becomes available, or the  connection
     state  changes.  The   three   functions   are called with the following
     arguments:

      (*r_upcall)(tcb,count); /* count == number of bytes in receive queue */
      (*t_upcall)(tcb,avail); /* avail == space available in send queue */
      (*s_upcall)(tcb,oldstate,newstate);

     Note: whenever a single event invokes more than one upcall the order  in
     which  the upcalls are made is not strictly defined. In general, though,
     the Principle of Least Astonishment is followed.   E.g.,  when  entering
     the   ESTABLISHED  state, the state change upcall is invoked first, fol-
     lowed by the transmit upcall.   When   an   incoming   segment  contains
     both   data   and  FIN, the receive upcall is invoked first, followed by
     the state change to CLOSE_WAIT state.  In this case, the user may inter-
     pret this state change as a "end of file" indicator.

     "tos" is the Internet type-of-service field. This  parameter  is  passed
     along  to  IP   and is included in every datagram. The actual precedence
     value used is the higher of the two specified in the corresponding  pair
     of open_tcp calls.

     open_tcp returns a pointer to an internal Transmission   Control   Block
     (tcb).  This "magic cookie" must be passed back as the first argument to
     all other TCP calls. In event of error, the NULL pointer (0) is returned
     and  net_error  is set to the reason for the error.

     The only limit on the number of  TCBs  that  may  exist  at   any   time
     (i.e.,   the number  of  simultaneous  connections)  is  the  amount  of
     free memory on the machine. Each TCB on  a  16-bit  processor  currently
     takes  up   111   bytes;   addi-  tional   memory  is consumed and freed
     dynamically as needed to buffer send and receive data.  Deleting  a  TCB
     (see the del_tcp() call) reclaims its space.










                                     - 102 -


      /* Send data on a TCP connection */
      int
      send_tcp(tcb,bp)
      struct tcb *tcb;        /* TCB pointer */
      struct mbuf *bp;        /* Pointer to user's data mbufs */

     "tcb" is the pointer returned by the  open_tcp()   call.   "bp"   points
     to   the  user's   mbuf   with   data  to be sent. After being passed to
     send_tcp, the user must no longer access the data buffer. TCP uses posi-
     tive acknowledgments  with retransmission  to  ensure in-order delivery,
     but this is largely invisible to the user. Once the remote TCP has  ack-
     nowledged the data, the  buffer  will  be freed automatically.

     TCP does not enforce a limit in  the  number  of  bytes  that   may   be
     queued  for transmission,  but  it  is  recommended that the application
     not send any more than the amount passed as  "cnt"  in  the  transmitter
     upcall.   The  package  uses shared,  dynamically allocated buffers, and
     it is entirely possible for a mis- behaving user task to run the  system
     out of buffers.

      /* Receive data on a TCP connection */
      int
      recv_tcp(tcb,bp,cnt)
      struct tcb *tcb;
      struct mbuf **bp;
      int16 cnt;

     recv_tcp() passes back through bp a pointer to an mbuf  chain   contain-
     ing   any  available  receive  data, up to a maximum of "cnt" bytes. The
     actual number of bytes received (the lesser of  "cnt"  and  the   number
     pending   on   the  receive queue) is returned. If no data is available,
     net_error is set to EWOULDBLK and -1 is returned; the r_upcall mechanism
     may  be   used   to   determine   when  data arrives.  (Technical  note:
     "r_upcall" is called whenever a PUSH or FIN bit is seen in  an  incoming
     segment,  or  if  the receive  window  fills.  It  is  called before  an
     ACK  is  sent back to the remote TCP, in  order  to  give  the  user  an
     opportunity to piggyback any data in response.)

     When the remote TCP closes its half of the  connection  and  all   prior
     incoming  data   has   been  read by the local user, subsequent calls to
     recv_tcp return 0 rather than -1 as an "end of transmission"  indicator.
     Note   that   the   local application  is  notified  of  a  remote close
     (i.e., end-of-file) by a state- change upcall with the new  state  being
     CLOSE_WAIT;  if   the  local  application has  closed  first,  a  remote
     close is indicated  by  a  state-change  upcall  to  either  CLOSING  or
     TIME_WAIT  state. (CLOSING state is used only  when  the  two ends close
     simultaneously and their FINs cross in the mail).

      /* Close a TCP connection */
      close_tcp(tcb)
      struct tcb *tcb;

     This tells TCP that the local user has no more  data   to   send.   How-
     ever,   the  remote  TCP  may  continue to send data indefinitely to the









                                     - 103 -


     local user, until the remote user also does a close_tcp.  An attempt  to
     send data after a  close_tcp is an error.

      /* Delete a TCP connection */
      del_tcp(tcb)
      struct tcb *tcb;

     When the connection has been closed in both connections and all incoming
     data  has been read, this call is made to cause TCP to reclaim the space
     taken up by the TCP control block. Any incoming data remaining unread is
     lost.

      /* Dump a TCP connection state */
      state_tcp(tcb)
      struct tcb *tcb;

     This debugging call prints an ASCII-format dump of  the  TCP  connection
     state  on the  terminal.  You need a copy of the TCP specification (ARPA
     RFC 793 or MIL- STD-1778) to interpret most of the numbers.

     8.6.9.  The User Datagram Protocol (UDP)

     UDP is available for simple applications not needing the services of   a
     reli-  able  protocol  like TCP.  A minimum of overhead is placed on top
     of the "raw" IP datagram service, consisting only of port numbers and  a
     checksum   covering  the  UDP  header  and user data. Four functions are
     available to the UDP user.

      /* Create a UDP control block for lsocket, so that we can queue
       * incoming datagrams.
       */
      int
      open_udp(lsocket,r_upcall)
      struct socket *lsocket;
      void (*r_upcall)();

     open_udp creates a queue to accept incoming  datagrams  (regardless   of
     source)  addressed   to  "lsocket".  "r_upcall"  is  an  optional upcall
     mechanism to provide the address of a function to be called  as  follows
     whenever a datagram arrives:

      (*r_upcall)(lsocket,rcvcnt);
      struct socket *lsocket;         /* Pointer to local socket */
      int rcvcnt;                     /* Count of datagrams pending on  queue
     */

      /* Send a UDP datagram */
      int
      send_udp(lsocket,fsocket,tos,ttl,bp,length,id,df)
      struct socket *lsocket;         /* Source socket */
      struct socket *fsocket;         /* Destination socket */
      char tos;                       /* Type-of-service for IP */
      char ttl;                       /* Time-to-live for IP */
      struct mbuf *bp;                /* Data field, if any */









                                     - 104 -


      int16 length;                   /* Length of data field */
      int16 id;                       /* Optional ID field for IP */
      char df;                        /* Don't Fragment flag for IP */

     The parameters passed to send_udp  are  simply  stuffed   in   the   UDP
     and  IP headers, and the datagram is sent on its way.

      /* Accept a waiting datagram, if available. Returns length of  datagram
     */
      int
      recv_udp(lsocket,fsocket,bp)
      struct socket *lsocket;         /* Local socket to receive on */
      struct socket *fsocket;         /* Place to stash incoming socket */
      struct mbuf **bp;               /* Place to stash data packet */

     The "lsocket" pointer indicates  the   socket   the   user   wishes   to
     receive   a datagram  on (a queue must have been created previously with
     the open_udp rou- tine). "fsocket" is taken as the address of  a  socket
     structure  to  be  overwrit-  ten  with  the  foreign  socket associated
     with the datagram being read; bp is overwritten with a  pointer  to  the
     data portion (if any) of the datagram  being received.

      /* Delete a UDP control block */
      int
      del_udp(lsocket)
      struct socket *lsocket;

     This function destroys any unread datagrams on a queue, and reclaims the
     space taken by the queue descriptor.





































                                     CONTENTS



     Section Title                                                       Page

     1.  Introduction to TCP/IP and the KA9Q Software                      3
     1.1.  An Overview of the TCP/IP Protocol Family                       3
     1.1.1.  Acknowledgement                                               3
     1.1.2.  Introduction                                                  3
     1.1.3.  What is TCP/IP?                                               3
     1.1.4.  General description of the TCP/IP protocols                   8
     1.1.5.  The IP level                                                 12
     1.1.6.  The Ethernet level                                           13
     1.1.7.  Well-known sockets and the applications layer                15
     1.1.8.  An example application: SMTP                                 17
     1.2.  Protocols other than TCP: UDP and ICMP                         20
     1.3.  Keeping track of names and information: the domain system      21
     1.4.  Routing                                                        22
     1.5.  Details about Internet addresses: subnets and broadcasting     24
     1.6.  Datagram fragmentation and reassembly                          26
     1.7.  Ethernet encapsulation: ARP                                    26
     1.8.  Getting more information                                       27
     1.9.  Overview of the KA9Q Internet Package                          29

     2.  Installation                                                     31
     2.1.  What an IP Address Is, and How to Get One                      31
     2.2.  Configuring a TNC for TCP/IP Operation                         31
     2.2.1.  TAPR TNC-1 and Clones                                        31
     2.2.2.  TAPR TNC-2 and Clones                                        32
     2.2.3.  AEA PK-232                                                   32
     2.2.4.  Kantronics TNC's                                             33
     2.2.5.  Paccomm PC-100 Card                                          34
     2.2.6.  DRSI                                                         34
     2.3.  IBM PC and Clones                                              34
     2.3.1.  Installing the Plug'N'Play Disk                              34
     2.3.1.1.  The AUTOEXEC.NET File                                      34
     2.3.1.2.  The FTPUSERS File                                          35
     2.3.1.3.  The HOSTS.NET File                                         36
     2.3.2.  Installing on a Hard Disk                                    37
     2.4.  Unix                                                           37
     2.5.  Macintosh                                                      38
     2.6.  Atari ST                                                       38
     2.7.  NEC PC-9801                                                    38
     2.8.  Hewlett-Packard Portable Plus                                  38

     3.  Taking NET for a Test Drive                                      39
     3.1.  Trying out the AX.25 Support                                   39
     3.2.  The Telnet Command                                             39
     3.3.  The FTP Command                                                40
     3.4.  The Mail System                                                40
     3.5.  Tracing and Status Commands                                    40

     4.  The Mail System                                                  42
     4.1.  Installing and Using BM                                        42
     4.1.1.  Installation                                                 42
     4.1.1.1.  Directory Structure                                        42
     4.1.1.2.  Configuration File                                         42
     4.1.1.2.1.  smtp <path>                                              43
     4.1.1.2.2.  host <your hostname>                                     43
     4.1.1.2.3.  user <username>                                          43
     4.1.1.2.4.  edit <path of your editor>                               43
     4.1.1.2.5.  fullname <your full name>                                43
     4.1.1.2.6.  reply <return address>                                   43
     4.1.1.2.7.  maxlet <number of messages>                              43
     4.1.1.2.8.  mbox <filename>                                          43
     4.1.1.2.9.  record <filename>                                        44
     4.1.1.2.10.  folder <directory name>                                 44
     4.1.1.2.11.  screen [bios|direct]                                    44
     4.1.1.2.12.  Example BM.RC File                                      44
     4.1.1.3.  The alias File                                             44
     4.1.1.4.  /spool/mqueue/sequence.seq                                 45
     4.1.2.  Environment                                                  45
     4.2.  Commands                                                       45
     4.2.1.  Main Menu Commands                                           45
     4.2.1.1.  m [userlist]                                               45
     4.2.1.2.  d [msglist]                                                45
     4.2.1.3.  h                                                          45
     4.2.1.4.  u [msglist]                                                46
     4.2.1.5.  n [mailbox]                                                46
     4.2.1.6.  ! cmd                                                      46
     4.2.1.7.  ?                                                          46
     4.2.1.8.  s [msglist] [file]                                         46
     4.2.1.9.  p [msglist]                                                46
     4.2.1.10.  w [msglist] file                                          46
     4.2.1.11.  f [msg]                                                   46
     4.2.1.12.  b [msg]                                                   46
     4.2.1.13.  r [msg]                                                   47
     4.2.1.14.  msg#                                                      47
     4.2.1.15.  l                                                         47
     4.2.1.16.  k [msglist]                                               47
     4.2.1.17.  $                                                         47
     4.2.1.18.  x                                                         47
     4.2.1.19.  q                                                         47
     4.2.2.  Text Input Commands                                          47
     4.2.3.  Command Line Options                                         48
     4.3.  Technical Information                                          48
     4.3.1.  Outbound Mail Queue File Formats                             48
     4.3.2.  Standards Documents                                          48
     4.4.  Bug Reports                                                    49

     5.  NET/ROM Support                                                  50
     5.1.  Introduction                                                   50
     5.2.  Setting up the NET/ROM Interface                               50
     5.3.  Tracing on the NET/ROM Interface                               50
     5.4.  Routing Broadcasts                                             50
     5.5.  The NET/ROM Routing Table                                      51
     5.6.  The Importance of the Routing Table                            52
     5.7.  Interfacing with NET/ROMs Using Your Serial Port               53
     5.8.  The Time to Live Initializer                                   53
     5.9.  Using NET/ROM Support for IP                                   53
     5.10.  The NET/ROM Transport Layer                                   54
     5.11.  Connecting via NET/ROM Transport                              55
     5.12.  Displaying the Status of NET/ROM Connections                  55
     5.13.  NET/ROM Transport Parameters                                  55
     5.14.  The Mailbox                                                   56
     5.15.  Where to go for More Information                              56
     5.16.  About the Code                                                56

     6.  Advanced Topics                                                  58
     6.1.  The Finger Server                                              58
     6.2.  The GRAPES Multi-Port Digipeating Code                         58
     6.3.  Multiple Serial Ports on One Interrupt                         59

     7.  NET Command Reference                                            60
     7.1.  Startup                                                        60
     7.2.  Console Mode                                                   60
     7.3.  Commands                                                       60
     7.3.1.  <cr>                                                         61
     7.3.2.  !                                                            61
     7.3.3.  #                                                            61
     7.3.4.  arp                                                          61
     7.3.4.1.  arp add <hostid> ether|ax25|netrom <ether addr|callsign>   61
     7.3.4.2.  arp drop <hostid> ether|ax25|netrom                        61
     7.3.4.3.  arp publish                                                61
     7.3.5.  attach                                                       61
     7.3.5.1.  HP Portable Specifics                                      63
     7.3.5.2.  SLIP Modem Dialing                                         63
     7.3.6.  ax25                                                         64
     7.3.6.1.  ax25 digipeat [on|off]                                     64
     7.3.6.2.  ax25 heard [on|off]                                        64
     7.3.6.3.  ax25 maxframe [<val]>]                                     64
     7.3.6.4.  ax25 mycall [<call>]                                       64
     7.3.6.5.  ax25 bbscall [<call>]                                      64
     7.3.6.6.  ax25 paclen [<val>]                                        64
     7.3.6.7.  ax25 pthresh [<val>]                                       65
     7.3.6.8.  ax25 reset <axcb>                                          65
     7.3.6.9.  ax25 retry [<val>]                                         65
     7.3.6.10.  ax25 status [<axcb>]                                      65
     7.3.6.11.  ax25 t1|t2|t3 [<val>]                                     65
     7.3.6.12.  ax25 window [<val>]                                       65
     7.3.7.  close [<session #>]                                          65
     7.3.8.  connect <interface> <callsign> [<digipeater> ... ]           65
     7.3.9.  dir [<dirname>]                                              66
     7.3.10.  disconnect [<session #>]                                    66
     7.3.11.  echo [accept|refuse]                                        66
     7.3.12.  eol [unix|standard]                                         66
     7.3.13.  escape <char>                                               67
     7.3.14.  etherstat                                                   67
     7.3.15.  exit                                                        67
     7.3.16.  finger                                                      67
     7.3.17.  ftp <hostid>                                                67
     7.3.17.1.  abort                                                     67
     7.3.17.2.  dir [<file>|<directory> [<localfile>]]                    67
     7.3.17.3.  get <remote_file> [<local_file>]                          68
     7.3.17.4.  ls [<file>|<directory> [<localfile>]]                     68
     7.3.17.5.  mkdir <remote_directory>                                  68
     7.3.17.6.  put <local_file> [<remote_file>]                          68
     7.3.17.7.  rmdir <remote_directory>                                  68
     7.3.17.8.  type [a|i|l<bytesize>]                                    68
     7.3.18.  help                                                        69
     7.3.19.  hostname [<name>]                                           69
     7.3.20.  log [stop|<file>]                                           69
     7.3.21.  ip                                                          69
     7.3.21.1.  ip address [<hostid>]                                     69
     7.3.21.2.  ip status                                                 69
     7.3.21.3.  ip ttl [<val>]                                            69
     7.3.22.  memstat                                                     69
     7.3.23.  mode <interface> [vc|datagram]                              69
     7.3.24.  mulport [on|off]                                            70
     7.3.25.  param <interface> [param]                                   71
     7.3.26.  pwd [<dirname>]                                             71
     7.3.27.  record [<filename>|off]                                     71
     7.3.28.  reset [<session>]                                           71
     7.3.29.  route                                                       71
     7.3.30.  session [<session #>]                                       72
     7.3.31.  shell                                                       73
     7.3.32.  smtp                                                        73
     7.3.32.1.  smtp gateway [<hostid>]                                   73
     7.3.32.2.  smtp kick                                                 73
     7.3.32.3.  smtp maxclients [<val>]                                   73
     7.3.32.4.  smtp timer [<val>]                                        73
     7.3.32.5.  smtp trace [<val>]                                        73
     7.3.33.  start                                                       73
     7.3.34.  stop                                                        74
     7.3.35.  tcp                                                         74
     7.3.35.1.  tcp irtt [<val>]                                          74
     7.3.35.2.  tcp kick <tcp_addr>                                       74
     7.3.35.3.  tcp mss [<size>]                                          74
     7.3.35.4.  tcp reset <tcb_addr>                                      74
     7.3.35.5.  tcp rtt <tcp_addr> <rtval>                                74
     7.3.35.6.  tcp status [<tcb_addr>]                                   74
     7.3.35.7.  tcp window [<val>]                                        75
     7.3.36.  telnet <hostid>                                             75
     7.3.37.  trace [<interface> [<flags>]|allmode|cmdmode]               75
     7.3.38.  udp status                                                  75
     7.3.39.  upload [<filename>]                                         75
     7.3.40.  ?                                                           75

     8.  Appendices                                                       76
     8.1.  Obtaining Current Bits                                         76
     8.1.1.  Via FTP on the Internet                                      76
     8.1.2.  On PC Floppies                                               76
     8.1.2.1.  WB3FFV's Phone BBS in the USA                              76
     8.1.2.2.  PA0GRI's Phone BBS in Holland                              77
     8.1.3.  Gary Sanders' Phone BBS in the USA                           77
     8.1.4.  Michael Broqvist in Sweden                                   77
     8.2.  The KISS Specification                                         78
     8.3.  The KISS Host to TNC Protocol                                  78
     8.3.1.  The Protocol Specification                                   78
     8.3.1.1.  Introduction                                               78
     8.3.1.2.  Asynchtronous Frame Format                                 78
     8.3.1.2.1.  Transparency                                             79
     8.3.1.3.  Control of the Raw TNC                                     79
     8.3.1.4.  Persistence                                                80
     8.3.2.  The TNC-2 Implementation                                     80
     8.3.3.  The TNC-1 Implementation                                     81
     8.3.4.  The VADCG/ASHBY Implementation                               81
     8.3.5.  The AEA Implemenation                                        81
     8.3.6.  The Kantronics Implemenation                                 81
     8.5.  Information for Software Developers                            93
     8.6.  Technical Information for Client/Server Developers             94
     8.6.1.  Data Structures                                              94
     8.6.2.  Timer Services                                               95
     8.6.3.  Internet Type-of-Service                                     95
     8.6.4.  The Internet Protocol Implementation.                        95
     8.6.5.  IP Gateway (Packet Router) Support                           95
     8.6.6.  IP Interfaces                                                96
     8.6.7.  IP Host Support                                              98
     8.6.8.  The Transmission Control Protocol (TCP)                      99
     8.6.9.  The User Datagram Protocol (UDP)                            103