HAM Radio 1/HamRadio.cdr/exam/g1emmnos/userref.out

Text File | 1990-09-26 | 128KB | 2,641 lines

                NNNEEETTT UUUssseeerrr RRReeefffeeerrreeennnccceee MMMaaannnuuuaaalll (((NNNOOOSSS VVVeeerrrsssiiiooonnn)))


                            Phil Karn, KA9Q






111...  TTThhheee NNNEEETTT...EEEXXXEEE PPPrrrooogggrrraaammm

The MS-DOS executable file nnneeettt...eeexxxeee provides  Internet  (TCP/IP),  NET/ROM  and
AX.25  facilities.   Because it has an internal multitasking operating system,
nnneeettt...eeexxxeee can act simultaneously as a client, a server and a packet  switch  for
all  three  sets  of  protocols.  That  is, while a local user accesses remote
services, the system can also provide those  same  services  to  remote  users
while  also  switching  IP, NET/ROM and AX.25 packets and frames between other
client and server nodes.

The keyboard and display is used by the local operator to  control  both  host
and gateway level functions, for which a number of commands are provided.


111...111...  SSStttaaarrrtttuuuppp

When nnneeettt...eeexxxeee is executed without arguments,  it  attempts  to  open  the  file
aaauuutttoooeeexxxeeeccc...nnneeettt  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 attaching communication interfaces,
configuring network addresses, and starting the various services.  If  nnneeettt...eeexxxeee
is  invoked  with  an  argument,  it  is  taken to be the name of an alternate
startup file to be read instead of aaauuutttoooeeexxxeeeccc...nnneeettt.

Three command-line options are accepted:


111...111...111...  ---bbb

The ---bbb option specifies the use of BIOS for console output; the default is  to
write directly to the video display buffer. Use this option if you are running
under a windowing package and have trouble with output "bleeding  through"  on
top of other windows.


111...111...222...  ---sss

The ---sss option specifies the size of the _s_o_c_k_e_t array to  be  allocated  within
net.   This   limits   the  number  of  network  connections  that  may  exist
simultaneously; the default is 40.








                                    - 2 -


111...111...333...  ---ddd

The ---ddd  option  allows  the  user  to  specify  a  "root"  directory  for  the
configuration  and  spool  files;  it  defaults  to  the root directory of the
system.


222...  CCCooonnnsssooollleee mmmooodddeeesss

The console may be in one of two modes: _c_o_m_m_a_n_d _m_o_d_e and  _c_o_n_v_e_r_s_e  _m_o_d_e.   In
command  mode,  the prompt nnneeettt>>> 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  _c_u_r_r_e_n_t _s_e_s_s_i_o_n.  Sessions come in eight types:
_T_e_l_n_e_t, _F_T_P, _A_X_2_5, _N_E_T_R_O_M, _P_i_n_g, _M_o_r_e, _H_o_p_c_h_e_c_k and _T_i_p.

In a Telnet, AX25, NETROM, or Tip 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  command; if so it is executed locally.  If not, it is "passed
through" to the remote FTP server.  (See the section titled FFFTTTPPP  SSSuuubbbcccooommmmmmaaannndddsss).
In  a  Ping session the user may test the path to a remote site, and in a More
session, the user may examine a local file. A  Hopcheck  session  is  used  to
trace the path taken by packets to reach a specified destination.

The keyboard also has _c_o_o_k_e_d and _r_a_w 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, FTP or  NET/ROM  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 eeeccchhhooo command).

On the IBM-PC, the user may escape back to command mode  by  hitting  the  F10
key.   On other systems, the user must enter the _e_s_c_a_p_e 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 eeessscccaaapppeee command).

In the IBM PC version, each session (including the command "session") has  its
own  screen.   When  a new session is created, the command display is saved in
memory and the screen is cleared. When the command escape key (usually F10) is
hit,  the  current session screen is saved and the command screen is restored.
When a session is resumed, its screen is restored exactly as it appeared  when
it was last current.


333...  CCCooommmmmmaaannndddsss

This section describes the commands recognized in  command  mode.   These  are
given in the following notation:











                                    - 3 -


     command
     command literal_parameter
     command subcommand <parameter>
     command [<optional_parameter>]
     command a|b

Many commands take  subcommands  or  parameters,  which  may  be  optional  or
required.  In  general,  if  a required subcommand or parameter is omitted, an
error message will summarize the available subcommands or required parameters.
(Giving a '?' in place of the subcommand will also generate the message.  This
is useful when the command word alone is a valid command.) If a command  takes
an  optional  value  parameter,  issuing  the  command  without  the parameter
generally displays the current value of the variable. (Exceptions to this rule
are noted in the individual command descriptions.)

Two or more parameters separated by vertical bar(s) denote  a  choice  between
the  specified  values.  Optional parameters are shown enclosed in [brackets],
and a parameter enclosed in <angle brackets> should be replaced with an actual
value or string.  For example, the notation <<<hhhooossstttiiiddd>>> denotes an actual host or
gateway, which may be specified in one of two ways: as a symbolic name  listed
in  the  file  ///dddooommmaaaiiinnn...tttxxxttt,  or  as  a  numeric  IP  address in dotted decimal
notation, e.g., 44.0.0.1. If a domain name server is available on the  network
and  configured  into  _n_e_t,  it  will  be  queried  if the name isn't found in
///dddooommmaaaiiinnn...tttxxxttt.

All commands and many subcommands may  be  abbreviated.  You  only  need  type
enough  of  a command's name to distinguish it from others that begin with the
same series of letters. Parameters, however, must be typed in full.

Certain FTP subcommands, e.g., pppuuuttt,,, gggeeettt,,, dddiiirrr,  etc,  are  recognized  only  in
converse  mode  with  the  appropriate FTP session; they are not recognized in
command mode.


333...111...  <<<cccrrr>>>

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, _n_e_t
remains in command mode.


333...222...  !!!

An alias for the ssshhheeellllll command.


333...333...  ###

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


333...444...  aaabbbooorrrttt [[[<<<ssseeessssssiiiooonnn ###>>>]]]










                                    - 4 -


Abort a FTP gggeeettt,,, pppuuuttt ooorrr dddiiirrr  operation  in  progress.  If  issued  without  an
argument,  the  current  session  is  aborted. (This command works only on FTP
sessions.) When receiving a file, aaabbbooorrrttt simply resets the data connection; the
next  incoming  data  packet will generate a TCP RST (reset) response to clear
the remote server.  When sending a file, aaabbbooorrrttt sends a premature  end-of-file.
Note  that  in  both  cases aaabbbooorrrttt will leave a partial copy of the file on the
destination machine, which must be removed manually if it is unwanted.


333...555...  aaarrrppp

Display 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.


333...666...  aaarrrppp aaadddddd <<<hhhooossstttiiiddd>>> eeettthhheeerrrnnneeettt|||aaaxxx222555 <<<eeettthhheeerrrnnneeettt aaaddddddrrreeessssss>>>|||<<<aaaxxx222555___aaaddddddrrreeessssss>>>

Add a permanent entry  to  the  table.  It  will  not  time  out  as  will  an
automatically-created entry, but must be removed with the aaaxxx222555 dddrrroooppp command.


333...777...  aaarrrppp pppuuubbbllliiissshhh <<<hhhooossstttiiiddd>>> eeettthhheeerrrnnneeettt|||aaaxxx222555 <<<eeettthhheeerrrnnneeettt aaaddddddrrreeessssss>>>|||<<<aaaxxx222555___aaaddddddrrreeessssss>>>

The aaarrrppp pppuuubbbllliiissshhh command is similar to the aaarrrppp aaadddddd  command,  but  system  will
also  respond  to  any  ARP  request  it  sees  on  the network that seeks the
specified address.  (Use this feature with great care.)


333...888...  aaarrrppp dddrrroooppp <<<hhhooossstttiiiddd>>> aaaxxx222555|||eeettthhheeerrrnnneeettt

Remove the specified entry from the ARP table.


333...999...  aaarrrppp fffllluuussshhh

Drop all automatically-created entries in the ARP table; permanent entries are
not affected.


333...111000...  aaasssyyyssstttaaattt

Display statistics on attached asynchronous communications interfaces (8250 or
16550A),  if any. The display for each port consists of three lines. The first
line gives the port label and the configuration flags; these indicate  whether
the  port is a 16550A chip, the _t_r_i_g_g_e_r _c_h_a_r_a_c_t_e_r if any, and whether CTS flow
control is enabled. (The trigger character when received causes the driver  to
signal upper layer software that data is ready; it is automatically set to the
appropriate frame end character for SLIP and NRS lines.)

The second line of the status display shows receiver (RX)  event  counts:  the
total  number  of  receive  interrupts, received characters, receiver overruns
(lost characters) and the receiver _h_i_g_h _w_a_t_e_r _m_a_r_k.  The high  water  mark  is
the  maximum  number  of  characters ever read from the device during a single







                                    - 5 -


interrupt. This is useful for monitoring system interrupt latency  margins  as
it  shows  how  close  the  port  hardware  has come to overflowing due to the
inability of the CPU to respond to a receiver interrupt in  time.  8250  chips
have  no  FIFO, so the high water mark cannot go higher than 2 before overruns
occur. The 16550A chip, however, has a 16-byte receive FIFO which the software
programs  to  interrupt  the  CPU when the FIFO is one-quarter full.  The high
water mark should typically be 4 or 5 when a 16550A  is  used;  higher  values
indicate  that  the  CPU  has at least once been slow to respond to a receiver
interrupt.

When the 16550A is used, a count of FIFO timeouts is also displayed on the  RX
status  line.  These  are  generated  automatically  by  the 16550A when three
character intervals go by with more than 0 but less than 4 characters  in  the
FIFO.  Since the characters that make up a SLIP or NRS frame are normally sent
at full line speed, this count will usually be a lower bound on the number  of
frames  received  on  the port, as only the last fragment of a frame generally
results in a timeout (and then only when the frame is  not  a  multiple  of  4
bytes long.)

The third line shows transmit (TX) statistics,  including  a  total  count  of
transmit  interrupts, transmitted characters, the length of the transmit queue
in bytes, and the number of CTS interrupts (this latter  value  will  be  zero
unless CTS flow control has been enabled.)


333...111111...  aaattttttaaaccchhh <<<hhhwww tttyyypppeee>>> .........

Configure and attach a hardware interface  to  the  system.  The  details  are
highly  interface  dependent. Drivers are available for the following hardware
types:


333...111111...111...  aaasssyyy

Standard PC asynchronous interface (com  port)  using  the  National  8250  or
16550A chip.


333...111111...222...  dddrrrsssiii

N6TTO driver for the DRSI PCPA 8530 card.


333...111111...333...  eeeaaagggllleee

WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530).


333...111111...444...  hhhaaapppnnn

KE3Z driver for the Hamilton  Amateur  Packet  Network  adapter  board  (Intel
8273).











                                    - 6 -


333...111111...555...  hhhsss

Special "high speed" 8530 driver for the WA4DSY 56kb/s modem.


333...111111...666...  pppaaaccckkkeeettt

Driver for use  with  separate  software  "packet  drivers"  meeting  the  FTP
Software, Inc, Software Packet Driver specification.


333...111111...777...  pppccc111000000

Driver for the PACCOMM PC-100 (Zilog 8530) card.


333...111111...888...  ssscccccc

PE1CHL driver for generic 8530 cards.

Detailed instructions for each driver are in the section AAAttttttaaaccchhh CCCooommmmmmaaannndddsss.   An
easy  way to obtain a summary of the parameters required for a given device is
to issue a partial attach command, e.g., aaattttttaaaccchhh pppaaaccckkkeeettt.  This produces a usage
message giving the complete command format.


333...111222...  aaaxxx222555 bbbllliiimmmiiittt [[[<<<vvvaaalll>>>]]]

Display or set the AX25 retransmission backoff limit. Normally each successive
AX25  retransmission  is  delayed by twice the value of the previous interval;
this is called _b_i_n_a_r_y _e_x_p_o_n_e_n_t_i_a_l  _b_a_c_k_o_f_f.   When  the  backoff  reaches  the
blimit setting it is held at that value, which defaults to 30.  To prevent the
possibility of "congestion collapse" on a loaded channel, blimit should be set
at least as high as the number of stations sharing the channel.


333...111333...  aaaxxx222555 dddiiigggiiipppeeeaaattt [[[ooonnn|||oooffffff]]]

Display or set the digipeater enable flag.


333...111444...  aaaxxx222555 fffllluuussshhh

Clear the AX.25 "heard" list (see aaaxxx222555 hhheeeaaarrrddd).


333...111555...  aaaxxx222555 hhheeeaaarrrddd

Display the AX.25 "heard" list. For each interface that is configured  to  use
AX.25,  a  list  of all callsigns heard through that interface is shown, along
with a count of the  number  of  packets  heard  from  each  station  and  the
interval,  in hr:min:sec format, since each station was last heard.  The local
station always appears  first  in  the  listing;  the  packet  count  actually
reflects  the number of packets transmitted. This entry is always present even
if no packets have been sent.








                                    - 7 -


333...111666...  aaaxxx222555 iiirrrtttttt [[[<<<vvvaaalll>>>]]]

Display or set the initial value of smoothed round trip time to be used when a
new  AX25  connection  is  created.  The value is in milliseconds.  The actual
round trip time will be learned by measurement once the  connection  has  been
established.


333...111777...  aaaxxx222555 kkkiiiccckkk <<<aaaxxxcccbbb>>>

Force a retransmission on the specified AX.25 control block.


333...111888...  aaaxxx222555 mmmaaaxxxfffrrraaammmeee [[[<<<vvvaaalll>>>]]]

Establish 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.


333...111999...  aaaxxx222555 mmmyyycccaaallllll [[[<<<cccaaallllll>>>]]]

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 commands
using AX.25 mode are given.


333...222000...  aaaxxx222555 pppaaacccllleeennn [[[<<<vvvaaalll>>>]]]

Limit the size of I-fields on new  AX.25  connections.   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 fragment at the other end of the link. To
have any effect on IP datagrams, this parameter should be less than  or  equal
to the MTU of the associated interface.


333...222111...  aaaxxx222555 pppttthhhrrreeessshhh [[[<<<vvvaaalll>>>]]]

Display or set the  poll  threshold  to  be  used  for  new  AX.25  Version  2
connections.   The poll threshold controls retransmission behavior as follows.
If the oldest unacknowledged I-frame size is less than the poll threshold,  it
will  be  sent  with  the poll (P) bit set if a timeout occurs.  If the oldest
unacked I-frame size is equal to or greater than the threshold, then a  RR  or
RNR  frame,  as  appropriate,  with the poll bit set will be sent if a timeout
occurs.

The idea behind the poll threshold is that the extra time  needed  to  send  a
"small" I-frame instead of a supervisory frame when polling after a timeout is
small, and since there's a good chance the I-frame will have to be sent anyway
(i.e., if it were lost previously) then you might as well send it as the poll.
But if the I-frame is large, send  a  supervisory  (RR/RNR)  poll  instead  to
determine  first  if  retransmitting  the  oldest  unacknowledged  I-frame  is
necessary; the timeout might have been caused by a lost acknowledgement.  This
is  obviously  a  tradeoff, so experiment with the poll threshold setting. The
default is 128 bytes, one half the default value of pppaaacccllleeennn.







                                    - 8 -


333...222222...  aaaxxx222555 rrreeessseeettt <<<aaaxxxcccbbb>>>

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


333...222333...  aaaxxx222555 rrreeetttrrryyy [[[<<<vvvaaalll>>>]]]

Limit the number of successive unsuccessful  retransmission  attempts  on  new
AX.25  connections.  If  this  limit  is  exceeded,  link  re-establishment is
attempted. If this fails rrreeetttrrryyy times, then the connection is abandoned and all
queued data is deleted.


333...222444...  aaaxxx222555 rrrooouuuttteee

Display the AX.25 routing table that specifies the digipeaters to be  used  in
reaching a given station.


333...222555...  aaaxxx222555 rrrooouuuttteee aaadddddd <<<tttaaarrrgggeeettt>>> [[[dddiiigggiiisss ......... ]]]

Add an entry to the AX.25 routing table.   An  automatic  aaaxxx222555  rrrooouuuttteee  aaadddddd  is
executed  if  digipeaters  are  specified  in an AX25 cccooonnnnnneeecccttt command, or if a
connection is received from a remote station via digipeaters.  Such  automatic
routing table entries won't override locally created entries, however.


333...222666...  aaaxxx222555 rrrooouuuttteee dddrrroooppp <<<tttaaarrrgggeeettt>>>

Drop an entry from the AX.25 routing table.


333...222777...  aaaxxx222555 ssstttaaatttuuusss [[[<<<aaaxxxcccbbb>>>]]]

Without an argument, display a one-line summary of each AX.25  control  block.
If  the  address  of  a particular control block is specified, 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.


333...222888...  aaaxxx222555 ttt333 [[[<<<vvvaaalll>>>]]]

Display or set the AX.25 idle "keep alive" timer. Value is in milliseconds.


333...222999...  aaaxxx222555 vvveeerrrsssiiiooonnn [[[111|||222]]]

Display or set the version of the AX.25 protocol to  attempt  to  use  on  new
connections.  The  default  is 1 (the version that does not use the poll/final
bits).


333...333000...  aaaxxx222555 wwwiiinnndddooowww [[[<<<vvvaaalll>>>]]]










                                    - 9 -


Set 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
I-frames  containing  network  (IP,  NET/ROM)  packets  are  always  processed
immediately and are not placed on the receive queue.  However, when  an  AX.25
connection  carries  both  interactive  and  network  packet  traffic,  an RNR
generated because of backlogged interactive traffic  will  also  stop  network
packet traffic from being sent.


333...333111...  cccddd [[[<<<dddiiirrrnnnaaammmeee>>>]]]

Change the current working directory, and display the new setting.  Without an
argument,  cccddd  simply  displays the current directory without change.  The pppwwwddd
command is an alias for cccddd.


333...333222...  ccclllooossseee [[[<<<ssseeessssssiiiooonnn ###>>>]]]

Close the specified session; without an argument, close the  current  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 rrreeessseeettt
command, in that it is less likely to leave the remote TCP  in  a  "half-open"
state.


333...333333...  cccooonnnnnneeecccttt <<<iiifffaaaccceee>>> <<<cccaaallllllsssiiigggnnn>>> [[[<<<dddiiigggiiipppeeeaaattteeerrr>>> ......... ]]]

Initiate a "vanilla" AX.25 session  to  the  specified  call  sign  using  the
specified  interface. Data sent on this session goes out in conventional AX.25
packets with no upper layer  protocol.   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  terminal-to-
terminal,  IP  and  NET/ROM  traffic,  with  the  three  types  of  data being
automatically separated by their AX.25 Level 3 Protocol IDs.

Up to 7 optional digipeaters may be given; note  that  the  word  vvviiiaaa  is  NOT
needed. If digipeaters are specified, they are automatically added to the AX25
routing table as though the aaaxxx222555 rrrooouuuttteee  aaadddddd  command  had  been  given  before
issuing the connect command.


333...333444...  dddeeetttaaaccchhh <<<iiifffaaaccceee>>>

Detach a previously attached interface from the system. All IP  routing  table
entries  referring to this interface are deleted, and forwarding references by
any other interface to this interface are removed.











                                    - 10 -


333...333555...  dddiiirrr [[[<<<dddiiirrrnnnaaammmeee>>>]]]

List the contents of the specified directory on the console. If no argument is
given,  the current directory is listed. Note that this command works by first
listing the directory into a temporary file, and then creating a mmmooorrreee  session
to display it. After this completes, the temporary file is deleted.


333...333666...  dddiiissscccooonnnnnneeecccttt [[[<<<ssseeessssssiiiooonnn ###>>>]]]

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


333...333777...  dddooommmaaaiiinnn aaaddddddssseeerrrvvveeerrr <<<hhhooossstttiiiddd>>> [[[<<<hhhooossstttiiiddd>>> .........]]]

Add one or more domain name server(s) to the list of name servers.


333...333888...  dddooommmaaaiiinnn dddrrrooopppssseeerrrvvveeerrr <<<hhhooossstttiiiddd>>> [[[<<<hhhooossstttiiiddd>>> .........]]]

Remove one or more domain name server(s) from the list of name servers.


333...333999...  dddooommmaaaiiinnn llliiissstttssseeerrrvvveeerrrsss

List the currently configured domain name servers, along  with  statistics  on
how  many  queries  and  replies  have  been exchanged with each one, response
times, etc.


333...444000...  dddooommmaaaiiinnn sssuuuffffffiiixxx [[[<<<dddooommmaaaiiinnn sssuuuffffffiiixxx>>>]]]

Display or specify the default domain name suffix to be  appended  to  a  host
name  when  it  contains  no  periods.  For  example,  if the suffix is set to
aaammmppprrr...ooorrrggg and the user enters ttteeelllnnneeettt kkkaaa999qqq, the domain resolver will attempt  to
find  kkkaaa999qqq...aaammmppprrr...ooorrrggg.  If  the  host  name  being  sought  contains one or more
periods, however, the default suffix is  NOT  applied;  e.g.,  ttteeelllnnneeettt  fffoooooo...bbbaaarrr
would NOT be turned into fffoooooo...bbbaaarrr...aaammmppprrr...ooorrrggg.


333...444111...  dddooommmaaaiiinnn tttrrraaaccceee [[[ooonnn|||oooffffff]]]

Display or set the flag controlling the tracing of domain server requests  and
responses.  Trace  messages will be seen only if a domain name being sought is
not found in the local cache file, ///dddooommmaaaiiinnn...tttxxxttt.


333...444222...  eeeccchhhooo [[[aaacccccceeepppttt|||rrreeefffuuussseee]]]

Display or set 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
nothing  is actually sent until a carriage return is typed. Local line editing







                                    - 11 -


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
timesharing 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 Telnet WILL ECHO offer immediately upon receiving  an  incoming
Telnet  connection  request.  If  eeeccchhhooo  aaacccccceeepppttt  is  in effect, a client Telnet
session will automatically 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 eeeccchhhooo rrreeefffuuussseee  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:  Berkeley  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 sssttttttyyy ---eeeccchhhooo command to the shell once you have logged in.)


333...444333...  eeeooolll [[[uuunnniiixxx|||ssstttaaannndddaaarrrddd]]]

Display or set Telnet's end-of-line behavior when in  remote  echo  mode.   In
standard  mode,  each  key  is  sent as-is. In unix mode, carriage returns are
translated to line feeds.   This  command  is  not  necessary  with  all  UNIX
systems;  use  it only when you find that a particular system responds to line
feeds but not carriage returns.  Only SunOS release 3.2 seems to exhibit  this
behavior; later releases are fixed.


333...444444...  eeessscccaaapppeee [[[<<<ccchhhaaarrr>>>]]]

Display or set the  current  command-mode  escape  character  in  hex.   (This
command  is  not  provided on the IBM-PC; on the PC, the escape char is always
F10.)


333...444555...  eeettthhheeerrrssstttaaattt

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


333...444666...  eeexxxiiittt

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


333...444777...  fffiiinnngggeeerrr <<<uuussseeerrr@@@hhhooossstttiiiddd>>> [[[<<<uuussseeerrr@@@hhhooossstttiiiddd>>> .........]]]

Issue a network finger request for user uuussseeerrr at host hhhooossstttiiiddd.  This  creates  a
client  session  which  may  be  interrupted, resumed, reset, etc, just like a
Telnet client session.










                                    - 12 -


333...444888...  ffftttppp <<<hhhooossstttiiiddd>>>

Open an FTP control channel to the specified remote host  and  enter  converse
mode  on  the  new  session.   Responses  from the remote server are displayed
directly on the screen. See the chapter FFFTTTPPP SSSuuubbbcccooommmmmmaaannndddsss  for  descriptions  of
the commands available in an FTP session.


333...444999...  hhheeelllppp

Display a brief summary of top-level commands.


333...555000...  hhhoooppp ccchhheeeccckkk <<<hhhooossstttiiiddd>>>

Initiate a hhhooopppccchhheeeccckkk session to the specified host. This uses a series  of  UDP
"probe"  packets  with  increasing  IP TTL fields to determine the sequence of
gateways in the path to the specified destination. This function is  patterned
after the UNIX tttrrraaaccceeerrrooouuuttteee facility.

ICMP message tracing should be turned off before this command is executed (see
the iiicccmmmppp tttrrraaaccceee command).


333...555111...  hhhoooppp mmmaaaxxxttttttlll [[[<<<ttttttlll>>>]]]

Display or set the maximum TTL value to be used in hop check  sessions.   This
effectively bounds the radius of the search.


333...555222...  hhhoooppp mmmaaaxxxwwwaaaiiittt [[[<<<tttiiimmmeee>>>]]]

Display or set the maximum interval, in seconds, that a hopcheck session  will
wait for responses at each stage of the trace. The default is 5 seconds.


333...555333...  hhhoooppp qqquuueeerrriiieeesss [[[<<<cccooouuunnnttt>>>]]]

Display or set the number of UDP probes that will be sent at each stage of the
trace. The default is 3.


333...555444...  hhhoooppp tttrrraaaccceee [[[ooonnn|||oooffffff]]]

Display or set the flag that controls the display  of  additional  information
during a hop check session.


333...555555...  hhhooossstttnnnaaammmeee [[[<<<nnnaaammmeee>>>]]]

Display or set the local host's name. By convention this should be the same as
the  host's  primary  domain  name.  This  string is used only in the greeting
messages of the various network  servers;  note  that  it  does  NOT  set  the
system's IP address.









                                    - 13 -


333...555666...  hhhsss

Display statistics about the HS high speed  HDLC  driver  (if  configured  and
active).


333...555777...  iiicccmmmppp eeeccchhhooo [[[ooonnn|||oooffffff]]]

Display or set the flag controlling the  asynchronous  display  of  ICMP  Echo
Reply  packets.  This flag must be on for one-shot pings to work (see the pppiiinnnggg
command.)


333...555888...  iiicccmmmppp ssstttaaatttuuusss

Display  statistics  about  the  Internet  Control  Message  Protocol  (ICMP),
including the number of ICMP messages of each type sent or received.


333...555999...  iiicccmmmppp tttrrraaaccceee [[[ooonnn|||oooffffff]]]

Display or set the flag controlling the display of ICMP error messages.  These
informational  messages  are  generated  by  Internet  routers  in response to
routing, protocol or congestion problems. This option  should  be  turned  off
before  using  the  hhhooopppccchhheeeccckkk  facility because it relies on ICMP Time Exceeded
messages, and the asynchronous display of these messages will be mingled  with
hop check command output.


333...666000...  iiippp aaaddddddrrreeessssss [[[<<<hhhooossstttiiiddd>>>]]]

Display or set the default local IP address. This command must be given before
an  attach  command  if  it  is  to  be used as the default IP address for the
interface.


333...666111...  iiippp rrrtttiiimmmeeerrr [[[<<<vvvaaalll>>>]]]

Display or set the IP reassembly timeout. The default is 30 seconds.


333...666222...  iiippp ssstttaaatttuuusss

Display Internet Protocol (IP) statistics, such as  total  packet  counts  and
error counters of various types.


333...666333...  iiippp ttttttlll [[[<<<vvvaaalll>>>]]]

Display or set the default time-to-live  value  placed  in  each  outgoing  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.









                                    - 14 -


333...666444...  llloooggg [[[ssstttoooppp|||<<<fffiiillleee>>>]]]

Display or set the file name for logging server sessions. If ssstttoooppp is given  as
the  argument,  logging is terminated (the servers themselves are unaffected).
If a file name is given as an argument, server session  log  entries  will  be
appended to it.


333...666555...  mmmbbboooxxx

Display the status of the mailbox server system (if configured).


333...666666...  mmmeeemmmooorrryyy fffrrreeeeee

Display the storage allocator free list. Each entry  consists  of  a  starting
address, in hex, and a size, in decimal bytes.


333...666777...  mmmeeemmmooorrryyy sssiiizzzeeesss

Display a histogram of storage allocator request sizes. Each histogram bin  is
a binary order of magnitude (i.e., a factor of 2).


333...666888...  mmmeeemmmooorrryyy ssstttaaatttuuusss

Display a summary of storage allocator statistics. The first  line  shows  the
base  address of the heap, its total size, the amount of heap memory available
in bytes and as a percentage of the total heap size, and the amount of  memory
left  over  (i.e.,  not placed on the heap at startup) and therefore available
for shell subcommands.

The second line shows the total number of calls to allocate and free blocks of
memory,  the  difference  of  these  two values (i.e., the number of allocated
blocks outstanding), the number of allocation requests that were denied due to
lack  of  memory,  and  the  number  of calls to free() that attempted to free
garbage, e.g., by freeing the same block twice or freeing a garbled pointer.

The third line shows the number of calls to malloc and free that occurred with
interrupts  off. In normal situations these values should be zero.  The fourth
line shows statistics for the special  pool  of  fixed-size  buffers  used  to
satisfy  requests  for  memory  at interrupt time. The variables shown are the
number of buffers currently in  the  pool,  their  size,  and  the  number  of
requests that failed due to exhaustion of the pool.


333...666999...  mmmooodddeee <<<iiifffaaaccceee>>> [[[vvvccc|||dddaaatttaaagggrrraaammm]]]

Control the default transmission mode on the  specified  AX.25  interface.  In
dddaaatttaaagggrrraaammm  mode, IP packets are encapsulated in AX.25 UI frames and transmitted
without  any  other  link   level   mechanisms,   such   as   connections   or
acknowledgements.










                                    - 15 -


In vvvccc (virtual circuit) mode, IP packets are encapsulated in  AX.25  I  frames
and  are acknowledged at the link level according to the AX.25 protocol.  Link
level connections are opened if necessary.

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 resulting datagram
(or fragments) is further fragmented at the AX.25 layer if it  (or  they)  are
still  larger  than  the  AX.25  pppaaacccllleeennn  parameter.  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
retransmitted by the link layer).


333...777000...  mmmooorrreee <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]]

Display the specified file(s) a screen at a  time.  To  proceed  to  the  next
screen, press the space bar; to cancel the display, hit the 'q' key.  The mmmooorrreee
command creates a session that you can suspend and resume just like any  other
session.


333...777111...  pppaaarrraaammm <<<iiifffaaaccceee>>> [[[<<<pppaaarrraaammm>>> .........]]]

Invoke 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,
pppaaarrraaammm aaaxxx000 111 222555555  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
implementation of this command for the various interface drivers is incomplete
and subject to change.


333...777222...  pppiiinnnggg <<<hhhooossstttiiiddd>>> [[[<<<llleeennn>>> [[[<<<iiinnnttteeerrrvvvaaalll>>> [[[<<<iiinnncccffflllaaaggg>>>]]]]]]]]]

Ping (send ICMP Echo Request packets to) the specified host.  By  default  the
data  field  contains  only a small timestamp to aid in determining round trip
time; if the optional llleeennngggttthhh argument is given, the appropriate number of data
bytes (consisting of hex 55) are added to the ping packets.

If iiinnnttteeerrrvvvaaalll is specified, pings will be repeated indefinitely at the specified
interval,  in seconds; otherwise a single, "one shot" ping is done.  Responses
to one-shot pings appear asynchronously on the command screen, while  repeated
pings  create  a session that may be suspended and resumed.  Pinging continues
until the session is manually reset.

The iiinnncccffflllaaaggg option causes a repeated ping to increment the target  IP  address
for  each  ping;  it  is  an  experimental  feature for searching blocks of IP
addresses for active hosts.







                                    - 16 -


333...777333...  pppsss

Display all current processes in the system. The fields are as follows:

PPPIIIDDD - Process ID (the address of the process descriptor).

SSSPPP - The current value of the process stack pointer.

ssstttkkksssiiizzzeee - The size of the stack allocated to the process.

mmmaaaxxxssstttkkk - The apparent peak stack utilization of this process. This is done  in
a somewhat heuristic fashion, so the numbers should be treated as approximate.
If this number reaches or exceeds the stksize figure,  the  system  is  almost
certain  to  crash; the _n_e_t program should be recompiled to give the process a
larger allocation when it is started.

eeevvveeennnttt - The event this task is waiting for, if it is not runnable.

ffflll - Process status flags. There are three: I (Interrupts enabled), W (Waiting
for  event) and S (suspended - not currently used). The I flag is set whenever
a task has executed a pwait() call (wait for event)  without  first  disabling
hardware  interrupts.  Only tasks that wait for hardware interrupt events will
turn off this flag; this  is  done  to  avoid  critical  sections  and  missed
interrupts. The W flag indicates that the process is waiting for an event; the
eeevvveeennnttt column will be non-blank.  Note  that  although  there  may  be  several
runnable processes at any time (shown in the pppsss listing as those without the W
flag and with blank event fields) only one process is actually running at  any
one  instant (The Refrigerator Light Effect says that the pppsss command is always
the one running when this display is generated.)


333...777444...  pppwwwddd [[[<<<dddiiirrrnnnaaammmeee>>>]]]

An alias for the cccddd command.


333...777555...  rrreeecccooorrrddd [[[<<<fffiiillleeennnaaammmeee>>>|||oooffffff]]]

Append to fffiiillleeennnaaammmeee all data received on the current session.  Data sent on the
current  session  is  also written into the file except for Telnet sessions in
remote echo mode.  The command rrreeecccooorrrddd oooffffff stops recording and closes the file.


333...777666...  rrreeemmmooottteee [[[---ppp <<<pppooorrrttt>>>]]] [[[---kkk <<<kkkeeeyyy>>>]]] [[[---aaa <<<kkkiiiccckkkaaaddddddrrr>>>]]] <<<hhhooossstttiiiddd>>> eeexxxiiittt|||rrreeessseeettt|||kkkiiiccckkk

Send a UDP packet to the specified host commanding it to exit the net program,
reset  the  processor, or force a retransmission on TCP connections.  For this
command to be accepted, the remote system must be running  the  rrreeemmmooottteee  server
and the port number specified in the remote command must match the port number
given when the server was started on the remote system.  If the  port  numbers
do not match, or if the remote server is not running on the target system, the
command packet is ignored.  Even if  the  command  is  accepted  there  is  no
acknowledgement.










                                    - 17 -


The kick command forces a retransmission timeout on all TCP  connections  that
the  remote  node  may  have  with  the local node.  If the -a option is used,
connections to the specified host are kicked instead. No key is  required  for
the kick subcommand.

The exit and reset subcommands  are  mainly  useful  for  restarting  the  net
program  on  a  remote unattended system after the configuration file has been
updated.  The remote system should invoke the net program  automatically  upon
booting,  preferably  in an infinite loop.  For example, under MS-DOS the boot
disk should contain the following in aaauuutttoooeeexxxeeeccc...nnneeettt:

     :loop
     net
     goto :loop

333...777777...  ---sss <<<kkkeeeyyy>>>

The exit and reset subcommands of remote require a password.  The password  is
set  on a given system with the ---sss option, and it is specified in a command to
a remote system with the ---kkk option. If no password is set with the ---sss  option,
then the exit and reset subcommands are disabled.

Note that rrreeemmmooottteee is an experimental feature in NOS; it is _n_o_t yet supported by
any other TCP/IP implementation.


333...777888...  rrreeennnaaammmeee <<<fffiiillleee111>>> <<<fffiiillleee222>>>

Rename fffiiillleee111 to fffiiillleee222.


333...777999...  rrreeessseeettt [[[<<<ssseeessssssiiiooonnn>>>]]]

Reset the specified session; if  no  argument  is  given,  reset  the  current
session.   This command should be used with caution since it does not reliably
inform the remote end that the connection no longer exists.  (In TCP  a  reset
(RST)  message  will  be  automatically  generated  should the remote TCP send
anything 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.)


333...888000...  rrriiippp aaacccccceeepppttt <<<gggaaattteeewwwaaayyy>>>

Remove the specified gateway  from  the  RIP  filter  table,  allowing  future
broadcasts from that gateway to be accepted.


333...888111...  rrriiippp aaadddddd <<<hhhooossstttiiiddd>>> <<<iiinnnttteeerrrvvvaaalll>>> [[[<<<ffflllaaagggsss>>>]]]

Add an entry to the RIP broadcast table. The IP routing table will be sent  to
hhhooossstttiiiddd  every  iiinnnttteeerrrvvvaaalll  seconds.  If  ffflllaaagggsss  is  specified  as 1, then "split
horizon" processing will be performed for this destination. That  is,  any  IP
routing table entries pointing to the interface that will be used to send this
update will be removed from the update.  If split horizon  processing  is  not
specified,  then  all routing table entries except those marked "private" will







                                    - 18 -


be sent in each update.  (Private entries are never sent in RIP packets).

Triggered updates are always done. That is, any change in  the  routing  table
that  causes  a  previously  reachable  destination to become unreachable will
trigger an update that advertises the destination with metric 15,  defined  to
mean "infinity".

Note that for RIP packets to be sent properly to a  broadcast  address,  there
must  exist correct IP routing and ARP table entries that will first steer the
broadcast to the correct interface  and  then  place  the  correct  link-level
broadcast  address  in  the  link-level  destination  field.  If a standard IP
broadcast address convention is used (e.g., 128.96.0.0 or 128.96.255.255) then
chances are you already have the necessary IP routing table entry, but unusual
subnet or cluster-addressed networks may require special attention.   However,
an  aaarrrppp  aaadddddd  command  will  be  required  to  translate  this  address to the
appropriate link level broadcast address, e.g.,


arp add 128.96.0.0 ethernet ff:ff:ff:ff:ff:ff

for an Ethernet network, and


arp add 44.255.255.255 ax25 qst-0

for an AX25 packet radio channel.


333...888222...  rrriiippp dddrrroooppp <<<dddeeesssttt>>>

Remove an entry from the RIP broadcast table.


333...888333...  rrriiippp mmmeeerrrgggeee [[[ooonnn|||oooffffff]]]

This flag controls an experimental feature for consolidating redundant entries
in  the  IP  routing  table. When rip merging is enabled, the table is scanned
after processing each RIP update. An entry  is  considered  redundant  if  the
target(s)  it  covers  would  be routed identically by a less "specific" entry
already in the table. That is, the target address(es) specified by  the  entry
in  question  must  also match the target addresses of the less specific entry
and the two entries must have the  same  interface  and  gateway  fields.  For
example, if the routing table contains


Dest            Len Interface    Gateway          Metric  P Timer  Use
1.2.3.4         32  ethernet0    128.96.1.2       1       0 0      0
1.2.3           24  ethernet0    128.96.1.2       1       0 0      0

then the first entry would be deleted  as  redundant  since  packets  sent  to
1.2.3.4  will  still  be  routed  correctly by the second entry. Note that the
relative metrics of the entries are ignored.











                                    - 19 -


333...888444...  rrriiippp rrreeefffuuussseee <<<gggaaattteeewwwaaayyy>>>

Refuse to accept RIP updates from the specified gateway by adding the  gateway
to the RIP filter table. It may be later removed with the rrriiippp aaacccccceeepppttt command.


333...888555...  rrriiippp rrreeeqqquuueeesssttt <<<gggaaattteeewwwaaayyy>>>

Send a RIP Request packet to the specified gateway, causing it to reply with a
RIP Response packet containing its routing table.


333...888666...  rrriiippp ssstttaaatttuuusss

Display RIP status, including a count  of  the  number  of  packets  sent  and
received,  the  number  of  requests  and responses, the number of unknown RIP
packet types, and the number of refused RIP updates from hosts in  the  filter
table. A list of the addresses and intervals to which periodic RIP updates are
being sent is also shown, along with the contents of the filter table.


333...888777...  rrriiippp tttrrraaaccceee [[[000|||111|||222]]]

This variable controls the tracing  of  incoming  and  outgoing  RIP  packets.
Setting  it  to 0 disables all RIP tracing. A value of 1 causes changes in the
routing table to be displayed, while packets that cause no  changes  cause  no
output.  Setting  the variable to 2 produces maximum output, including tracing
of RIP packets that cause no change in the routing table.


333...888888...  rrrooouuuttteee

With no arguments, rrrooouuuttteee displays the IP routing table.


333...888999...   rrrooouuuttteee  aaadddddd  <<<dddeeesssttt___hhhooossstttiiiddd>>>[[[///bbbiiitttsss]]]|||dddeeefffaaauuulllttt   <<<iiifffaaaccceee>>>   [[[<<<gggaaattteeewwwaaayyy___hhhooossstttiiiddd>>>
[[[<<<mmmeeetttrrriiiccc>>>]]]]]]

This command adds an entry to the routing table. It requires at least two more
arguments, the host_id of the target destination and the 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 gggaaattteeewwwaaayyy___hhhooossstttiiiddd 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,  gggaaattteeewwwaaayyy___hhhooossstttiiiddd  is  also
unnecessary  since  the destination address is used to determine the interface
link address).

The optional ///bbbiiitttsss 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 significance) 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








                                    - 20 -


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 bbbiiitttsss 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 dddeeefffaaauuulllttt is used to route datagrams  to  addresses  not
matched  by  any  other  entries  in  the  routing  table; it is equivalent to
specifying a ///bbbiiitttsss 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 unknown 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).

Here are some examples of 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

# The station with IP address 44.0.0.10 is on the local AX.25 channel
route add 44.0.0.10 ax0

333...999000...  rrrooouuuttteee aaaddddddppprrriiivvvaaattteee <<<dddeeesssttt hhhooossstttiiiddd>>>[[[///bbbiiitttsss]]]|||dddeeefffaaauuulllttt <<<iiifffaaaccceee>>> [[[<<<gggaaattteeewwwaaayyy hhhooossstttiiiddd>>>
[[[<<<mmmeeetttrrriiiccc>>>]]]]]]

This command is identical to rrrooouuuttteee aaadddddd except that it also marks the new entry
as private; it will never be included in outgoing RIP updates.


333...999111...  rrrooouuuttteee dddrrroooppp <<<dddeeesssttt hhhooossstttiiiddd>>>

rrrooouuuttteee dddrrroooppp 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.


333...999222...  ssseeessssssiiiooonnn [[[<<<ssseeessssssiiiooonnn ###>>>]]]

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
a  blank  line  at  this  point  puts  you in converse mode with that session.
Entering a session number as an argument to the session command will  put  you
in converse mode with that session.  If the Telnet server is enabled, the user







                                    - 21 -


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.


333...999333...  ssshhheeellllll

Suspends _n_e_t and executes a sub  shell  ("command  processor"  under  MS-DOS).
When  the sub shell exits, _n_e_t resumes (under MS-DOS, enter the eeexxxiiittt command).
Background activity (FTP servers, etc) is also suspended  while  the  subshell
executes.  Note  that  this will fail unless there is sufficient unused memory
for the subshell  and  whatever  command  the  user  tries  to  run  (see  the
discussion of ---fff option to nnneeettt...eeexxxeee).


333...999444...  sssmmmtttppp gggaaattteeewwwaaayyy [[[<<<hhhooossstttiiiddd>>>]]]

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


333...999555...  sssmmmtttppp kkkiiiccckkk

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


333...999666...  sssmmmtttppp mmmaaaxxxcccllliiieeennntttsss [[[<<<vvvaaalll>>>]]]

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.


333...999777...  sssmmmtttppp tttiiimmmeeerrr [[[<<<vvvaaalll>>>]]]

Displays or sets the interval, in seconds, between scans of the outbound  mail
queue. For example, sssmmmtttppp tttiiimmmeeerrr 666000000 will cause the system to check for outgoing
mail every 10 minutes and attempt to deliver anything  it  finds,  subject  of
course  to  the  sssmmmtttppp mmmaaaxxxcccllliiieeennntttsss 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 handle mail, since it saves wear and
tear on the floppy disk drive.


333...999888...  sssmmmtttppp tttrrraaaccceee [[[<<<vvvaaalll>>>]]]

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.











                                    - 22 -


333...999999...  sssoooccckkkeeettt [[[<<<sssoooccckkkeeettt ###>>>]]]

Without an argument, displays all active sockets, giving their index and type,
the address of the associated protocol control block and the and owner process
ID and name. If the index to an active socket is supplied, the status  display
for  the appropriate protocol is called.  For example, if the socket refers to
a TCP connection, the display will be that given by  the  tttcccppp  ssstttaaatttuuusss  command
with the protocol control block address.


333...111000000...  ssstttaaarrrttt aaaxxx222555|||dddiiissscccaaarrrddd|||eeeccchhhooo|||ffftttppp|||nnneeetttrrrooommm|||rrreeemmmooottteee|||sssmmmtttppp|||ttteeelllnnneeettt|||ttttttyyyllliiinnnkkk

Start the specified Internet server, allowing remote connection requests.


333...111000111...  ssstttoooppp aaaxxx222555|||dddiiissscccaaarrrddd|||eeeccchhhooo|||ffftttppp|||nnneeetttrrrooommm|||rrreeemmmooottteee|||sssmmmtttppp|||ttteeelllnnneeettt|||ttttttyyyllliiinnnkkk

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


333...111000222...  tttcccppp iiirrrtttttt [[[<<<vvvaaalll>>>]]]

Display or set the initial round trip time estimate, in  milliseconds,  to  be
used  for  new  TCP connections until they can measure and adapt to the actual
value.  The default is 5000 milliseconds (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.

TCP also keeps a _c_a_c_h_e of measured round trip times and mean deviations (MDEV)
for  current and recent destinations. Whenever a new TCP connection is opened,
the system first looks in this cache. If the destination is found, the  cached
IRTT  and MDEV values are used. If not, the default IRTT value mentioned above
is used, along with a MDEV of 0.  This feature is fully automatic, and it  can
improve performance greatly when a series of connections are opened and closed
to a given destination (e.g., a series of  FTP  file  transfers  or  directory
listings).


333...111000333...  tttcccppp kkkiiiccckkk <<<tttcccbbb___aaaddddddrrr>>>

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


333...111000444...  tttcccppp mmmssssss [[[<<<sssiiizzzeee>>>]]]

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. Changing  MSS  affects  only
future connections; existing connections are unaffected.










                                    - 23 -


333...111000555...  tttcccppp rrreeessseeettt <<<tttcccbbb___aaaddddddrrr>>>

Deletes the TCP control block at the specified address.


333...111000666...  tttcccppp rrrtttttt <<<tttcccbbb___aaaddddddrrr>>> <<<rrrttttttvvvaaalll>>>

Replaces the automatically computed round trip time in the specified TCB  with
the  rrrttttttvvvaaalll 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.


333...111000777...  tttcccppp ssstttaaatttuuusss [[[<<<tttcccbbb___aaaddddddrrr>>>]]]

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


333...111000888...  tttcccppp wwwiiinnndddooowww [[[<<<vvvaaalll>>>]]]

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


333...111000999...  ttteeelllnnneeettt <<<hhhooossstttiiiddd>>>

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


333...111111000...  tttiiippp <<<iiifffaaaccceee>>>

Creates a tttiiippp session that  connects  to  the  specified  interface  in  "dumb
terminal" mode.  The interface must have already been attached with the aaattttttaaaccchhh
command.  Any packet traffic (IP datagrams, etc) routed to the interface while
this  session exists will be discarded.  To close a tttiiippp session, use the rrreeessseeettt
command. It will then revert to normal sssllliiippp,,, nnnrrrsss or kkkiiissssss mode operation.

This feature is primarily useful for manually establishing  SLIP  connections.
At present, only the built-in "com" ports can be used with this command.


333...111111111...  tttrrraaaccceee [[[<<<iiifffaaaccceee>>> [[[<<<ffflllaaagggsss>>> [[[<<<tttrrraaaccceeefffiiillleee>>>]]]]]]]]]

Controls packet tracing by the interface drivers. Specific bits enable tracing
of  the various interfaces and the amount of information produced.  Tracing is
controlled on a per-interface basis; without arguments, tttrrraaaccceee 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 follows:









                                    - 24 -


BTIO
||||--- 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.
|------ Broadcast filter flag. If set, only packets specifically addressed
        to this node will be traced; broadcast packets will not be displayed.

If tttrrraaaccceeefffiiillleee is not specified, tracing will be to the console.


333...111111222...  uuudddppp ssstttaaatttuuusss

Displays the status of all UDP receive queues.


333...111111333...  uuupppllloooaaaddd [[[<<<fffiiillleeennnaaammmeee>>>]]]

Opens fffiiillleeennnaaammmeee and sends it on the current session as though it were typed  on
the terminal.


333...111111444...  wwwaaatttccchhh

Displays the current software stopwatch values, with min and max readings  for
each.  This  facility  allows  a  programmer  to measure the execution time of
critical sections of  code  with  microsecond  resolution.   This  command  is
supported  only on the IBM PC, and the meaning of each stopwatch value depends
on where the calls have been inserted for test purposes; the distribution copy
of _n_e_t usually has no stopwatch calls.


333...111111555...  ???

Same as the hhheeelllppp command.


444...  FFFTTTPPP SSSuuubbbcccooommmmmmaaannndddsss

During converse mode with an FTP server, everything typed on  the  console  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 channel. 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.)











                                    - 25 -


444...111...  dddiiirrr [[[<<<fffiiillleee>>>|||<<<dddiiirrreeeccctttooorrryyy>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]]]]

Without arguments, dddiiirrr requests that a full directory listing  of  the  remote
server's current directory be sent to the terminal.  If one argument is given,
this is passed along in the LIST command; this  can  be  a  specific  file  or
subdirectory  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.


444...222...  gggeeettt <<<rrreeemmmooottteee fffiiillleee>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]

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.


444...333...  hhhaaassshhh

A synonym for the vvveeerrrbbbooossseee 333 command.


444...444...  lllsss [[[<<<fffiiillleee>>>|||<<<dddiiirrreeeccctttooorrryyy>>> [[[<<<lllooocccaaalll fffiiillleee>>>]]]]]]

lllsss is identical to the dddiiirrr 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.


444...555...  mmmgggeeettt <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]]

Fetch a collection of files from the server. File names may include wild  card
characters;  they will be interpreted and expanded into a list of files by the
remote system using the NLST command. The files will have the same name on the
local system that they had on the server.


444...666...  mmmkkkdddiiirrr <<<rrreeemmmooottteee dddiiirrreeeccctttooorrryyy>>>

Creates a directory on the remote machine.


444...777...  mmmpppuuuttt <<<fffiiillleee>>> [[[<<<fffiiillleee>>> .........]]]  SSSeeennnddd aaa cccooolllllleeeccctttiiiooonnn ooofff fffiiillleeesss tttooo ttthhheee ssseeerrrvvveeerrr... FFFiiillleee
nnnaaammmeeesss  mmmaaayyy  iiinnncccllluuudddeee wwwiiilllddd cccaaarrrddd ccchhhaaarrraaacccttteeerrrsss;;; ttthhheeeyyy wwwiiillllll bbbeee eeexxxpppaaannndddeeeddd lllooocccaaallllllyyy iiinnntttooo aaa
llliiisssttt ooofff fffiiillleeesss tttooo bbbeee ssseeennnttt... TTThhheee fffiiillleeesss wwwiiillllll hhhaaavvveee ttthhheee sssaaammmeee nnnaaammmeee ooonnn ttthhheee  ssseeerrrvvveeerrr  aaasss
ooonnn ttthhheee lllooocccaaalll sssyyysssttteeemmm...


444...888...  pppuuuttt <<<lllooocccaaalll fffiiillleee>>> [[[<<<rrreeemmmooottteee fffiiillleee>>>]]]

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.







                                    - 26 -


The PORT and STOR commands are sent on the control channel.


444...999...  rrrmmmdddiiirrr <<<rrreeemmmooottteee dddiiirrreeeccctttooorrryyy>>>

Deletes a directory on the remote machine.


444...111000...  tttyyypppeee [[[aaa|||iii|||lll <<<bbbyyyttteeesssiiizzzeee>>>]]]

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
'i' means _i_m_a_g_e, i.e., binary.  In ASCII  mode,  files  are  sent  as  varying
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 different 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 is usually 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. bbbyyyttteeesssiiizzzeee is typically 8.  The type command sets the local
transfer mode and generates the TYPE command on the control channel.


444...111111...  vvveeerrrbbbooossseee [[[000|||111|||222|||333]]]

Set or display the level of message output in file transfers.  VVVeeerrrbbbooossseee 000 gives
the least output, and vvveeerrrbbbooossseee 333 the most, as follows:

0 - Display error messages only.
1 - Display error messages plus a one-line summary after each transfer
    giving the name of the file, its size, and the transfer time and rate.
2 - Display error and summary messages plus the progress messages generated
    by the remote FTP server. (This setting is the default.)
3 - Display all messages. In addition, a "hash mark" (#) is displayed for
    every 1,000 bytes sent or received.

If a command is sent to  the  remote  server  because  it  is  not  recognized
locally,  the  response  is  always  displayed,  regardless  of the setting of
vvveeerrrbbbooossseee.  This is necessary for commands like pppwwwddd (display working directory),
which would otherwise produce no message at all if vvveeerrrbbbooossseee were set to 0 or 1.


555...  AAAttttttaaaccchhh CCCooommmmmmaaannndddsss

This section details the attach commands for the  various  hardware  interface
drivers. Not all of these drivers may be configured into every net.exe binary;
a list of the available types may be obtained by entering the  command  aaattttttaaaccchhh
???.

Some parameters are accepted by several drivers. They are:









                                    - 27 -


555...111...  bbbuuufffsssiiizzzeee

For asynchronous devices (e.g., COM ports operating in SLIP or NRS mode)  this
parameter  specifies  the  size  of  the receiver's ring buffer.  It should be
large enough to hold incoming data at full line speed  for  the  longest  time
that  the  system may be busy in MS-DOS or the BIOS doing a slow I/O operation
(e.g., to a floppy disk). A kilobyte is usually more than sufficient.

For synchronous devices (e.g., the ssscccccc,,, hhhsss,,, pppccc111000000,,, hhhaaapppnnn  and  dddrrrsssiii  interfaces
operating  in  HDLC  mode), the bufsize parameter specifies the largest packet
that may be received on the interface.  This should be set by mutual agreement
among  stations sharing the channel. For standard AX.25 with a maximum I-frame
data size of 256 bytes, a value of  325  should  provide  an  adequate  safety
margin. On higher speed channels (e.g., 56kb/s) larger values (e.g., 2K bytes)
will provide much better performance and allow full-sized Ethernet packets  to
be carried without fragmentation.


555...222...  iiioooaaaddddddrrr

The base address of the interface's control registers, in hex.


555...333...  vvveeeccctttooorrr

The interface's hardware interrupt (IRQ) vector, in hex.


555...444...  iiifffaaaccceee

The name (an arbitrary character string) to be assigned to this interface.  It
is  used  to  refer  to the interface in iiifffaaaccceee and rrrooouuuttteee commands and in tttrrraaaccceee
output.


555...555...  mmmtttuuu

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 information field.  For  AX.25  I  frames,
however,  the  aaaxxx222555  pppaaacccllleeennn  parameter  is  also relevant.  If the datagram or
fragment is still larger than pppaaacccllleeennn, it is also fragmented at the AX.25 level
(as  opposed  to  the  IP  level)  before  transmission.  (See the aaaxxx222555 pppaaacccllleeennn
command for further information).


555...666...  aaattttttaaaccchhh 333ccc555000000 <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaarrrpppaaa <<<iiifffaaaccceee>>> <<<qqqllleeennn>>> <<<mmmtttuuu>>> [[[<<<iiippp___aaaddddddrrr>>>]]]

Attach a 3Com  3C501  Ethernet  interface.   qqqllleeennn  is  the  maximum  allowable
transmit  queue  length.   If  the  iiippp___aaaddddddrrr  parameter is not given, the value
associated with a prior iiippp aaaddddddrrreeessssss command will be used.

The use of this driver is not recommended; use  the  packet  driver  interface
with the loadable 3C501 packet driver instead.









                                    - 28 -


555...777...  aaattttttaaaccchhh aaasssyyy  <<<iiioooaaaddddddrrr>>>  <<<vvveeeccctttooorrr>>>  sssllliiippp|||aaaxxx222555|||nnnrrrsss  <<<iiifffaaaccceee>>>  <<<bbbuuufffsssiiizzzeee>>>  <<<mmmtttuuu>>>
<<<ssspppeeeeeeddd>>> [[[<<<ffflllaaagggsss>>>]]]

Attach a "com port" (asynchronous serial port).  Standard values on the IBM PC
and clones for iiioooaaaddddddrrr and vvveeeccctttooorrr are 0x3f8 and 4 for COM1, and 0x2f8 and 3 for
COM2. If the port uses a 16550A chip, it will be  detected  automatically  and
the FIFOs enabled.

Three operating modes are available:


555...777...111...  sssllliiippp

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.


555...777...222...  aaaxxx222555

Similar to sssllliiippp, 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
mmmooodddeee command for details.


555...777...333...  nnnrrrsss

Use the NET/ROM asynchronous framing technique for communication with a  local
NET/ROM TNC.


555...888...  aaattttttaaaccchhh dddrrrsssiii <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>>  <<<ccchhh___aaa___ssspppeeeeeeddd>>>
<<<ccchhh___bbb___ssspppeeeeeeddd>>>

Attach a Digital Radio Systems PCPA card. Since there are two channels on  the
board,  two interfaces are attached. They will be named iiifffaaaccceee with 'a' and 'b'
appended. bbbuuufffsssiiizzzeee is the receiver buffer size in bytes; it must be larger than
the largest frame to be received. ccchhh___aaa___ssspppeeeeeeddd and ccchhh___bbb___ssspppeeeeeeddd are the speeds, in
bits/sec, for the A and B channels, respectively.


555...999...  aaattttttaaaccchhh eeeaaagggllleee <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> <<<ssspppeeeeeeddd>>>

Attach an Eagle Computer 8530 interface card.


555...111000...  aaattttttaaaccchhh hhhaaapppnnn <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>> cccsssmmmaaa|||fffuuullllll

Attach a Hamilton Area Packet Network adapter using the Intel 8273 chip.   The
cccsssmmmaaa|||fffuuullllll parameter specifies whether the port should operate in carrier sense
multiple access (CSMA) mode or in full duplex.











                                    - 29 -


555...111111...  aaattttttaaaccchhh hhhsss <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<mmmtttuuu>>>  <<<kkkeeeyyyuuuppp___dddeeelllaaayyy>>>
<<<ppp>>>

Attach a DRSI PCPA or Eagle Computer interface  card  using  a  special  "high
speed"  driver. This driver uses busy-wait loops to send and receive each byte
instead of interrupts, making it usable with high  speed  (56kb/s)  modems  on
slow systems. This does have the side effect of "freezing" the system whenever
the modem transmitter or receiver is active.  This driver can operate only  in
CSMA  mode,  and  it  is  recommended that no other interfaces requiring small
interrupt latencies be attached to the same machine.

The kkkeeeyyyuuuppp___dddeeelllaaayyy parameter specifies the transmitter keyup delay in  byte  time
intervals.  The  ppp  value  specifies  the transmitter persistence value in the
range 1-255; the corresponding slot time is fixed at one hardware clock  tick,
about 55 ms on the PC.

As with the other 8530 drivers, this driver actually attaches two  interfaces,
one for each 8530 channel.


555...111222...  aaattttttaaaccchhh pppaaaccckkkeeettt <<<iiinnntttvvveeeccc>>> <<<iiifffaaaccceee>>> <<<tttxxxqqqllleeennn>>> <<<mmmtttuuu>>>

Attach a packet driver conforming to the  FTP  Software,  Inc,  Packet  Driver
Specification.  The  driver must have already been installed before the attach
command is given. Packet drivers in the Ethernet, ARCNET, SLIP, KISS/AX25  and
SLFP classes are supported.

iiinnntttvvveeeccc is the software interrupt vector used for communication to  the  packet
driver,  and  tttxxxqqqllleeennn  is the maximum number of packets that will be allowed on
the transmit queue.


555...111333...  aaattttttaaaccchhh pppccc111000000 <<<iiioooaaaddddddrrr>>> <<<vvveeeccctttooorrr>>> aaaxxx222555 <<<iiifffaaaccceee>>> <<<bbbuuufffsssiiizzzeee>>> <<<ssspppeeeeeeddd>>>

Attach a Paccomm PC-100 interface card. Only AX.25 operation is supported.


555...111444...  aaattttttaaaccchhh ssscccccc <<<dddeeevvviiiccceeesss>>> iiinnniiittt  <<<aaaddddddrrr>>>  <<<ssspppaaaccciiinnnggg>>>  <<<AAAoooffffff>>>  <<<BBBoooffffff>>>  <<<DDDaaatttaaaoooffffff>>>
<<<iiinnntttaaaccckkk>>> <<<vvveeeccc>>> [[[ppp]]]<<<cccllloooccckkk>>> [[[hhhdddwwweee]]] [[[pppaaarrraaammm]]]

Initialize a generic SCC (8530) interface board prior  to  actually  attaching
it. The parameters are as follows:


555...111444...111...  dddeeevvviiiccceeesss

The number of SCC chips to support.


555...111444...222...  aaaddddddrrr

The base address of the first SCC chip (hex).











                                    - 30 -


555...111444...333...  ssspppaaaccciiinnnggg

The spacing between the SCC chip base addresses.


555...111444...444...  AAAoooffffff

The offset from a chip's base address to its channel A control register.


555...111444...555...  BBBoooffffff

The offset from a chip's base address to its channel B control register.


555...111444...666...  DDDaaatttaaaoooffffff

The offset from each channel's control register to its data register.


555...111444...777...  iiinnntttaaaccckkk

The address of the INTACK/Read Vector port. If none, specify 0  to  read  from
RR3A/RR2B.


555...111444...888...  vvveeeccc

The CPU interrupt vector for all connected SCCs.


555...111444...999...  cccllloooccckkk

The clock frequency (PCLK/RTxC) of all SCCs in hertz.   Prefix  with  'p'  for
PCLK, 'r' for RTxC clock (for baudrate gen).


555...111444...111000...  hhhdddwwweee

Optional hardware type. The following values are  currently  supported:   1  -
Eagle  card,  2  -  PACCOMM  PC-100, 4 - PRIMUS-PC card (DG9BL), 8 - DRSI PCPA
card.


555...111444...111111...  pppaaarrraaammm

Optional extra parameter. At present, this is used only with  the  PC-100  and
PRIMUS-PC  cards to set the modem mode. The value 0x22 is used with the PC-100
and 0x2 is used with the PRIMUS-PC card.

The aaattttttaaaccchhh ssscccccc ......... iiinnniiittt command  must  be  given  before  the  interfaces  are
actually attached with the following command.











                                    - 31 -


555...111555...  aaattttttaaaccchhh ssscccccc <<<ccchhhaaannn>>> sssllliiippp|||kkkiiissssss|||nnnrrrsss|||aaaxxx222555 <<<iiifffaaaccceee>>>  <<<mmmtttuuu>>>  <<<ssspppeeeeeeddd>>>  <<<bbbuuufffsssiiizzzeee>>>
[[[cccaaallllll]]]

Attach an initialized SCC port to the system. The parameters are as follows:


555...111555...111...  <<<ccchhhaaannn>>>

The SCC channel number to attach, 0 or 1 for the first chip's A or B  port,  2
or 3 for the second chip's A or B port, etc.


555...111555...222...  sssllliiippp|||kkkiiissssss|||nnnrrrsss|||aaaxxx222555

The operating mode of the interface. sssllliiippp,,, kkkiiissssss and nnnrrrsss all operate  the  port
hardware  in asynchronous mode; sssllliiippp is Internet-standard serial line IP mode,
kkkiiissssss generates SLIP frames containing KISS TNC commands and AX.25 packets  and
nnnrrrsss  uses  NET/ROM  local  serial  link  framing  conventions to carry NET/ROM
packets. Selecting aaaxxx222555 mode puts the interface  into  synchronous  HDLC  mode
that is suitable for direct connection to a half duplex radio modem.


555...111555...333...  ssspppeeeeeeddd

The interface speed in bits per second, e.g., 1200.  Prefix with 'd'  when  an
external  divider is available to generate the TX clock. When the clock source
is PCLK, this can be a /32 divider between TRxC and RTxC. When the clock is at
RTxC,  the  TX  rate  must  be  supplied at TRxC. This is needed only for full
duplex synchronous operation. When this arg is given as  'ext',  the  transmit
and  receive  clocks  are external, and the internal baud rate generator (BRG)
and digital phase locked loop (DPLL) are not used.


555...111555...444...  AAAttttttaaaccchhh EEExxxaaammmpppllleeesss

Here are some examples of the attach command:

# 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

# Attach the packet driver loaded at interrupt 0x7e







                                    - 32 -


# The packet driver is for an Ethernet interface
attach packet 0x7e ethernet 8 1500

666...  TTThhheee ///ffftttpppuuussseeerrrsss FFFiiillleee

Since MS-DOS is a single-user  operating  system  (some  might  say  it  is  a
glorified  bootstrap  loader), it provides 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.  Net therefore provides
its own access control mechanisms.

The file ///ffftttpppuuussseeerrrsss controls remote FTP and mailbox access.  The FTP default is
_n_o  access;  if  this file does not exist, the FTP server will be unusable.  A
remote user must first "log in" to the system with the USER and PASS commands,
giving  a  valid  name  and password listed in ///ffftttpppuuussseeerrrsss, before he or she can
transfer files.

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

username password /path permissions

There must be exactly four fields, and there must be exactly one space between
each  field.   Comments may be added after the last field. Comment lines begin
with '#' in column one.

uuussseeerrrnnnaaammmeee is the user's login name.

pppaaasssssswwwooorrrddd 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.

///pppaaattthhh is the 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  the
allowable  path  prefix;  if  not,  the  operation is denied.  This field must
always begin with a "/", i.e., at the root directory.

pppeeerrrmmmiiissssssiiiooonnnsss 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 addition he may delete
files.  Again, all operations are allowed subject  to  the  path  name  prefix
restrictions.  Permissions may be combined by adding bits, for example, 0x3 (=
0x2 + 0x1) means that the user is given read and create  permission,  but  not
overwrite/delete permission.

For example, suppose ///ffftttpppuuussseeerrrsss on machine pc.ka9q.ampr.org contains the line

friendly test /testdir 7










                                    - 33 -


A session using this account would look like this:

net> ftp pc.ka9q.ampr.org
Resolving pc.ka9q.ampr.org... Trying 128.96.160.1...
FTP session 1 connected to pc.ka9q.ampr.org
220 pc.ka9q.ampr.org FTP version 900418 ready at Mon May 7 16:27:18 1990
Enter user name: friendly
331 Enter PASS command
Password: test [not echoed]
230 Logged in
ftp>

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 ///ffftttpppuuussseeerrrsss:

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

guest bletch /g/bogus 3 # User "guest" with password "bletch" may read
                        # any file under /g/bogus and its subdirectories,
                        # and may create a new file as long as it does
                        # not overwrite an existing file. He may NOT
                        # delete any files.

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

This last entry is the standard convention for keeping a repository of  public
files;  in  particular,  the  username  "anonymous"  is  an  established  ARPA
convention.


777...  TTThhheee ///dddooommmaaaiiinnn...tttxxxttt FFFiiillleee

_N_e_t translates domain names (e.g., "pc.ka9q.ampr.org") to IP addresses  (e.g.,
128.96.160.3)  through the use of an Internet Domain Name resolver and a local
"cache"  file,  ///dddooommmaaaiiinnn...tttxxxttt.  Whenever  the  user  specifies  a  domain  name,
///dddooommmaaaiiinnn...tttxxxttt  is first searched for the desired entry.  If it is present, it is
used; if not, and if domain name server(s) have been configured,  a  query  is
sent  over  the  network  to  the  current server. If the server responds, the
answer is appended to the ///dddooommmaaaiiinnn...tttxxxttt file for future use. If the server  does
not  respond,  any  additional servers on the list are tried indefinitely in a
round-robin fashion until one responds.  If ///dddooommmaaaiiinnn...tttxxxttt does not  contain  the
desired  entry  and  there  are  no  configured  domain name servers, then the
request immediately fails.

If a domain name server is available, and if all references to hostids in your
/aaauuutttoooeeexxxeeeccc...nnneeettt file are in IP address format, then it is possible to start with
a completely empty ///dddooommmaaaiiinnn...tttxxxttt file and have _n_e_t build it for  you.   However,
you may wish to add your own entries to ///dddooommmaaaiiinnn...tttxxxttt, either because you prefer
to use symbolic domain names in your /aaauuutttoooeeexxxeeeccc...nnneeettt  file  or  you  don't  have
access  to a domain server and you need to create entries for all of the hosts







                                    - 34 -


you may wish to access.  Each  entry  takes  one  line,  and  the  fields  are
separated by tabs. For example:

pc.ka9q.ampr.org. IN A 128.96.160.3

IIINNN is the _c_l_a_s_s of the record. It means _I_n_t_e_r_n_e_t, and it will be found in  all
entries.   AAA  is  the _t_y_p_e of the record, and it means that this is an _a_d_d_r_e_s_s
record.   Domain  name  pppccc...kkkaaa999qqq...aaammmppprrr...ooorrrggg  therefore   has   Internet   address
128.96.160.3.

Another possible entry is the CCCNNNAAAMMMEEE (Canonical Name) record, e.g.,

ka9q.ampr.org. IN CNAME pc.ka9q.ampr.org.

This says that domain name "ka9q.ampr.org" is actually an alias for the system
with  (primary,  or  _c_a_n_o_n_i_c_a_l) domain name "pc.ka9q.ampr.org."  When a domain
name having a CCCNNNAAAMMMEEE record is given to _n_e_t, the system  automatically  follows
the reference to the canonical name and returns the IP address associated with
that entry.

Entries added automatically by _n_e_t will have an additional field  between  the
domain name and the class (IIINNN) field, e.g.,

pc.ka9q.ampr.org. 3600 IN A 128.96.160.3

This is the  _t_i_m_e-_t_o-_l_i_v_e  value,  in  seconds,  associated  with  the  record
received  from  the  server.  Clients  (such as _n_e_t) caching these records are
supposed to delete them after the time-to-live interval has expired,  allowing
for the possibility that the information in the record may become out of date.
Cache expiration is not currently implemented in _n_e_t, but TTLs are recorded in
///dddooommmaaaiiinnn...tttxxxttt in anticipation of this feature. Since ///dddooommmaaaiiinnn...tttxxxttt is a plain text
file, it may be easily edited by the user to delete old records.

Additional types of records, include  NS  (name  server)  and  SOA  (start  of
authority)  may  appear in ///dddooommmaaaiiinnn...tttxxxttt from remote server responses. These are
not currently used by _n_e_t but are retained for future development (such as the
incorporation  of  a  domain  name  server into _n_e_t itself).  Server responses
indicating  that  a  given  record  does  not  exist  are  also  recorded   in
///dddooommmaaaiiinnn...tttxxxttt. These entries have empty value fields, e.g.,

foobar.ampr.org. 500 IN A

888...  SSSeeettttttiiinnnggg BBBuuufffsssiiizzzeee,,, PPPaaacccllleeennn,,, MMMaaaxxxfffrrraaammmeee,,, MMMTTTUUU,,, MMMSSSSSS aaannnddd WWWiiinnndddooowww

Many _n_e_t users are confused by these parameters and do not  know  how  to  set
them  properly.  This  section  will  first  review  these parameters and then
discuss how to choose values for them. Special emphasis is given  to  avoiding
interoperability  problems  that  may  appear  when communicating with non-_n_e_t
implementations of AX.25.


888...111...  HHHaaarrrdddwwwaaarrreee PPPaaarrraaammmeeettteeerrrsss











                                    - 35 -


888...111...111...  BBBuuufffsssiiizzzeee

This parameter is required by most of _n_e_t's built-in HDLC drivers (e.g., those
for the DRSI PCPA and the Paccomm PC-100). It specifies the size of the buffer
to be allocated for each receiver port. HDLC frames  larger  than  this  value
cannot be received.

There is no default bbbuuufffsssiiizzzeee; it must be specified in the  aaattttttaaaccchhh  command  for
the interface.


888...222...  AAAXXX222555 PPPaaarrraaammmeeettteeerrrsss


888...222...111...  PPPaaacccllleeennn

Paclen limits the size of the data field in an AX.25 I-frame. This value  does
_n_o_t  include  the  AX.25  protocol  header (source, destination and digipeater
addresses).

Since unconnected-mode (datagram) AX.25 uses UI frames, this parameter has  no
effect in unconnected mode.

The default value of pppaaacccllleeennn is 256 bytes.


888...222...222...  MMMaaaxxxfffrrraaammmeee

This parameter controls the number of I-frames that _n_e_t may send on  an  AX.25
connection  before  it  must  stop and wait for an acknowledgement.  Since the
AX.25/LAPB sequence number field is 3 bits wide, this number cannot be  larger
than 7.

Since unconnected-mode (datagram) AX.25  uses  UI  frames  that  do  not  have
sequence numbers, this parameter does _n_o_t apply to unconnected mode.

The default value of mmmaaaxxxfffrrraaammmeee in _n_e_t is 1 frame.


888...333...  IIIPPP aaannnddd TTTCCCPPP PPPaaarrraaammmeeettteeerrrsss


888...333...111...  MMMTTTUUU

The MTU (Maximum Transmission Unit) is an interface parameter that limits  the
size of the largest IP datagram that it may handle.  IP datagrams routed to an
interface that are larger than its  MTU  are  each  split  into  two  or  more
_f_r_a_g_m_e_n_t_s.   Each fragment has its own IP header and is handled by the network
as if it were a distinct IP datagram, but when it arrives at  the  destination
it  is  held by the IP layer until all of the other fragments belonging to the
original datagram have arrived.  Then  they  are  reassembled  back  into  the
complete,  original  IP  datagram.  The minimum acceptable interface MTU is 28
bytes: 20 bytes for the IP (fragment) header, plus 8 bytes of data.










                                    - 36 -


There is no default MTU in _n_e_t; it  must  be  explicitly  specified  for  each
interface as part of the aaattttttaaaccchhh command.


888...333...222...  MMMSSSSSS

MSS (Maximum Segment Size) is a TCP-level parameter that limits the amount  of
data  that  the  _r_e_m_o_t_e  TCP  will send in a single TCP packet. MSS values are
exchanged in the SYN (connection request) packets that open a TCP  connection.
In  the  _n_e_t  implementation  of  TCP, the MSS actually used by TCP is further
reduced in order to avoid fragmentation at the local IP  interface.  That  is,
the  local TCP asks IP for the MTU of the interface that will be used to reach
the destination. It then subtracts 40 from the MTU  value  to  allow  for  the
overhead  of  the  TCP  and  IP  headers.  If  the result is less than the MSS
received from the remote TCP, it is used instead.

The default value of MMMSSSSSS is 512 bytes.


888...333...333...  WWWiiinnndddooowww

This is a TCP-level parameter that controls how much data the local  TCP  will
allow   the  remote  TCP  to  send  before  it  must  stop  and  wait  for  an
acknowledgement. The actual window value used by TCP when  deciding  how  much
more data to send is referred to as the _e_f_f_e_c_t_i_v_e _w_i_n_d_o_w.  This is the smaller
of  two  values:  the  window  advertised  by  the  remote   TCP   minus   the
unacknowledged  data  in  flight,  and the _c_o_n_g_e_s_t_i_o_n _w_i_n_d_o_w, an automatically
computed time-varying estimate of how much data the network can handle.

The default value of WWWiiinnndddooowww is 2048 bytes.


888...444...  DDDiiissscccuuussssssiiiooonnn

888...444...111...  IIIPPP FFFrrraaagggmmmeeennntttaaatttiiiooonnn vvvsss AAAXXX...222555 SSSeeegggmmmeeennntttaaatttiiiooonnn

IP-level fragmentation often makes it possible to interconnect two  dissimilar
networks, but it is best avoided whenever possible.  One reason is that when a
single IP fragment is lost, all other fragments belonging to the same datagram
are effectively also lost and the entire datagram must be retransmitted by the
source.  Even without loss, fragments  require  the  allocation  of  temporary
buffer  memory  at the destination, and it is never easy to decide how long to
wait for missing fragments before giving up and  discarding  those  that  have
already  arrived.   A  reassembly  timer  controls this process.  In _n_e_t it is
(re)initialized with the iiippp rrrtttiiimmmeeerrr parameter  (default  30  seconds)  whenever
progress  is  made  in  reassembling  a  datagram  (i.e.,  a  new  fragment is
received).  It is not necessary that all  of  the  fragments  belonging  to  a
datagram  arrive  within  a  single  timeout  interval, only that the interval
between fragments be less than the timeout.

Most  subnetworks  that  carry  IP  have  MTUs  of  576  bytes  or  more,   so
interconnecting  them  with  subnetworks  having  smaller values can result in
considerable fragmentation. For this  reason,  IP  implementors  working  with
links  or  subnets having unusually small packet size limits are encouraged to
use _t_r_a_n_s_p_a_r_e_n_t _f_r_a_g_m_e_n_t_a_t_i_o_n, that is, to devise schemes to break up large IP
datagrams  into  a  sequence  of  link  or  subnet frames that are immediately







                                    - 37 -


reassembled on the other end of the link or subnet into the original, whole IP
datagram  without the use of IP-level fragmentation. Such a scheme is provided
in AX.25 Version 2.1.  It can break a large IP  or  NET/ROM  datagram  into  a
series  of pppaaacccllleeennn-sized AX.25 segments (not to be confused with TCP segments),
one per AX.25 I-frame, for transmission and  reassemble  them  into  a  single
datagram  at  the  other  end  of  the  link before handing it up to the IP or
NET/ROM module.  Unfortunately, the segmentation procedure is a new feature in
AX.25 and is not yet widely implemented; in fact, _n_e_t is so far the only known
implementation. This creates some interoperability problems  between  _n_e_t  and
non-_n_e_t  nodes,  in  particular, standard NET/ROM nodes being used to carry IP
datagrams. This problem is discussed further in the  section  on  setting  the
MTU.


888...444...222...  SSSeeettttttiiinnnggg pppaaacccllleeennn aaannnddd bbbuuufffsssiiizzzeee

The more data you put into an AX.25 I frame, the smaller the AX.25 headers are
in relation to the total frame size. In other words, by increasing pppaaacccllleeennn, you
lower the AX.25  protocol  overhead.  Also,  large  data  packets  reduce  the
overhead  of keying up a transmitter, and this can be an important factor with
higher speed modems. On the other hand, large frames make bigger  targets  for
noise  and interference. Each link has an optimum value of pppaaacccllleeennn that is best
discovered by experiment.

Another thing to remember when setting pppaaacccllleeennn is that the  AX.25  version  2.0
specification  limits  it  to  256  bytes. Although _n_e_t can handle much larger
values, some other AX.25 implementations (including  digipeaters)  cannot  and
this  may  cause  interoperability  problems.  Even  _n_e_t may have trouble with
certain KISS TNCs because of fixed-size buffers. The original  KISS  TNC  code
for the TNC-2 by K3MC can handle frames limited in size only by the RAM in the
TNC, but some other KISS TNCs cannot.

_N_e_t's built-in HDLC drivers (SCC, PC-100, DRSI, etc) allocate receive  buffers
according  to  the  maximum expected frame size, so it is important that these
devices be configured with the correct bbbuuufffsssiiizzzeee. To do this, you must know  the
size  of the largest possible frame that can be received. The pppaaacccllleeennn parameter
controls only the size of the data field in an I-frame and not the total  size
of  the  frame  as  it  appears  on  the  air.  The  AX.25 spec allows up to 8
digipeaters, so the largest possible frame is (pppaaacccllleeennn  +  72)  bytes.  So  you
should make bbbuuufffsssiiizzzeee at least this large.

Another important consideration is  that  the  more  recent  versions  of  NOS
improve interrupt response by maintaining a special pool of buffers for use by
the receive routines.  These buffers are currently fixed in size to 2048 bytes
and  this  can  be changed only by editing config.h and recompiling NOS.  This
limits bbbuuufffsssiiizzzeee; in fact, attempting to set a larger value may cause the driver
not  to  work  at  all.  This  situation can be detected by running the mmmeeemmmooorrryyy
ssstttaaatttuuusss command and looking for a non-zero count of IIIbbbuuuffffffaaaiiilll  events,  although
these events can also occur occasionally during normal operation.

One of the drawbacks of AX.25 that there is no way for  one  station  to  tell
another  how  large  a  packet  it  is  willing  to accept.  This requires the
stations sharing a channel to agree beforehand on a maximum packet size.   TCP
is different, as we shall see.









                                    - 38 -


888...444...333...  SSSeeettttttiiinnnggg MMMaaaxxxfffrrraaammmeee

For best performance on a half-duplex radio channel, mmmaaaxxxfffrrraaammmeee should always be
set  to  1.  The  reasons  are  explained  in  the  paper _L_i_n_k _L_e_v_e_l _P_r_o_t_o_c_o_l_s
_R_e_v_i_s_i_t_e_d by Brian Lloyd and Phil Karn, which appeared in the  proceedings  of
the ARRL 5th Computer Networking Conference in 1986.


888...444...444...  SSSeeettttttiiinnnggg MMMTTTUUU

TCP/IP header overhead considerations similar to those of the AX.25 layer when
setting  pppaaacccllleeennn apply when choosing an MTU.  However, certain subnetwork types
supported by _n_e_t have well-established MTUs, and these should always  be  used
unless  you know what you're doing: 1500 bytes for Ethernet, and 508 bytes for
ARCNET. Other subnet  types,  including  SLIP  and  AX.25,  are  not  as  well
standardized.  SLIP  has  no  official MTU, but the most common implementation
(for BSD UNIX) uses an MTU of 1006 bytes.  Although  _n_e_t  has  no  hard  wired
limit  on  the  size  of  a  received  SLIP  frame, this is not true for other
systems.  Interoperability problems may therefore result if  larger  MTUs  are
used in _n_e_t.

Choosing an MTU for an AX.25 interface is more  complex.  When  the  interface
operates in datagram (UI-frame) mode, the pppaaacccllleeennn parameter does not apply. The
MTU effectively becomes  the  pppaaacccllleeennn  of  the  link.   However,  as  mentioned
earlier,  large  packets sent on AX.25 _c_o_n_n_e_c_t_i_o_n_s are automatically segmented
into I-frames no larger than pppaaacccllleeennn bytes.  Unfortunately, as  also  mentioned
earlier,  _n_e_t  is  so  far  the  only  known  implementation  of the new AX.25
segmentation procedure. This is fine as long as all of the NET/ROM nodes along
a  path  are running _n_e_t, but since the main reason _n_e_t supports NET/ROM is to
allow use of existing NET/ROM networks, this is unlikely.

So it is usually important to avoid AX.25 segmentation when  running  IP  over
NET/ROM.   The  way to do this is to make sure that packets larger than pppaaacccllleeennn
are never handed to AX.25.  A NET/ROM transport header is 5 bytes long  and  a
NET/ROM  network  header takes 15 bytes, so 20 bytes must be added to the size
of an IP datagram when figuring the size of the AX.25 I-frame data  field.  If
pppaaacccllleeennn  is 256, this leaves 236 bytes for the IP datagram. This is the default
MTU of the nnneeetttrrrooommm pseudo-interface, so as long  as  pppaaacccllleeennn  is  at  least  256
bytes,  AX.25  segmentation  can't happen. But if smaller values of pppaaacccllleeennn are
used, the nnneeetttrrrooommm MTU must also be reduced with the iiifffcccooonnnfffiiiggg command.

On the other hand, if you're running IP directly on top of AX.25, chances  are
all of the nodes are running _n_e_t and support AX.25 segmentation.  In this case
there is no reason not to use a larger MTU and let AX.25 segmentation  do  its
thing.  If  you choose an MTU on the order of 1000-1500 bytes, you can largely
avoid IP-level fragmentation and reduce TCP/IP-level header overhead  on  file
transfers to a very low level.  And you are still free to pick whatever pppaaacccllleeennn
value is appropriate for the link.


888...444...555...  SSSeeettttttiiinnnggg MMMSSSSSS

The setting of this TCP-level parameter is somewhat less critical than the  IP
and   AX.25   level   parameters  already  discussed,  mainly  because  it  is
automatically lowered according to the MTU  of  the  local  interface  when  a
connection  is  created.  Although  this  is,  strictly  speaking,  a protocol







                                    - 39 -


layering violation (TCP is not supposed to have any knowledge of the  workings
of  lower  layers) this technique does work well in practice.  However, it can
be fooled; for example, if a routing change occurs after  the  connection  has
been  opened  and  the new local interface has a smaller MTU than the previous
one, IP fragmentation may occur in the local system.

The only drawback to setting a large MSS is  that  it  might  cause  avoidable
fragmentation  at  some  other  point within the network path if it includes a
"bottleneck" subnet with an MTU smaller than  that  of  the  local  interface.
(Unfortunately,  there  is  presently  no  way  to know when this is the case.
There is ongoing work within the Internet Engineering Task  Force  on  a  "MTU
Discovery" procedure to determine the largest datagram that may be sent over a
given path without fragmentation, but it is not yet  complete.)   Also,  since
the  MSS  you  specify is sent to the remote system, and not all other TCPs do
the MSS-lowering procedure yet, this might cause the remote system to generate
IP fragments unnecessarily.

On the other hand, a too-small MSS can result in  a  considerable  performance
loss,  especially  when  operating over fast LANs and networks that can handle
larger packets. So the best value for MSS is probably 40 less than the largest
MTU  on  your  system,  with  the  40-byte  margin allowing for the TCP and IP
headers. For example, if you have a SLIP interface with a 1006 byte MTU and an
Ethernet  interface  with  a 1500 byte MTU, set MSS to 1460 bytes. This allows
you to receive maximum-sized Ethernet  packets,  assuming  the  path  to  your
system does not have any bottleneck subnets with smaller MTUs.


888...444...666...  SSSeeettttttiiinnnggg WWWiiinnndddooowww

A sliding window protocol like TCP cannot  transfer  more  than  one  window's
worth  of  data  per  round  trip  time  interval. So this TCP-level parameter
controls the ability of the remote TCP to keep a long "pipe"  full.  That  is,
when  operating  over  a path with many hops, offering a large TCP window will
help keep all those hops busy when you're receiving data. On the  other  hand,
offering  too  large  a window can congest the network if it cannot buffer all
that data. Fortunately, new algorithms for dynamic controlling  the  effective
TCP  flow  control  window have been developed over the past few years and are
now widely deployed. _N_e_t includes them, and you can watch them in action  with
the  tttcccppp  ssstttaaatttuuusss  <<<tttcccbbb>>>  or  sssoooccckkkeeettt  <<<sssoooccckkknnnooo>>>  commands.   Look  at  the cccwwwiiinnnddd
(congestion window) value.

In most cases it is safe to set the TCP window to a small integer multiple  of
the   MSS,  e.g.,  4x,  or  larger  if  necessary  to  fully  utilize  a  high
bandwidth*delay product path. One thing to keep  in  mind,  however,  is  that
advertising  a certain TCP window value declares that the system has that much
buffer space available for incoming data. _N_e_t does  not  actually  preallocate
this  space;  it  keeps  it  in  a  common  pool  and  may well "overbook" it,
exploiting the fact that many TCP connections are idle for  long  periods  and
gambling  that  most  applications  will  read  incoming  data  from an active
connection as soon as it arrives, thereby quickly freeing the  buffer  memory.
However, it is possible to run _n_e_t out of memory if excessive TCP window sizes
are advertised and either the applications go  to  sleep  indefinitely  (e.g.,
suspended  Telnet  sessions)  or a lot of out-of-sequence data arrives.  It is
wise to keep an eye on the amount of available memory and to decrease the  TCP
window  size  (or limit the number of simultaneous connections) if it gets too
low.







                                    - 40 -


Depending on the channel access method and link level protocol, the use  of  a
window  setting  that  exceeds  the  MSS  may  cause  an  increase  in channel
collisions. In particular,  collisions  between  data  packets  and  returning
acknowledgements  during a bulk file transfer may become common. Although this
is, strictly speaking, not TCP's fault, it is  possible  to  work  around  the
problem  at  the  TCP  level  by  decreasing  the  window so that the protocol
operates in stop-and-wait mode.  This is done by making the window value equal
to the MSS.


888...555...  SSSuuummmmmmaaarrryyy

In most cases, the default values provided by _n_e_t for each of these parameters
will   work  correctly  and  give  reasonable  performance.  Only  in  special
circumstances such as operation over a very poor link or experimentation  with
high speed modems should it be necessary to change them.