HAM Radio 3/hamradioversion3.0examsandprograms1992.iso/tcp/nosdoc/nos.doc

Text File | 1990-12-13 | 205KB | 4,620 lines

                                 USERREF.NOS










                           Network Operating System
                            User Reference Manual


                               Phil Karn, KA9Q
                                     and
                        Gerard van der Grinten, PA0GRI






1.  The NOS.EXE Program

The MS-DOS executable file  nos.exe  provides Internet (TCP/IP), NET/ROM and
AX.25 facilities. Because it has an internal multitasking operating system,
nos.exe 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.

1.1.  Startup

When  nos.exe  is executed without arguments, it attempts to open the file
autoexec.nos  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  nos.exe
is invoked with an argument, it is taken to be the name of an alternate
startup file to be read instead of  autoexec.nos.

Four command-line options are accepted:

1.1.1.  -s

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

1.1.2.  -d

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

1.1.3.  -m

The -m option tells nos how much RAM to grab from MS-DOS for its internal
heap. It defaults to 200K. On a 640K system, this is usually enough to run a
subshell and some smaller commands. If you don't need to run subcommands and
prefer to allocate as much memory as possible to nos, you can specify a large
number (e.g., 1000) to the -m option and nos will grab as much memory as it
can.

1.1.4.  -t

The -t option allows the user to trace command execution during the startup of
nos. It lets the commands read from autoexec.nos echo before they are
executed. This is a nice help if nos stops (hangs) during initialization.

2.  Console modes

The console may be in one of two modes: command mode and converse mode. In
command mode, the prompt net> is displayed and any of the commands described
in the next section may be entered. In converse mode, keyboard input is
processed according to the current session. Sessions come in eight types:
Telnet, FTP, AX25, NETROM, Ping, More, Hopcheck and Tip.

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 FTP Subcommands).
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 cooked and raw states. In cooked state, input is
line-at-a-time; the user may use the line editing characters ^U, ^R and
backspace to erase the line, redisplay the line and erase the last character,
respectively. Hitting either return or line feed passes the complete line up
to the application. In raw mode, each character is immediately passed to the
application as it is typed. The keyboard is always in cooked state in command
mode. It is also cooked in converse mode on an AX25, 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 echo 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 escape character, which is by
default control-] (hex 1d, ASCII GS). (Note that this is distinct from the
ASCII character of the same name). The escape character can be changed (see
the escape command).

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.

3.  Commands

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

        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 <hostid> denotes an actual host or
gateway, which may be specified in one of two ways: as a symbolic name listed
in the file /domain.txt, 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 nos, it will be queried if the name isn't found in
/domain.txt.

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., put, get, dir, etc, are recognized only in
converse mode with the appropriate FTP session; they are not recognized in
command mode.

3.1.  <cr>

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

3.2.  !

An alias for the shell command.

3.3.  #

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

3.4.  abort [<session #>]

Abort a FTP get, put or dir operation in progress. If issued without an
argument, the current session is aborted. (This command works only on FTP
sessions.) When receiving a file, abort 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, abort sends a premature
end-of-file. Note that in both cases abort will leave a partial copy of the
file on the destination machine, which must be removed manually if it is
unwanted.

3.5.  arp

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.

3.5.1.   arp add <hostid> ethernet|ax25 <ethernet address>|<ax25_address>

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

3.5.2.   arp publish <hostid> ethernet|ax25 <ethernet address>|<ax25_address>

The  arp publish  command is similar to the  arp add  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.)

3.5.3.  arp drop <hostid> ax25|ethernet

Remove the specified entry from the ARP table.

3.5.4.  arp flush

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

3.5.5.  asystat

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 trigger character 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 high water mark. The high water mark is the
maximum number of characters ever read from the device during a single
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.)

3.6.  attach <hw type> ...

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

3.6.1.  asy

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

3.6.2.  drsi

N6TTO driver for the DRSI PCPA 8530 card.

3.6.3.  eagle

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

3.6.4.  hapn

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

3.6.5.  hs

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

3.6.6.  packet

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

3.6.7.  pc100

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

3.6.8.  scc

PE1CHL driver for generic 8530 cards.

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

3.7.  ax25 <subcommand>

Ax25 subcommands are:

3.7.1.  ax25 blimit [<val>]

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 binary exponential backoff. 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.

3.7.2.  ax25 digipeat [on|off]

Display or set the digipeater enable flag.

3.7.3.  ax25 flush

Clear the AX.25 "heard" list (see ax25 heard).

3.7.4.  ax25 heard

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.

3.7.5.  ax25 irtt [<val>]

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.

3.7.6.  ax25 kick <axcb>

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

3.7.7.  ax25 maxframe [<val>]

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.

3.7.8.  ax25 mycall [<call>]

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

3.7.9.  ax25 paclen [<val>]

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.

3.7.10.  ax25 pthresh [<val>]

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

3.7.11.  ax25 reset <axcb>

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

3.7.12.  ax25 retry [<val>]

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 retry times, then the connection is abandoned and all
queued data is deleted.

3.7.13.  ax25 route

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

3.7.14.  ax25 route add <target> [digis ... ]

Add an entry to the AX.25 routing table. An automatic ax255 route add is
executed if digipeaters are specified in an AX25 connect 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.

3.7.15.  ax25 route drop <target>

Drop an entry from the AX.25 routing table.

3.7.16.  ax25 status [<axcb>]

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.

3.7.17.  ax25 t3 [<val>]

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

3.7.18.  ax25 version [1|2]

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

3.7.19.  ax25 window [<val>]

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.

3.8.  bbs

Enter the local bbs port (same as a telnet session to your own station).

3.9.  cd [<dirname>]

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

3.10.  close [<session #>]

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 reset
command, in that it is less likely to leave the remote TCP in a "half-open"
state.

3.11.  connect <iface> <callsign> [<digipeater> ... ]

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  via  is NOT
needed. If digipeaters are specified, they are automatically added to the AX25
routing table as though the ax25 route add command had been given before
issuing the connect command.

3.12.  detach <iface>

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.

3.13.  dir [<dirname>]

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 more session
to display it. After this completes, the temporary file is deleted.

3.14.  disconnect [<session #>]

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

3.15.  domain addserver <hostid> [<hostid> ...]

Add one or more domain name server(s) to the  list  of  name servers.   If
the <hostid> is the ip address of this system the domain name server is
started to listen for queries from other hosts. Note that in the /autoexec.nos
file the ip address command should be before this command.

3.16.  domain dropserver <hostid> [<hostid> ...]

Remove one or more domain name server(s) from  the  list  of name  servers.
You are warned when you delete the last name server.

3.17.  domain listservers

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.

3.18.  domain suffix [<domain suffix>]

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
ampr.org. and the user enters telnet ka9q, the domain resolver will attempt to
find ka9q.ampr.org. If the host name being sought contains one or more
periods, however, the default suffix is NOT applied; e.g., telnet foo.bar
would NOT be turned into foo.bar.ampr.org. Note that a trailing dot (.) is
required for the suffix.

3.19.  domain trace [on|off]

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, ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt.

3.20.  domain debug [on|off]

Display or set the flag controlling the extended tracing  of
the domain software internals.

3.21.  domain loopback [on|off]

Display or set the flag controlling  the  internal  loopback
capability of the domain software. This is only usefull when
the local system is an domain server.

3.22.  domain load [<filename>]

Loads the file <filename> or if  <filename>  not  given  the
standard  ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt  file  into memory as a fast database.
Note that if too many records are read into memory you  will
get  into  problems  with  memory shortage soner or later. A
good compromise I found is around 400 records. That is prob-
ably more stations as you can reach.

3.23.  domain bootp <server> [<filename>]

This is for "mountain top" stations where no disk  space  is
available  for  keeping  a  oooommmmaaaaiiiinnnn....ttttxxxxtttt  file.  It sends out a
request to <server> to send all records in his  <file>.  (by
default /domain.txt).  All records received will be added to
the memory database. No disk access for  a  domain  file  is
made.   The   <server>   address   needs   to  be  given  in
[xx.xx.xx.xx] format as the software assumes  it  could  not
resolve a symbolic name yet.

3.24.  domain nslookup <server> <type> <record>

A domain query is send  out  to  <server>  for  record  type <type> and name
<record>.  The <type> can be a standard type (A , CNAME, WKS) or an integer
value (1..255) where  255  is TYPE_ANY.  (all  types referencing <record>.
Record <record> is where is sought for. Note that the answer to  this  query
is NOT added to the database (domain.txt or memory based).

3.25.  domain retries value

Sets the number of domain  query  retries  for  a  paticular request.
Default  is  0.  This means after an request to a server is timed out no
further requests will be send out. If you can reach more than one server set
this parameter acord- ingly so that more than one server  can  be  queried
before giving up.

3.26.  domain timeout value

This sets a timeout value (1 to 255 seconds) to a  query  or domain  name
server.  This is not set for a already defined server but will be used for a
newly  defined  name  server.

Also the value is used for domain nslookups.  Note that name servers can have
(PC based) trouble finding  records  in  an large database. The default is set
to 30 seconds.

3.27.  domain save <filename>

This command  saves  all  records  (except  A  records  with 0.0.0.0)  onto
file  <filename>  from the memory data base.  Records are grouped  by  origin.
If  there  where  answered queries , this is a way to save them.

3.28.  echo [accept|refuse]

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 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  eeeecccchhhhoooo
aaaacccccccceeeepppptttt  is in effect, a client Telnet session will automati-
cally return a DO ECHO response. In this mode, local echoing
and  editing  is  turned  off  and  each  key stroke is sent
immediately (subject to  the  Nagle  tinygram  algorithm  in
TCP).   While  this mode is just fine across an Ethernet, it
is clearly inefficient and painful across  slow  paths  like
packet  radio  channels.  Specifying  eeeecccchhhhoooo  rrrreeeeffffuuuusssseeee 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 ssssttttttttyyyy ----eeeecccchhhhoooo command to
the shell once you have logged in.)

3.29.  eol [unix|standard]

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.

3.30.  escape [<char>]

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

3.31.  etherstat

Display 3-Com Ethernet  controller  statistics  (if  config- ured).

3.32.  exit

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

3.33.  finger <user@hostid> [<user@hostid> ...]

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

3.34.  ftp <hostid>

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  FFFFTTTTPPPP  SSSSuuuubbbbccccoooommmmmmmmaaaannnnddddssss  for  descriptions of the commands
available in an FTP session.

3.35.  help

Display a brief summary of top-level commands.

3.36.  hop check <hostid>

Initiate a hhhhooooppppcccchhhheeeecccckkkk 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 ttttrrrraaaacccceeeerrrroooouuuutttteeee facility.

ICMP message tracing should be turned off before  this  com-
mand is executed (see the iiiiccccmmmmpppp ttttrrrraaaacccceeee command).

3.37.  hop maxttl [<ttl>]

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

3.38.  hop maxwait [<time>]

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

3.39.  hop queries [<count>]

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

3.40.  hop trace [on|off]

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

3.41.  hostname [<name>]

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.

3.42.  hs

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

3.43.  icmp echo [on|off]

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 ppppiiiinnnngggg command.)

3.44.  icmp status

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

3.45.  icmp trace [on|off]

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 hhhhooooppppcccchhhheeeecccckkkk facility because it relies on  ICMP  Time
Exceeded  messages,  and  the  asynchronous display of these
messages will be mingled with hop check command output.

3.46.  ip address [<hostid>]

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.

3.47.  ip rtimer [<val>]

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

3.48.  ip status

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

3.49.  ip ttl [<val>]

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.

3.50.  log [stop|<file>]

Display or set the file name for logging server sessions. If
ssssttttoooopppp  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.

3.51.  mbox

Display the status of the mailbox server system (if  config- ured).

3.52.  memory free

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

3.53.  memory sizes

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

3.54.  memory status

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  statis- tics  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  exhaus- tion of the pool.

3.55.  mode <iface> [vc|datagram]

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

In vvvvcccc (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 cir-
cuit 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 ppppaaaacccclllleeeennnn parameter. In AX.25 frag-
mentation,  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).

3.56.  more <file> [<file> ...]

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 mmmmoooorrrreeee command creates  a  ses-
sion  that  you  can  suspend and resume just like any other
session.

3.57.  nntp <subcommand>

Network news transfer protocol  has  the  following  subcom- mands:

3.57.1.  nntp addserver  <nntpserver>  <interval>  [<range>]
[<groups>]

Add a nntp news server to quiry every interval for new arti- cles  specified
by  the nntp groups command. Range can be a limit in time to query like nntp
addserver  someserver  600 22:00-23:00  To only query between 10 and 11pm
Multiple nntp add can be used co concatenate groups (up to 512 bytes)

3.57.2.  nntp directory <directory>

Show or set default directory for spooling  news.   This  is not the control
directory but the (alternate) place to spool articles to.

3.57.3.  nntp dropserver <nntpserver>


3.57.4.  nntp groups <group> [<group> ...]

Set or display currently set newsgroups.

3.57.5.  nntp  kick <nntpserver>

Kick the client to get in touch with the named server.

3.57.6.  nntp listservers

Lists the curently defined servers.

3.58.  nntp trace <level>

Sets or shows the current trace level for the  nntp  client.  0  No  tracing
1  (default)  displays  serious  errors.   2 displays as 1 and transient
errors.  3  displays  as  2  and session  progress.   4   displays  as  3 and
actual received articles.  5  displays errors.

3.59.  param <iface> [<param> ...]

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, ppppaaaarrrraaaammmm aaaaxxxx0000 1111  222255555555
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.

3.60.  ping <hostid> [<len> [<interval> [<incflag>]]]

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  lllleeeennnnggggtttthhhh
argument  is  given,  the  appropriate  number of data bytes
(consisting of hex 55) are added to the ping packets.

If iiiinnnntttteeeerrrrvvvvaaaallll is specified, pings will  be  repeated  indefin-
itely  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 iiiinnnnccccffffllllaaaagggg 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.

3.61.  pop mailbox [<name>]

Show or sets the name to <name> for POP mail queries to  the mailhost.

3.62.  pop mailhost [<name>]

Show or sets the IP address to the system named  <name>  for POP connections.

3.63.  pop kick

Start a POP connection now. (one shot connection)

3.64.  pop timer [<seconds>]

Show or start a POP connection every <seconds>  to  transfer mail.

3.65.  pop userdata <name> <password>

Sets up the userdata used for validation on the  POP  server system.  Note
that <name> and <password> are case sensitive.  When only pop userdata is
entered to show  the  values  only the  <name>  is  shown.  (ultimate in
security, if you realy want to see the password look in the "ether").

3.66.  ps

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

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

SSSSPPPP - The current value of the process stack pointer.

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

mmmmaaaaxxxxssssttttkkkk - The apparent peak stack utilization  of  this  pro-
cess.  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 nos
program should  be  recompiled  to give the process a larger allocation when
it is started.

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

ffffllll - 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  exe-
cuted  a  pwait()  call (wait for event) without first disa-
bling 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
eeeevvvveeeennnntttt column will be non-blank. Note that although there may
be  several  runnable processes at any time (shown in the ppppssss
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 ppppssss com-
mand  is  always  the  one running when this display is gen-
erated.)

3.67.  pwd [<dirname>]

An alias for the ccccdddd command.

3.68.  record [<filename>|off]

Append to ffffiiiilllleeeennnnaaaammmmeeee 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 rrrreeeeccccoooorrrrdddd ooooffffffff stops recording and closes the file.

3.69.  remote [-p <port>] [-k <key>] [-a  <kickaddr>]  <hos-
tid> exit|reset|kick

Send a UDP packet to the specified  host  commanding  it  to
exit  the  nos  program,  reset  the  processor,  or force a
retransmission on TCP connections.  For this command  to  be
accepted,  the  remote  system  must  be  running the rrrreeeemmmmooootttteeee
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.

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  speci- fied  host  are  kicked  instead. No key is
required for the kick subcommand.

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

        :loop
        nos
        goto :loop

3.70.  -s <key>

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

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

3.71.  rename <file1> <file2>

Rename ffffiiiilllleeee1111 to ffffiiiilllleeee2222.

3.72.  reset [<session>]

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

3.73.  rip accept <gateway>

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

3.74.  rip add <hostid> <interval> [<flags>]

Add an entry to the RIP  broadcast  table.  The  IP  routing
table  will  be  sent  to  hhhhoooossssttttiiiidddd every iiiinnnntttteeeerrrrvvvvaaaallll seconds. If
ffffllllaaaaggggssss 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 rout- ing table entries except those marked "private"
will 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 desti- nation 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 neces-
sary  IP routing table entry, but unusual subnet or cluster-
addressed networks may require special attention.   However,
an  aaaarrrrpppp  aaaadddddddd  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.

3.75.  rip drop <dest>

Remove an entry from the RIP broadcast table.

3.76.  rip merge [on|off]

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  tar- get addresses of
the less specific entry and the two entries must have the same interface and
gateway fields.  For  exam- ple, 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.

3.77.  rip refuse <gateway>

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 rrrriiiipppp aaaacccccccceeeepppptttt command.

3.78.  rip request <gateway>

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

3.79.  rip status

Display RIP status, including a count of the number of pack- ets 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.

3.80.  rip trace [0|1|2]

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 out- put. Setting the variable  to  2  produces  maximum  output,
including tracing of RIP packets that cause no change in the routing table.

3.81.  rlogin host

Sets up an rlogin session via port 511 to an *NIX compatible station.   Defaut
terminal  is a vt100 (as defined with the fkeys) compatible terminal.

3.82.  route

With no arguments, rrrroooouuuutttteeee displays the IP routing table.

3.83.   route   add   <dest_hostid>[/bits]|default   <iface>
[<gateway_hostid> [<metric>]]

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

The optional ////bbbbiiiittttssss suffix to the destination host id  speci-
fies  how  many  leading  bits in the host id are to be con-
sidered 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 com-
mand

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


3.84.  route addprivate <dest hostid>[/bits]|default <iface>
[<gateway hostid> [<metric>]]

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

_3._8_5.  _r_o_u_t_e _d_r_o_p <_d_e_s_t _h_o_s_t_i_d>

rrrroooouuuutttteeee ddddrrrroooopppp 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.

_3._8_6.  _s_e_s_s_i_o_n [<_s_e_s_s_i_o_n #>]

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  ses-
sion.   Entering a session number as an argument to the ses- sion command
will  put  you  in  converse  mode  with  that session.  If the Telnet server
is enabled, the user is noti- fied of an incoming request and a session number
is automat- ically  assigned.  The user may then select the session nor- mally
to converse with the remote user as though the session had been locally
initiated.

_3._8_7.  _s_h_e_l_l

Suspends _n_o_s and executes a sub shell  ("command  processor"
under MS-DOS).  When the sub shell exits, _n_o_s resumes (under
MS-DOS, enter the eeeexxxxiiiitttt 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 ----ffff option to nnnnoooossss....eeeexxxxeeee).

_3._8_8.  _s_m_t_p _g_a_t_e_w_a_y [<_h_o_s_t_i_d>]

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.

_3._8_9.  _s_m_t_p _k_i_c_k

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

_3._9_0.  _s_m_t_p _m_a_x_c_l_i_e_n_t_s [<_v_a_l>]

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.

_3._9_1.  _s_m_t_p _t_i_m_e_r [<_v_a_l>]

Displays or sets the interval, in seconds, between scans  of
the  outbound  mail  queue. For example, ssssmmmmttttpppp ttttiiiimmmmeeeerrrr 666600000000 will
cause the system to check for outgoing mail every 10 minutes
and  attempt to deliver anything it finds, subject of course
to the ssssmmmmttttpppp mmmmaaaaxxxxcccclllliiiieeeennnnttttssss limit. Setting a value of  zero  dis-
ables  queue  scanning  altogether,  note  that  this is the
default!  This value is recommended for stand alone IP gate- ways that never
handle mail, since it saves wear and tear on the floppy disk drive.

_3._9_2.  _s_m_t_p _t_r_a_c_e [<_v_a_l>]

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.

_3._9_3.  _s_o_c_k_e_t [<_s_o_c_k_e_t #>]

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 ttttccccpppp ssssttttaaaattttuuuussss command with  the  protocol  control
block address.

_3._9_4.                                                  _s_t_a_r_t
_a_x_2_5|_d_i_s_c_a_r_d|_e_c_h_o|_f_i_n_g_e_r|_f_t_p|_n_e_t_r_o_m|_r_e_m_o_t_e|_p_o_p|_s_m_t_p|_t_e_l_n_e_t|_t_t_y_l_i_n_k

Start the specified Internet server, allowing remote connec- tion requests.

_3._9_5.                                                   _s_t_o_p
_a_x_2_5|_d_i_s_c_a_r_d|_e_c_h_o|_f_i_n_g_e_r|_f_t_p|_n_e_t_r_o_m|_r_e_m_o_t_e|_p_o_p|_s_m_t_p|_t_e_l_n_e_t|_t_t_y_l_i_n_k

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

_3._9_6.  _t_c_p _i_r_t_t [<_v_a_l>]

Display or set the initial round trip time estimate, in mil- liseconds, 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. When-
ever 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).

_3._9_7.  _t_c_p _k_i_c_k <_t_c_b__a_d_d_r>

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

_3._9_8.  _t_c_p _m_s_s [<_s_i_z_e>]

Display or set the TCP Maximum Segment Size  in  bytes  that will  be  sent on
all outgoing TCP connect request (SYN seg- ments).  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.

_3._9_9.  _t_c_p _r_e_s_e_t <_t_c_b__a_d_d_r>

Deletes the TCP control block at the specified address.

_3._1_0_0.  _t_c_p _r_t_t <_t_c_b__a_d_d_r> <_r_t_t_v_a_l>

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

_3._1_0_1.  _t_c_p _s_t_a_t_u_s [<_t_c_b__a_d_d_r>]

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 ttttccccbbbb____aaaaddddddddrrrr is specified, a
more detailed  dump  of  the  specified  TCB  is  generated,
including send and receive sequence numbers and timer infor- mation.

_3._1_0_2.  _t_c_p _w_i_n_d_o_w [<_v_a_l>]

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

_3._1_0_3.  _t_e_l_n_e_t <_h_o_s_t_i_d> [<_p_o_r_t>]

Creates a Telnet session to the specified  host  and  enters converse  mode.
If  <port>  is  given that number is used.  Default port is 23.

_3._1_0_4.  _t_t_y_l_i_n_k <_h_o_s_t_i_d> [<_p_o_r_t>]

Creates a Telnet session to the specified  host  and  enters converse  mode.
If  <port>  is  given that number is used.  Default port is 87.  This uses a
split screen interface  for easy conversation.

_3._1_0_5.  _t_i_p <_i_f_a_c_e>

Creates a ttttiiiipppp session that connects to the specified  inter-
face  in  "dumb  terminal"  mode.   The  interface must have
already been attached with the aaaattttttttaaaacccchhhh command.   Any  packet
traffic  (IP  datagrams,  etc) routed to the interface while
this session exists will be discarded.  To close a ttttiiiipppp  ses-
sion,  use  the rrrreeeesssseeeetttt command. It will then revert to normal
sssslllliiiipppp,,,, nnnnrrrrssss or kkkkiiiissssssss 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.

_3._1_0_6.  _t_r_a_c_e [<_i_f_a_c_e> [<_f_l_a_g_s> [<_t_r_a_c_e_f_i_l_e>]]]

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, ttttrrrraaaacccceeee 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:

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 ttttrrrraaaacccceeeeffffiiiilllleeee is not specified, tracing will be to  the  con-
sole.

_3._1_0_7.  _u_d_p _s_t_a_t_u_s

Displays the status of all UDP receive queues.

_3._1_0_8.  _u_p_l_o_a_d [<_f_i_l_e_n_a_m_e>]

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

_3._1_0_9.  _w_a_t_c_h

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_o_s usually has no stopwatch calls.

_3._1_1_0.  ?

Same as the hhhheeeellllpppp command.

_4.  _F_T_P _S_u_b_c_o_m_m_a_n_d_s

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

_4._1.  _d_i_r [<_f_i_l_e>|<_d_i_r_e_c_t_o_r_y> [<_l_o_c_a_l _f_i_l_e>]]

Without arguments, ddddiiiirrrr requests that a full directory  list-
ing  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 subdirec- tory 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.

_4._2.  _g_e_t <_r_e_m_o_t_e _f_i_l_e> [<_l_o_c_a_l _f_i_l_e>]

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.

_4._3.  _l_s [<_f_i_l_e>|<_d_i_r_e_c_t_o_r_y> [<_l_o_c_a_l _f_i_l_e>]]

llllssss is identical to the ddddiiiirrrr 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.

_4._4.  _m_k_d_i_r <_r_e_m_o_t_e _d_i_r_e_c_t_o_r_y>

Creates a directory on the remote machine.

_4._5.  _p_u_t <_l_o_c_a_l _f_i_l_e> [<_r_e_m_o_t_e _f_i_l_e>]

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;  other- wise  it  will  have  the same name as on the
local machine.  The PORT and STOR commands are sent on the control channel.

_4._6.  _r_m_d_i_r <_r_e_m_o_t_e _d_i_r_e_c_t_o_r_y>

Deletes a directory on the remote machine.

_4._7.  _t_y_p_e [_a|_i|_l <_b_y_t_e_s_i_z_e>]

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  transfer-
ring 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  usu-
ally  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. bbbbyyyytttteeeessssiiiizzzzeeee is typically 8.  The type command
sets the local transfer mode and generates the TYPE  command
on the control channel.

_5.  _A_t_t_a_c_h _C_o_m_m_a_n_d_s

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

Some parameters are accepted by several drivers. They are:

_5._1.  _b_u_f_s_i_z_e

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 usu- ally more than
sufficient.

For synchronous devices (e.g., the sssscccccccc,,,, hhhhssss,,,, ppppcccc111100000000,,,, hhhhaaaappppnnnn  and
ddddrrrrssssiiii interfaces operating in HDLC mode), the bufsize parame-
ter 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 max- imum  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  pack- ets to be carried
without fragmentation.

_5._2.  _i_o_a_d_d_r

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

_5._3.  _v_e_c_t_o_r

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

_5._4.  _i_f_a_c_e

The name (an arbitrary character string) to be  assigned  to
this  interface.  It  is  used  to refer to the interface in
iiiiffffaaaacccceeee and rrrroooouuuutttteeee commands and in ttttrrrraaaacccceeee output.

_5._5.  _m_t_u

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 aaaaxxxx22225555 ppppaaaacccclllleeeennnn parameter is also relevant.  If the datagram
or  fragment  is  still larger than ppppaaaacccclllleeeennnn, it is also frag-
mented at the AX.25 level  (as  opposed  to  the  IP  level)
before  transmission.   (See  the  aaaaxxxx22225555  ppppaaaacccclllleeeennnn  command for
further information).

_5._6.  _a_t_t_a_c_h _3_c_5_0_0 <_i_o_a_d_d_r>  <_v_e_c_t_o_r>  _a_r_p_a  <_i_f_a_c_e>  <_q_l_e_n>
<_m_t_u> [<_i_p__a_d_d_r>]

Attach a 3Com 3C501 Ethernet interface.  qqqqlllleeeennnn is the maximum
allowable  transmit  queue length.  If the iiiipppp____aaaaddddddddrrrr parameter
is not given, the value associated with a prior  iiiipppp  aaaaddddddddrrrreeeessssssss
command will be used.

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

_5._7.  _a_t_t_a_c_h _a_s_y  <_i_o_a_d_d_r>  <_v_e_c_t_o_r>  _s_l_i_p|_a_x_2_5|_n_r_s  <_i_f_a_c_e>
<_b_u_f_s_i_z_e> <_m_t_u> <_s_p_e_e_d> [<_f_l_a_g_s>]

Attach a "com port" (asynchronous  serial  port).   Standard
values  on  the  IBM PC and clones for iiiiooooaaaaddddddddrrrr and vvvveeeeccccttttoooorrrr 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:

_5._7._1.  _s_l_i_p

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.

_5._7._2.  _a_x_2_5

Similar to sssslllliiiipppp, 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 mmmmooooddddeeee
command for details.

_5._7._3.  _n_r_s

Use the NET/ROM asynchronous framing technique for  communi- cation with a
local NET/ROM TNC.

_5._8.  _a_t_t_a_c_h _d_r_s_i <_i_o_a_d_d_r> <_v_e_c_t_o_r> _a_x_2_5  <_i_f_a_c_e>  <_b_u_f_s_i_z_e>
<_m_t_u> <_c_h__a__s_p_e_e_d> <_c_h__b__s_p_e_e_d>

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

_5._9.  _a_t_t_a_c_h _e_a_g_l_e <_i_o_a_d_d_r> <_v_e_c_t_o_r> _a_x_2_5 <_i_f_a_c_e>  <_b_u_f_s_i_z_e>
<_m_t_u> <_s_p_e_e_d>

Attach an Eagle Computer 8530 interface card.

_5._1_0.  _a_t_t_a_c_h _h_a_p_n <_i_o_a_d_d_r> <_v_e_c_t_o_r> _a_x_2_5 <_i_f_a_c_e>  <_b_u_f_s_i_z_e>
<_m_t_u> _c_s_m_a|_f_u_l_l

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

_5._1_1.  _a_t_t_a_c_h _h_s <_i_o_a_d_d_r> <_v_e_c_t_o_r>  _a_x_2_5  <_i_f_a_c_e>  <_b_u_f_s_i_z_e>
<_m_t_u> <_k_e_y_u_p__d_e_l_a_y> <_p>

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  recom- mended  that  no
other interfaces requiring small interrupt latencies be attached to the same
machine.

The kkkkeeeeyyyyuuuupppp____ddddeeeellllaaaayyyy parameter specifies  the  transmitter  keyup
delay  in  byte  time  intervals.  The pppp 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.

_5._1_2.  _a_t_t_a_c_h _p_a_c_k_e_t <_i_n_t_v_e_c> <_i_f_a_c_e> <_t_x_q_l_e_n> <_m_t_u>

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.

iiiinnnnttttvvvveeeecccc is the software interrupt vector used for  communica-
tion  to the packet driver, and ttttxxxxqqqqlllleeeennnn is the maximum number
of packets that will be allowed on the transmit queue.

_5._1_3.  _a_t_t_a_c_h _p_c_1_0_0 <_i_o_a_d_d_r> <_v_e_c_t_o_r> _a_x_2_5 <_i_f_a_c_e> <_b_u_f_s_i_z_e>
<_s_p_e_e_d>

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

_5._1_4.  _a_t_t_a_c_h _s_c_c <_d_e_v_i_c_e_s>  _i_n_i_t  <_a_d_d_r>  <_s_p_a_c_i_n_g>  <_A_o_f_f>
<_B_o_f_f> <_D_a_t_a_o_f_f> <_i_n_t_a_c_k> <_v_e_c> [_p]<_c_l_o_c_k> [_h_d_w_e] [_p_a_r_a_m]

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

_5._1_4._1.  _d_e_v_i_c_e_s

The number of SCC chips to support.

_5._1_4._2.  _a_d_d_r

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

_5._1_4._3.  _s_p_a_c_i_n_g

The spacing between the SCC chip base addresses.

_5._1_4._4.  _A_o_f_f

The offset from a chip's base address to its channel A  con- trol register.

_5._1_4._5.  _B_o_f_f

The offset from a chip's base address to its channel B  con- trol register.

_5._1_4._6.  _D_a_t_a_o_f_f

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

_5._1_4._7.  _i_n_t_a_c_k

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

_5._1_4._8.  _v_e_c

The CPU interrupt vector for all connected SCCs.

_5._1_4._9.  _c_l_o_c_k

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

_5._1_4._1_0.  _h_d_w_e

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.

_5._1_4._1_1.  _p_a_r_a_m

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 aaaattttttttaaaacccchhhh sssscccccccc ............ iiiinnnniiiitttt command must  be  given  before  the
interfaces are actually attached with the following command.

_5._1_5.  _a_t_t_a_c_h _s_c_c <_c_h_a_n>  _s_l_i_p|_k_i_s_s|_n_r_s|_a_x_2_5  <_i_f_a_c_e>  <_m_t_u>
<_s_p_e_e_d> <_b_u_f_s_i_z_e> [_c_a_l_l]

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

_5._1_5._1.  <_c_h_a_n>

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.

_5._1_5._2.  _s_l_i_p|_k_i_s_s|_n_r_s|_a_x_2_5

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

_5._1_5._3.  _s_p_e_e_d

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  exter- nal,  and the internal baud rate
generator (BRG) and digital phase locked loop (DPLL) are not used.

_5._1_5._4.  _A_t_t_a_c_h _E_x_a_m_p_l_e_s

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
# The packet driver is for an Ethernet interface
attach packet 0x7e ethernet 8 1500

_6.  _T_h_e /_f_t_p_u_s_e_r_s _F_i_l_e

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 ////ffffttttppppuuuusssseeeerrrrssss 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, giv-
ing a valid name and password listed in ////ffffttttppppuuuusssseeeerrrrssss, before he
or she can transfer files.

Each entry in ////ffffttttppppuuuusssseeeerrrrssss 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.

uuuusssseeeerrrrnnnnaaaammmmeeee is the user's login name.

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

////ppppaaaatttthhhh 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 start- ing 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.

ppppeeeerrrrmmmmiiiissssssssiiiioooonnnnssss 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 permis- sion.

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

friendly test /testdir 7


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

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.

_7.  _T_h_e /_d_o_m_a_i_n._t_x_t _F_i_l_e

_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 Inter-
net  Domain  Name  resolver  and  a  local   "cache"   file,
////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt.  Whenever  the  user  specifies  a domain name,
////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt 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 ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt 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 ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt 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 /aaaauuuuttttooooeeeexxxxeeeecccc....nnnnoooossss file are in IP address for-
mat, then it is possible to start with  a  completely  empty
////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt  file  and  have _n_o_s build it for you.  However,
you may wish to add your own entries to ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt,  either
because  you  prefer  to  use  symbolic domain names in your
/aaaauuuuttttooooeeeexxxxeeeecccc....nnnnoooossss file or you don't  have  access  to  a  domain
server  and  you need to create entries for all of the hosts
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

IIIINNNN 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.  AAAA 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
ppppcccc....kkkkaaaa9999qqqq....aaaammmmpppprrrr....oooorrrrgggg     therefore    has    Internet    address
128.96.160.3.

Another possible entry is the CCCCNNNNAAAAMMMMEEEE (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  CCCCNNNNAAAAMMMMEEEE
record is given to _n_o_s, the system automatically follows the
reference to the canonical name and returns the  IP  address
associated with that entry.

Entries added automatically by _n_o_s will have  an  additional
field  between  the  domain  name  and the class (IIIINNNN) 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_o_s)
caching these records are supposed to delete them after  the
time-to-live  interval  has expired, allowing for the possi-
bility that the information in the record may become out  of
date.  Cache expiration is not currently implemented in _n_o_s,
but TTLs are recorded in ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt in anticipation of this
feature.  Since  ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt 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 ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt from
remote server responses. These are not currently used by _n_o_s
but  are retained for future development (such as the incor-
poration of a domain name server into _n_o_s  itself).   Server
responses  indicating that a given record does not exist are
also recorded in ////ddddoooommmmaaaaiiiinnnn....ttttxxxxtttt. These entries have empty value
fields, e.g.,

foobar.ampr.org.        500     IN      A


_8.  _S_e_t_t_i_n_g _B_u_f_s_i_z_e, _P_a_c_l_e_n, _M_a_x_f_r_a_m_e, _M_T_U, _M_S_S _a_n_d _W_i_n_d_o_w

Many _n_o_s 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_o_s implementations of AX.25.

_8._1.  _H_a_r_d_w_a_r_e _P_a_r_a_m_e_t_e_r_s


_8._1._1.  _B_u_f_s_i_z_e

This parameter is required by most of  _n_o_s'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 bbbbuuuuffffssssiiiizzzzeeee; it must  be  specified  in  the
aaaattttttttaaaacccchhhh command for the interface.

_8._2.  _A_X_2_5 _P_a_r_a_m_e_t_e_r_s

_8._2._1.  _P_a_c_l_e_n

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 ppppaaaacccclllleeeennnn is 256 bytes.

_8._2._2.  _M_a_x_f_r_a_m_e

This parameter controls the number of I-frames that _n_o_s  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 mmmmaaaaxxxxffffrrrraaaammmmeeee in _n_o_s is 1 frame.

_8._3.  _I_P _a_n_d _T_C_P _P_a_r_a_m_e_t_e_r_s

_8._3._1.  _M_T_U

The MTU (Maximum Transmission Unit) is an interface  parame-
ter  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 ori- ginal datagram have arrived. Then
they are reassembled  back into the complete, original IP datagram. The
minimum accept- able interface MTU is 28 bytes: 20 bytes for the  IP  (frag-
ment) header, plus 8 bytes of data.

There is no default MTU in _n_o_s; it must be explicitly speci-
fied for each interface as part of the aaaattttttttaaaacccchhhh command.

_8._3._2.  _M_S_S

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 (con-
nection  request) packets that open a TCP connection. In the
_n_o_s 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  over- head  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 MMMMSSSSSSSS is 512 bytes.

_8._3._3.  _W_i_n_d_o_w

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 WWWWiiiinnnnddddoooowwww is 2048 bytes.

_8._4.  _D_i_s_c_u_s_s_i_o_n


_8._4._1.  _I_P _F_r_a_g_m_e_n_t_a_t_i_o_n _v_s _A_X._2_5 _S_e_g_m_e_n_t_a_t_i_o_n

IP-level fragmentation often makes it possible to  intercon-
nect  two  dissimilar networks, but it is best avoided when-
ever 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_o_s it is (re)initialized with  the  iiiipppp  rrrrttttiiiimmmmeeeerrrr
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  sub-
net frames that are immediately 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 ppppaaaacccclllleeeennnn-sized AX.25 seg-
ments (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 segmenta-
tion procedure is a new feature in  AX.25  and  is  not  yet
widely  implemented;  in  fact, _n_o_s is so far the only known
implementation. This creates some interoperability  problems
between  _n_o_s  and  non-_n_o_s  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.

_8._4._2.  _S_e_t_t_i_n_g _p_a_c_l_e_n _a_n_d _b_u_f_s_i_z_e

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 ppppaaaacccclllleeeennnn, you lower the AX.25  pro-
tocol 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 ppppaaaacccclllleeeennnn that is best discovered
by experiment.

Another thing to remember when setting ppppaaaacccclllleeeennnn  is  that  the
AX.25  version  2.0  specification  limits  it to 256 bytes.
Although _n_o_s can handle much larger values, some other AX.25
implementations  (including digipeaters) cannot and this may
cause interoperability problems. Even _n_o_s 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)  allo-
cate receive buffers according to the maximum expected frame
size, so it is important that these  devices  be  configured
with the correct bbbbuuuuffffssssiiiizzzzeeee. To do this, you must know the size
of the largest possible frame  that  can  be  received.  The
ppppaaaacccclllleeeennnn 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 (ppppaaaacccclllleeeennnn + 72)  bytes.  So  you
should make bbbbuuuuffffssssiiiizzzzeeee at least this large.

Another important consideration is that the more recent ver-
sions  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  bbbbuuuuffffssssiiiizzzzeeee;  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 mmmmeeeemmmmoooorrrryyyy ssssttttaaaattttuuuussss com-
mand and looking for a non-zero count  of  IIIIbbbbuuuuffffffffaaaaiiiillll  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 dif-
ferent, as we shall see.

_8._4._3.  _S_e_t_t_i_n_g _M_a_x_f_r_a_m_e

For best performance on a half-duplex  radio  channel,  mmmmaaaaxxxx----
ffffrrrraaaammmmeeee  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.

_8._4._4.  _S_e_t_t_i_n_g _M_T_U

TCP/IP header overhead considerations similar  to  those  of
the  AX.25  layer when setting ppppaaaacccclllleeeennnn apply when choosing an
MTU.  However, certain subnetwork  types  supported  by  _n_o_s
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  offi-
cial  MTU, but the most common implementation (for BSD UNIX)
uses an MTU of 1006 bytes.  Although _n_o_s 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_o_s.

Choosing an MTU for an AX.25 interface is more complex. When
the  interface  operates  in  datagram  (UI-frame) mode, the
ppppaaaacccclllleeeennnn parameter does not apply. The MTU effectively becomes
the  ppppaaaacccclllleeeennnn  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 ppppaaaacccclllleeeennnn bytes.  Unfor-
tunately, as also mentioned earlier, _n_o_s is so far the  only
known  implementation  of  the  new  AX.25 segmentation pro-
cedure. This is fine as long as all  of  the  NET/ROM  nodes
along  a path are running _n_o_s, but since the main reason _n_o_s
supports NET/ROM is to allow use of  existing  NET/ROM  net-
works, 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 ppppaaaacccclllleeeennnn 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 ppppaaaacccclllleeeennnn is 256, this leaves  236
bytes  for  the  IP datagram. This is the default MTU of the
nnnneeeettttrrrroooommmm pseudo-interface, so as long as ppppaaaacccclllleeeennnn  is  at  least
256  bytes,  AX.25 segmentation can't happen. But if smaller
values of ppppaaaacccclllleeeennnn are used,  the  nnnneeeettttrrrroooommmm  MTU  must  also  be
reduced with the iiiiffffccccoooonnnnffffiiiigggg 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_o_s and sup-
port 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 ppppaaaacccclllleeeennnn value
is appropriate for the link.

_8._4._5.  _S_e_t_t_i_n_g _M_S_S

The setting of this TCP-level  parameter  is  somewhat  less critical than the
IP and AX.25 level parameters already dis- cussed, 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
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.  (Unfor- tunately, 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 unneces- sarily.

On the other hand, a too-small MSS can result in a consider- able  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.

_8._4._6.  _S_e_t_t_i_n_g _W_i_n_d_o_w

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 net-
work  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 ttttccccpppp ssssttttaaaattttuuuussss <<<<ttttccccbbbb>>>> or ssssoooocccckkkkeeeetttt
<<<<ssssoooocccckkkknnnnoooo>>>> commands.  Look at the  ccccwwwwiiiinnnndddd  (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 neces-
sary 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_o_s out of memory if excessive TCP window sizes  are  adver-
tised  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.

Depending on the channel access method and link level proto- col,  the  use
of a window setting that exceeds the MSS may cause an increase in channel
collisions. In particular, col- lisions  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.

_8._5.  _S_u_m_m_a_r_y

In most cases, the default values provided by _n_o_s  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.


                                  NOSDOC.DOC

Date: Tue, 22 Nov 88 00:35:09 EST
From: [e-mail] (Phil Karn)
To: [e-mail]
Subject: nos.arc on flash.bellcore.com

I'm uploading the file nos.arc to flash.bellcore.com under the /pub/ka9q
directory. This contains the current source of the new version I've been
working on. Although it is *NOT* yet complete, I thought I should make it
available so people can see how it's shaping up.

Go ahead and give it a try on the Internet. I have NOT yet finished the
implementation of AX.25 sockets, so don't bug me about that part yet.

I know, I know, there's no documentation yet. The main thing you need to know
is that \hosts.net has been replaced with \domain.txt, and the format is that
of a domain server database, not UNIX /etc/hosts.

Phil

Unfortunately, I just haven't had the time to update the documentation for
NOS. Actually, the user interface isn't that much different; the main
difference is the use of a domain resolver. As part of this work I got rid of
hosts.net in favor of a local domain cache called domain.txt.

A word of warning about the domain stuff in NOS: the domain.txt file is
intended only as a local CACHE for the resolver. I have not yet done a domain
SERVER, so the content of domain.txt is not necessarily the same as you would
put in a server database.

This particular version tries to grab 200K from the system at startup time for
the heap; if less is available, it'll get whatever it can. If you want to use
more, modify the call to grabcore() in pc.c. Eventually this will probably be
a easily configurable value.

1. I've made the final switch to Turbo. You need Turbo C 2.0 Professional to
compile and assemble this package from scratch.

2. The command line now accepts several arguments that are best illustrated by
example:

        net /m200 /s40 /d\ /autoexec.net

In this case, net is told to grab 200K of memory from MS-DOS for the heap, to
allow a maximum of 40 active sockets, and to make the directory prefix for all
files (configuration, domain.txt, mail spool files, etc) the root.  These
particular values all happen to be the defaults for their corresponding
parameters, so of course you'd get the same effect by just typing "net".

I decided that command line parameters were a better way to go than
environment variables. The latter don't necessarily exist on systems other
than MS-DOS and UNIX.  You can always create a batch (shell script) file to
invoke net with the parameters you want.

If you call net with the -d option, you can specify the parent directory of
all the various files used by net.

Interesting. Well, one thing you might try is giving NOS less memory than the
default, which is 200K for the heap. On my 640K system with no major TSRs
running (just MS-DOS, COMMAND.COM and TRW PC-2000 packet driver) this leaves
about 155K unused. (I also have a disk cache and ram disk, but they all run in
extended memory). Depending on what else you might have loaded, the problem
might well be as simple as running out of memory, e.g., if your driver tries
to request memory from DOS when it is all taken but doesn't bother checking
(or behaving rationally) when this happens.

To specify less memory, invoke NOS like this:

      net /m100

That would cause it to grab only 100K.

NOS does not deliberately "barf" if it requests more memory space than was
available. It will simply use whatever is available. The only problem this
creates is when you try to shell out to run a subcommand; there won't be any
memory left to run command.com.

2. As you can probably tell from the foregoing example, NET is now large model
by default. The code will still compile and run under small model if you want.
In large model you can use as much memory as the system has available for
buffering, but the downside of this is that there may be none left for other
activities, e.g., running under a multitasker or shelling to a subprogram.
Hence the option of specifying how much memory should be used. You can now run
many more sessions, run much larger windows, etc, and it all works!

2. The domain receiver task is now started immediately after the very first
"domain addserver" command is executed. This allows subsequent lines in the
autoexec.net file to refer to domain names that aren't yet in domain.txt -- IF
sufficient routing entries are already in place to reach the domain server.
Formerly, the use in autoexec.net of any domain name that wasn't already in
domain.txt caused net to hang at startup. Note, however, that domain.txt still
needs a few "seed" entries if you use domain names for the "ip address" and
"domain addserver" commands, or for "route add" commands necessary to reach
the domain server.

The ip address must be set before the first "domain addserver" command.

1. A finger server has been added. It works similarly to the pre-NOS finger
server by KA7AXD *except* that the files under /finger do NOT have ".txt"
appended to them. If you finger "[e-mail]", finger will send back the
contents of "/finger/foo".

2. I finally got tired of the schizophrenic MS-DOS use of either backslash (\)
or forward slash (/) as the path separator in file names. The code now deals
strictly with forward slashes just as though it's running under UNIX; MS-DOS
system calls that return pathnames now have any backslashes in their return
values immediately converted to forward slashes for consistency.

This requires ONE IMPORTANT CHANGE -- you must edit your /ftpusers file to
change all instances of backslash in the allowable prefix field to forward
slash, or you will not be able to access any files. The symptoms of not doing
this are that you will be allowed to log in via FTP, but every operation you
try will be rejected with a "permission denied" message -- even if you are
supposed to have full access to the system.

3. The session summary command ("session" without arguments) now shows any
active data connections that are associated with FTP sessions.

3. Added the "delete" and "rename" top-level commands.

Lately I've been receiving an increasing number of messages asking questions
about the UNIX ports of my code, particularly Xenix and AT&T Unix System V
(e.g., Microport).

I need to point out a few things:

1. I did not do these ports. In fact, all of my TCP/IP development work is
done on an AT clone running MS-DOS 3.3. That is the ONLY version of NET about
which I can answer questions.

2. As a matter of personal principle, I avoid all AT&T-based UNIX systems.
All of the UNIX systems I use run Berkeley or Berkeley-derived code (e.g.,
SunOS, Ultrix). Since all BSD-based UNIX systems already have full TCP/IP
support, there is little reason to run my code on those systems.

3. Bob Hoffman, [e-mail], has graciously agreed to act as
coordinator of those working with UNIX ports of my code. Please direct any
questions about these versions to him, not to me.

1. The "remote" server and client are completely reworked. The "reset" and
"exit" functions no longer depend on the secrecy of the control port number,
but use a password text string instead. (Not that this makes things any more
secure against someone merely watching the channel, of course. Someday this
will be replaced with a cryptographic authenticator.)

I did this because I just added a "remote kick" command and I wanted to make
it available to everyone without also making the more disruptive "exit" and
"reset" functions also freely available. I therefore recommend that people use
the default port number (0x1234) whenever possible.

As before, there are no explicit acknowledgements to any of the "remote"
commands.

Here are a few sample commands:

net> remote pc.ka9q.ampr.org kick

        Tell pc.ka9q.ampr.org to kick all TCP connections it has with me.
        If there aren't any, do nothing.

net> remote -p 555 pc.ka9q.ampr.org kick

        As above, but send the command to UDP port 555 on the remote system.
        (You won't have to use this if everybody uses the default port
        when starting the remote server.)

net> remote -a ka9q.bellcore.com pc.ka9q.ampr.org kick

        Tell pc.ka9q.ampr.org to kick all TCP connections it may have with
        ka9q.bellcore.com.

net> remote -k key pc.ka9q.ampr.org exit

        Tell the copy of net.exe on pc.ka9q.ampr.org to exit. (If the
        specified key is incorrect, the remote system will log that
        fact and take no other action, giving you half a chance to detect
        nasty people before they do actual damage.) "reset" may be
        substituted for "exit"; this causes a cold reboot of the remote
        system (MS-DOS only).

net> remote -s mykey

        Set the key for the local system's "remote" server. (This command
        does not generate any network packets.) NB: Until a key
        is set for the local system, it will refuse ALL remote requests
        except those for TCP kicks. I.e., you can allow remote kicks
        while disallowing remote resets and exits altogether by not
        setting a key.

The protocol formats for the new "remote" command are reasonably backward
compatible with the old. The commands are sent in UDP datagrams, as before,
with the first byte of the data field containing the command (1 == reset, 2 ==
exit, 3 == kick). In the case of reset or exit, the variable length key must
immediately follow the command byte.  For the kick command, an optional 4-byte
target IP address to kick follows the command byte; there is no key field. If
the target IP address is missing, the system will default to kicking the
source address in the UDP command packet.

This version includes the NET/ROM layer 3 and 4 protocols as integrated into
NOS by SM0RGV. I had to fix a few ANSI function prototypes and delint a few
other places, but I've adopted Anders' code pretty much as is. It seems to
work, although I did notice one occasion that the NET/ROM routing table got
garbled. I would like reports from others on how well this code works before
we put it into wide circulation.

I just fixed a typo in nr3.c that kept IP-over-NET/ROM from working, and I
also added a remote kick feature to SMTP. This latter Dfeature is coupled with
the remote tcp kick server I added the other week, in that now when you kick a
remote station it will not only do a TCP kick on any existing TCP connections
it may have with you, but it will also run through the SMTP queue and start up
a session for anything that's waiting for you.

This feature should be very useful to those who want to run mail gateways with
manually dialed SLIP links (with Tomcat being the prime example).  All you'll
have to do is dial the connection to Tom's machine and send it the remote kick
command (which is encapsulated in a UDP datagram).  His system will then
immediately send you any mail it has waiting for you.

I've updated the version of nos on flash. I incorporated some bug fixes to the
NET/ROM socket interface code from Anders, and I added a new command to the ip
layer: "ip rtimer". This allows you to set the IP level reassembly timeout
interval. This is the length of time that IP will keep the fragments of an
incomplete datagram around while waiting for additional fragments to arrive;
the reassembly timer is restarted each time a new fragment arrives.

The timeout value was formerly hard-coded at 30 seconds. This is now the
default for the new command, so if you do nothing the system will continue to
behave exactly as before. NB: the value for rtimer, as with other timer
values, is in MILLISECONDS.

I added this in response to some observations by WB0MPQ that indicated that IP
reassembly timeouts were occurring before subsequent fragments could be
delivered successfully over a NET/ROM network (yes, it's really that slow).
But be careful: if you set the timeout too long and you get a lot of
fragmentary datagrams that never complete, you'll tie up a lot of memory.

I'm uploading the version of NOS on flash.bellcore.com. This version supports
RIP, the interior routing protocol made popular by Berkeley UNIX.  To enable
the reception of RIP broadcasts, merely say

      start rip

If you're not acting as a gateway to anyone, this is all you need do -- your
system will begin to passively monitor its interfaces for broadcast routing
packets and it will automatically add routes to the routing table. It may take
up to 30 seconds on an ethernet for the table to be built (this assumes a
broadcast rate of 30 seconds, which is standard on Ethernet). If you want to
get started faster, you can give an optional IP address to the command:

      start rip [128.96.160.0]

This broadcasts a RIP "request" packet on the local subnet, which triggers
each gateway within earshot to send you its routing tables. (This requires
knowledge of the local IP broadcast address, plus an ARP entry for same. Read
on to find out about both of these things.)

If you are also acting as a gateway, then you'll want to enable the transmit
routines. First add ARP entries that map the local broadcast address for each
of your networks to the correct hardware address. For example, the IP
broadcast address on my shack Ethernet is 128.96.160.0, so I include the line

      arp add [128.96.160.0] ethernet ff:ff:ff:ff:ff:ff

in my /autoexec.net file. Then I enable the broadcasting of routing info
with the line

      rip add [128.96.160.0] ethernet 30 6

This means "broadcast your routing tables every 30 seconds on the interface
named 'ethernet', using IP destination address 128.96.160.0. Generate
triggered updates as necessary, and use the split horizon method."

On a packet radio channel, I might use the following lines:

      arp add [44.64.0.0] com1 qst-0
      rip add [44.64.0.0] com1 600 7

The last parameter in the "rip add" command is the flag parameter. It is the
sum of the following possible flag values:

1 - Include a host-specific route to yourself in each update. (Not needed
    if you're already advertising a route to the network you're on.)

2 - Use split horizon updating; that is, omit all routing entries that
    point to the interface being used for the broadcast. (This reduces the
    chances of routing loops forming).

4 - Generate triggered updates as necessary on this interface, i.e.,
    whenever a metric changes in the routing table, immediately generate
    a broadcast on this interface with the changed entries. If split horizon
    (bit 2) is also set, use "poisoned reverse", i.e., for any routing
    table entries that point to this interface, include them with an
    infinite metric (RIP defines 16 to be infinity) instead of leaving them
    out as happens during a normal routing broadcast when split horizon
    is set.  Triggered updates helps spread the word faster when links
    fail, reducing the chances of a temporary loop forming.



For Ethernet, I recommend a flag value of 6 (triggered updates and split
horizon). On SLIP links, use 6 or 7, depending on whether you need to emit a
host-specific route to yourself. On a packet radio channel where everyone is
not fully connected (the usual case), use 7 and DON'T advertise any routes to
the subnet unless you can reach everyone in that subnet.

(A packet radio channel is best modeled as a collection of point-to-point
links since it rarely fits the model of a fully interconnected subnet like
Ethernet.) Note that you don't have to broadcast your routes; you can direct
them to a specific set of stations by using their names or addresses in the
"rip add" command. You can have any number of such commands per interface,
with the only limit being channel traffic overhead.

An experimental parameter is available to control something I call "route
merging". If you say "rip merge on", then an incoming route that is more
specific than one you already have in your table is ignored if they both point
to the same gateway. For example, if you already have a default route that
points to gateway "foobar", then any route that arrives from gateway foobar
will be ignored because to put it in the table would not cause any change in
the routing of packets -- they'd still go to foobar anyway.

Properly used, this should save a lot of routing table space.

You can trace the automatic routing messages and controls by the "rip trace"
command; it takes a numeric parameter. "rip trace 0" disables tracing, "rip
trace 1" generates messages only when routes change, and "rip trace 2" shows
you everything, even when things are stable.

If you want to ignore routing broadcasts from a certain gateway (e.g., because
it can't hear you), say

      rip refuse hostname

where 'hostname' is the domain name or [ip address] of the offending gateway.
To reverse this, just say

      rip accept hostname

This manual filtering will probably do until I'm able to devise some sort of
link connectivity algorithm and protocol that can analyze the quality of the
path between your station and each of your neighbors so routing packets can be
filtered automatically. I have an idea of how to do this -- by broadcasting
periodic status packets containing received and transmitted packet count
statistics and using such packets to determine how well you're being heard.

Ooops, I think I made a minor error in my discussion of RIP over radio.  The
flag setting for RIP broadcasts over a radio channel should probably be 5, not
7. You don't want to use split horizon over a radio subnetwork unless it is
internally fully connected, since there may well be relay routes that enter
and leave an intermediate station by the same interface. Split horizon would
suppress such routes, which would preclude same-channel relay hops.

I've updated the NOS code on flash. I've been doing a lot of work on the RIP
code to fix bugs and make things more stable. I changed the command syntax for
a couple of the rip commands; look at the help messages or read the source for
details until I can document things further.

Note! This version REQUIRES that you set the default local IP address (i.e.,
issue the "ip addr" command) BEFORE you attach any interfaces. So edit your
autoexec.net file appropriately.

The reason for this requirement is the major change in this version: each
interface can now have its own IP address. An interface's IP address can be
specified in the attach command, but if it is omitted the IP address given
earlier in the "ip address" command will be used by default. (Hence the
requirement given above. I considered doing away with the "ip address" command
altogether and making the ip address argument on each attach command required,
but this would have been a more disruptive change.)

This architectural change brings the NET package into line with standard
Internet practice. This is mainly for the benefit of those who use NET as a
router between Ethernets in a regular Internet environment, where the other
hosts and routers lack NET's extensions to the standard Internet routing and
subnetting facilities. Although it was possible to make the earlier code work
in such situations through a combination of proxy arp and static routes, it
was a little unclean. With this version, the machine can be set up to act just
like a conventional Internet router and multi-homed host.

I.e., if you have NET running with several interfaces, each with its own
unique IP address, the system will accept packets addressed to any of its
interfaces' addresses. When the system originates packets, the local address
appropriate for the sending interface will be used, all in accordance with
standard Internet practice. Note that when you do a "tcp stat" the local IP
addresses for connections in LISTEN state are 0.0.0.0; this is normal. The
appropriate IP address is used when the connection is actually opened.  The
BSD constant "INADDR_ANY" is provided in a header file, and it can be used
just as it is in BSD when binding local socket addresses in an application.

Note that you are definitely NOT required to have a unique IP address for each
interface. If you specify the same IP address for each interface (or allow
each interface to use the global default set with the "ip address" command),
then the package behaves just as it did before.  Therefore this change is
largely irrelevanft to most AMPRNET users. It is also irrelevant whose NET
configurations have only a single interface (i.e., all end-user systems that
don't operate as gateways).

I've added a new command, "iface", that lists the interfaces on the system
along with their parameters (e.g., IP address, send and receive packet counts,
etc.)  There's also a "domain listservers" command that displays the list of
domain servers along with various statistics measured for each.

      Subject: lost first characters

I haven't investigated Tom's specific problem, but I've seen similar things in
the past and it's almost always been due to null characters inbedded in the
stream being sent to the terminal. The ANSI.SYS and NANSI.SYS drivers both
display a null (0) character exactly as though it were a space, and this I
consider a bug. Every other terminal I've ever seen treats null as a no-op.
One of these days I'll dig into the NANSI.SYS source and fix it.

1. KY3B's port of PE1CHL's generic 8530 driver. Ken did all the work of
porting Rob's driver to NOS. I took his code, reformatted and delinted it a
bit and added ANSI-style function prototypes, but I have not actually tested
it. Those of you using DRSI cards with slow speed modems, please give this
driver a try and let us know if it works. There's a flag in config.h for
configuring out this code if you don't need it and want to save the space.

2. I added an option in config.h for turning off the mailbox code.  When the
mailbox has been configured out, the following commands are removed:

      mbox
      start telnet/netrom/ax25
      stop telnet/netrom/ax25

The "mbox y" command is gone. It didn't seem to make sense to keep it around
given the presence of a separate "ttylink" server that goes straight to the
console. So whenever the mailbox is configured into the system the telnet,
netrom and ax25 servers all get the mailbox automatically. One less thing you
have to remember to put in your autoexec.net files...

I'm currently updating the NOS on flash. This incorporates the latest mbox and
netrom patches by Anders, the latest DRSI driver from Stu, and the
vector-saving fix to ec.c suggested by Ron Henderson. The only change I made
myself was to add an #ifdef MAILBOX in fingerd.c around a reference to the
mailbox code.


                                    ALIAS

#
# SMTP server ALIAS file. This is for resolving a given target address into
# a single or multiple entry mail list.
# Format:
#    mail_list_name call_1@host_1 [call_2@host_2]......# comments
#
bob     [e-mail]
colinw  [e-mail]
colinr  [e-mail]
G1PCD   g1pcd%gb3kp@gb3xp
G1WKK   [e-mail]
G3RRA   [e-mail]
G3TNE   [e-mail]
G8GGI   [e-mail]
G8KWI   [e-mail]
g8kwi   [e-mail]
GB3XP   [e-mail]
hilary  [e-mail]
ian     [e-mail]
jim     [e-mail]
john    g5ds%gb3kp@gb3xp
kelvin  [e-mail]
mike    g8atk%gb7wok@gb3xp
paul    g1pcd%gb3kp@gb3xp
world   [e-mail] [e-mail] [e-mail]
        [e-mail] [e-mail] [e-mail]
        [e-mail] [e-mail] [e-mail]
        [e-mail] [e-mail] [e-mail]
        [e-mail]
locals  [e-mail] [e-mail] [e-mail]
        [e-mail] [e-mail] [e-mail]
        [e-mail] [e-mail] [e-mail]
ted     gb3kp%gb3kp@gb3xp
ron     [e-mail]
tim     [e-mail]
gareth  [e-mail]
bolton  [e-mail]

                                 AUTOEXEC.NET

#                          A U T O E X E C . N E T
#                          -----------------------
#
#  This is the configuration file for the NOS.EXE program...
#  this file *MUST* be in the root directory ( \ ) of your current disk
#  when NOS.EXE is run if you want NOS to use is as the default file.
#
#  Note: NOS.EXE ignores all lines beginning with a pound sign (#).
#
#    There are many commands which must be provided to NOS.EXE
#    each time it is started to configure the program.  To keep
#    from having to type them by hand each time, we put them in
#    this file, which is read each time NOS starts up.  Commands
#    in this configuration file are entered exactly as they would
#    be typed at the keyboard in the program.
#
#    We've tried to give you intelligent default values for each of
#    the commands below.  You need to read completely through this
#    file, changing things as you go.  If you're not sure what to
#    do with a command, try leaving it like it is!  Once you become
#    familiar with the package, you'll no doubt find things to change.
#    Once you're up and running and are all set, you can delete some or
#    all of the comment lines (the ones that start with '#') to save
#    disk space and make the program load faster, if you wish.
#
#-----------------------------------------------
#
#    Turn off the internal stopwatch functions as on the Archimedes they
#    don't half hassle the pc emulators speaker driver code..and it BEEPS!
#
watch off
#
#-----------------------------------------------
#
#    Firstly, load up the memory database with all the remote nodes
#    identifications. The default file to use is \domain.txt but this
#    is very slow to access if the memory database is not invoked.
#
domain load
#
#-----------------------------------------------
#
#    Just in case we don't have a host name entry in our domain file
#    let's ask our domain server at g1emm2 to try and resolve unknowns.
#    This is currently VERY dangerous as it may stall the command
#    interpreter or worse still - the timer process!! => dead in the H2O!
#
# domain addserver g1emm2
#
#-----------------------------------------------
#
# The Domain timer backoff can be either linear or binary exponential.
# Realisically, the linear backoff is vital for Amateur radio work.
#
domain timertype linear
#
#-----------------------------------------------
#
# The Domain default suffix for host names without a '.' is '.ampr.org.'
# and the domain.txt file has only names of the format:-
# <host>.ampr. (CNAME) and <host>.ampr.org. (A) in it.
#
domain suffix ampr.org.
#
#-----------------------------------------------
#
# This entry tells NOS.EXE the name of your machine. Your hostname will
# show up in mail headers, etc.
#
hostname g1emm.ampr.org
#
#-----------------------------------------------
#
# The next line does the same thing that "MYCALL" did in your AX.25
# TNC... it identifies the callsign you're using on the air in AX.25
# packets. It also defines the callsign of your net/rom node!!!
#
ax25 mycall g1emm-1
#
#-----------------------------------------------
#
# This one contains your IP address. This can either be in the form
# [44.131.x.y] where x and y are your alloted number values or it can
# use the domain file information and will then take a symbolic node
# name and convert it internally to your IP address. The [] are required
# if you wish to give an absolute address.
#
ip address g1emm
#
#-----------------------------------------------
#
# The buffers command sets the number of buffers and thier sizes in
# the interrrupt memory handler cache. Ax25 doesn't use them at all
# but just in case, here are a few.
#
buffers 5 256
#
#------------------------------------------------
#
# The attach command tells NOS.EXE about the interfaces in your computer
# that you will be using for TCP/IP.  These can include normal IBM-type
# serial "comm ports", Ethernet controllers, or dedicated packet cards.
#
# The syntax is:
# attach <hw type> <I/O address> <vector> <mode> <label> <bufsize>
#        <mtu> [<speed>] [IP addr]
#
# COM1: / 9600 baud KISS connection for use with KISS TNC's.
#
#attach asy 0x3f8 4 ax25 tnc 2048 256 19200
#
# COM2: / 1200 baud KISS connection for use with KISS TNC's.
#
attach asy 0x2f8 3 ax25 tnc 2048 256 19200
#
# COM1: / 9600 baud slip link to another computer
#
#attach asy 0x3f8 4 slip sl0 8092 576 9600
#
#-------------------------------------------------
#
# The following entry defines the broadcast address for
# the interface labeled 'tnc' in the attach command.
#
ifconfig tnc broadcast [44.131.0.0]
#
#-------------------------------------------------
#
# The KISS computer-to-tnc protocol includes a "command packet" that
# you can use to twiddle TNC parameters like TXDELAY, TXTAIL, PERSIST,
# SLOTTIME and DUPLEX.  Since most KISS implementations include good
# default values, you shouldn't have to use this feature.
# All TNC's were not created equal, so you *MUST* read the docs for the
# KISS implementation for your TNC before twiddling!
#
# The format is:  param <label> <hex value> <hex value> <hex value> ...
#
param tnc 1 20
param tnc 2 16
param tnc 3 10
param tnc 4 10
param tnc 5 0
#
#-------------------------------------------------
#
# The following entry tells the program to route all packets out
# the interface labeled 'tnc' in the attach command.
#
route add default tnc
#
#-------------------------------------------------
#
# Time To Live is the maximum number of hops a packet can take
# before it is thrown away. This command prevents an inadvertent
# infinite loop from occuring with packets in the network.
#
ip ttl 10
#
#-------------------------------------------------
#
# The Maximum Segment Size is the largest single transmission that
# you will send. An mss of 216 corresponds to the mtu of 256 set
# up in the attach command above, overhead bytes considered.
#
tcp mss 216
#
#-------------------------------------------------
#
# Initial Retry TimeouT (irtt) is the time between retries before
# the corrected timers start to function in units of seconds.
# The default is 65 seconds but may be adjusted as required.
#
tcp irtt 65000
#
#-------------------------------------------------
#
# The TCP timer backoff can be either linear or binary exponential.
# Realisically, the linear backoff is vital for Amateur radio work.
#
tcp timertype linear
#
#-------------------------------------------------
#
# The Window parameter establishes the maximum number of bytes
# that may be outstanding before your system expects an ack.
# If window is twice as big as mss, for example, there will be two
# active packets on the channel at any given time... large values of
# window provide improved throughput on full-duplex links, but are a
# problem on the air.  Keep  mss <= window <= 2*mss if you're on the air.
#
#
tcp window 432
#
#-------------------------------------------------
#
# This entry will open 'logfile' in the \spool directory and will
# record the server activity of your system.  If you don't want a log,
# comment out this line... if you do, make sure you have a \spool
# directory!
#
log \spool\logfile
#
#-------------------------------------------------
#
# Each of the servers (services you will provide) must be turned
# on before they will be active. The following entries turn all
# of them on. To turn any function off use the command 'stop' after
# NOS gets fired up, or just comment out the line here.
#
start ax25
start netrom
start echo
start discard
start telnet
start ftp
start smtp
start finger
start remote
start rip
start ttylink
#
#--------------------------------------------------
#
# Cause the SMTP server to look for new mail to send every 10 minutes
#
smtp timer 600
#
#--------------------------------------------------
#
# Set the remote server password field
#
remote -s zardoz
#
#--------------------------------------------------
#
# Cause the SMTP server to send undeliverable mail to gb3xp for forwarding
#
smtp gateway gb3xp
#
#--------------------------------------------------
#
# Cause the SMTP server to queue mail for SMTP mailer or ext. mailer
#
smtp mode route
#
#--------------------------------------------------
#
# These values come into play when you are operating in the
# AX.25 mode, along with your ax25 mycall entry above.
#
# If you want to operate as a digipeater (for those poor souls
# not operating TCP/IP!), change 'off' to 'on'.
#
ax25 digipeat on
#
#-------------------------------------------------
#
# Use AX25 protocol version 2 as most people have now migrated from 1.
#
ax25 version 2
#
#---------------------------------------------------
#
# Maxframe sets the max number of frames allowed to remain
# unacknowledged. Cannot be greater than 7. Low values are best.
#
ax25 maxframe 3
#
#---------------------------------------------------
#
# Maximum size of packet which will have its data resent with the POLL
# bit set on retry, else, just RR (p) instead of I (p)
#
ax25 pthresh 128
#
#---------------------------------------------------
#
# Paclen limits the size of I=fields.
#
ax25 paclen 256
#
#---------------------------------------------------
#
# Retry limits the number of unsuccessful retransmissions.
#
ax25 retry 5
#
#---------------------------------------------------
#
# Blimit limits the number of incremental retransmission timeouts.
#
ax25 blimit 5
#
#---------------------------------------------------
#
# Set up the AX25 initial round-trip timer in milliseconds.
# The old T1 value is now taken to be 2*irtt and is variable.
#
ax25 irtt 2500
#
#---------------------------------------------------
#
# Set up the AX25 Link Keep-Alive timer T3 in milli-seconds.
#
ax25 t3 65000
#
#---------------------------------------------------
#
# Set up the AX25 Link Redundancy timer T4 in seconds.
#
ax25 t4 300
#
#-------------------------------------------------
#
# The AX25 timer backoff can be either linear or binary exponential.
# Realisically, the linear backoff is vital for Amateur radio work.
#
ax25 timertype linear
#
#---------------------------------------------------
#
# ax25 window sets the number of bytes that can be pending on an
# AX.25 receive queue before sending RNRs back to sender.
#
ax25 window 2048
#
#---------------------------------------------------
#
# Start tracing the previously defined `tnc' line with 111 which is
# trace all input and output packets and dump in ASCII only.
# Value pattern is:-
#       B:D:I:O
#       | | | |__Output packets 0 or 1          1 = trace / 0 = don't
#       | | |____Input packets  0 or 1          1 = trace / 0 = don't
#       | |______Dump level     0 or 1 or 2     0=headers / 1=ascii / 2=hex
#       |________Broadcasts     0 or 1          0 = trace / 1 = don't
#
#
#trace tnc 0111
#
#---------------------------------------------------
#
# Set up the NET/ROM pseudo device so that NOS knows that netrom is used.
#
attach netrom
#
#---------------------------------------------------
#
# Tell NET/ROM what line to use and what we are called, ie. our alias.
# Also define a default quality factor for incoming NET/ROM broadcasts.
#
netrom interface tnc farnhm 10
#
#---------------------------------------------------
#
# Set NET/ROM broadcast reception to only specifically named nodes.
#
netrom nodefilter mode accept
#
#---------------------------------------------------
#
# Set the NET/ROM inter-broadcast time to 30 minutes
#
netrom nodetimer 1800
#
#---------------------------------------------------
#
# Set the NET/ROM obsolesence timer to 30 minutes. Each time it fires
# we will derate the nodes in our tables. A non-refreshed node broadcast
# will vanish in about 3 hours then.
#
netrom obsotimer 1800
#
#---------------------------------------------------
#
# Set NET/ROM mode to switch rather then endpoint. We will tell the world
# about the nodes we can hear and not just ourself.
#
netrom verbose yes
#
#---------------------------------------------------
#
# Set NET/ROM minimum acceptable incoming broadcast level before we will
# build the nodes into our tables. Keeps out longshots!
#
netrom minquality 10
#
#---------------------------------------------------
#
# NET/ROM Time To Live is the maximum number of hops a packet can take
# before it is thrown away. This command prevents an inadvertent
# infinite loop from occuring with packets in the netrom network.
#
netrom ttl 15
#
#---------------------------------------------------
#
# Set NET/ROM acknowledge timer value in milliseconds
#
netrom acktime 3000
#
#---------------------------------------------------
#
# Set NET/ROM maximum number of bytes on the netrom queues (I think!)
#
netrom qlimit 1024
#
#---------------------------------------------------
#
# Set NET/ROM maximum number of retries before disconnecting
#
netrom retries 5
#
#---------------------------------------------------
#
# Set NET/ROM initial round-trip timer in milli-seconds.
#
netrom irtt 60000
#
#---------------------------------------------------
#
# Set NET/ROM promiscuous acceptance of broadcasts at minimum quality.
#
netrom promiscuous y
#
#-------------------------------------------------
#
# The NET/ROM timer backoff can be either linear or binary exponential.
# Realisically, the linear backoff is vital for Amateur radio work.
#
netrom timertype linear
#
#---------------------------------------------------
#
# Let the world know that we are alive and kicking. Three broadcasts
# just to make sure that most people will be able to catch one of them!
#
netrom bcnodes tnc
netrom bcnodes tnc
netrom bcnodes tnc
#
#---------------------------------------------------
#
# Use I frames for ax25 traffic instead of UI frames.
#
mode tnc vc
#
#---------------------------------------------------
#
# Use I frames for NET/ROM traffic instead of UI frames. (Is there a choice?)
#
mode netrom vc
#
#---------------------------------------------------
#
# Initial state ot the system is that the is no manual operator present.
#
attended no
#
#---------------------------------------------------
#
# Bring in all the variable parameters relating to the outside world.
#
# First bring in all the remote NET/ROM nodes for filtering.
#
source \nodes.fil
#
# Next bring in all the remote Tcp/Ip nodes ARP definitions
#
source \nodes.arp
#
# Lastly bring in all the remote Tcp/Ip nodes route definitions.
#
source \nodes.rou
#
#---------------------------------------------------
#
# Define the RIP setup and request a broadcast to load the tables.
#
rip merge n
#
rip add [44.131.0.0] 900 6
#
rip refuse g4hpe
rip refuse g1maa
#
rip request [44.131.0.0]
rip request [44.131.0.0]
rip request [44.131.0.0]
#
#---------------------------------------------------
#
# Wake up the SMTP process to start shipping any outstanding mail.
#
smtp kick
#
#---------------------------------------------------
#
# Announce our start up is complete and the time we took to do it.
#
motd "Sorry, I'm not in at the moment. Please feel free to leave a message. 73, Kelv."
status
#
#---------------------------------------------------
#
# THE END
#

                                  BBSFWD.INF

From [e-mail] Sat Nov 17 03:01:55 1990
Received: from wb0mpq.ampr.org by n2mh.ampr.org with SMTP
        id AA2277 ; Sat, 17 Nov 90 02:07:58 GMT
Date: Sat, 17 Nov 90 01:48:43 GMT
Message-Id: <[e-mail]>
From: [e-mail] (Al Shjarback - Warren,NJ 07060)
To: [e-mail]
Subject: Forwarding 1

>From nn2z@nn2z Wed Oct 10 23:09:51 1990
Received: from pc.nn2z.ampr.org by wb0mpq.ampr.org with SMTP
        id AA16293 ; Wed, 10 Oct 90 22:55:43 GMT
Received: from nn2z.ampr.org by pc.nn2z.ampr.org with SMTP
        id AA6110 ; Wed, 10 Oct 90 18:30:16 EDT
Received: by nn2z.ampr.org (5.59/smail2.5/08-26-89)
        id AA17857; Wed, 10 Oct 90 18:42:39 EDT
Received: from ucsd.edu by thumper.bellcore.com (4.1/4.7)
        id AA10039; Wed, 10 Oct 90 18:44:55 EDT
Received: by ucsd.edu; id AA11758
        sendmail 5.64/UCSD-2.1-sun
        Wed, 10 Oct 90 13:55:35 -0700 for hpbbrd!db0sao!dg4scv-2!tcp-group
Received: from sics.se by ucsd.edu; id AA11743
        sendmail 5.64/UCSD-2.1-sun via SMTP
        Wed, 10 Oct 90 13:55:27 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-group-relay tcp-group-list
Received: from isis.sics.se by sics.se (5.61-bind 1.5+ida/SiteCap-3.0)
        id AA21441; Wed, 10 Oct 90 21:55:11 +0100
Received: from localhost by isis.sics.se (5.61-bind 1.5+ida/SiteCap-3.0)
        id AA07844; Wed, 10 Oct 90 21:55:05 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: NOS Mbox forwarding
Date: Wed, 10 Oct 90 21:55:00 +0100
From: [e-mail]

I have been hacking on the NOS mailbox recently. Paul Healy, EI9GL, wrote some
good forwarding code for NOS. I started changing Pauls code, and I am not sure
if he will recognize it now.

The NOS mailbox now supports forwarding, both outgoing forwarding and reverse
forwarding. It keeps track of which bulletins have been forwarded by adding
"X-Forwarded-To:" lines to the messages. Messages in public "areas" are sent
as bulletins, with BID and everything. Messages from private areas are treated
as private mail and are deleted after forwarding.

The message areas can be checked for messages to forward at a regular
intervals, which is set with the "mbox timer" command. Forwarding can be
started immediately with the "mbox kick" command. There is also a "mbox motd"
and a "mbox attended" command, which I picked from the G1EMM code.

There is a new command in the mailbox too, "Verbose." It displays a message
with all it header lines, contrary to "Read" which only shows four lines. It
is also possible to read a message simply by typing its number.

The mailbox reads a forwarding file, "spool/forward.bbs". Here is a sample
file:

sk0tm 0006
ax25 ax0 sk0tm
sk0tm
amsat
all
------
sm0rgv
netrom #sth675
..c sm0rgv-2
sm0rgv
amsat

The first word on the first line in a forwarding record is the name of the BBS
to forward to. This should be the same type of name which is shown by the
"mbox status" command. The second word is optional. It specifies a range when
forwarding may take place. "0006" means that there will only be forwarding to
this station between midnight and 6am.

The second line specifies how to establish the connection. It should start
with the protocol (ax25, tcp or netrom) and be followed by all the parameters
which are necessary when NOS has to establish a network connection.

Directly after the second line there may be lines that start with a dot. What
follows after the dot will be sent to the remote BBS as soon as the connection
is established.

Then follows the names of a number of message areas, public or private.
Finally, there should be a couple of '-' signs to separate one forwarding
record from another.

The code seems to be working, although there could of course be bugs left.
Anyway, the source is available with ftp from sics.se. The filename is
archive/packet/ka9q/nos/mailbox.arc.

As usual, this message is the only documentation, so it could be worth saving.

Anders

From [e-mail] Sat Nov 17 04:15:14 1990
Received: from wb0mpq.ampr.org by n2mh.ampr.org with SMTP
        id AA2278 ; Sat, 17 Nov 90 03:16:45 GMT
Date: Sat, 17 Nov 90 01:49:06 GMT
Message-Id: <[e-mail]>
From: [e-mail] (Al Shjarback - Warren,NJ 07060)
To: [e-mail]
Subject: Forwarding 2

>From nn2z@nn2z Mon Oct 15 15:08:12 1990
Received: from pc.nn2z.ampr.org by wb0mpq.ampr.org with SMTP
        id AA16697 ; Mon, 15 Oct 90 14:57:51 GMT
Received: from nn2z.ampr.org by pc.nn2z.ampr.org with SMTP
        id AA6493 ; Mon, 15 Oct 90 10:24:34 EDT
Received: by nn2z.ampr.org (5.59/smail2.5/08-26-89)
        id AA01219; Mon, 15 Oct 90 10:35:34 EDT
Received: from ucsd.edu by thumper.bellcore.com (4.1/4.7)
        id AA01720; Mon, 15 Oct 90 10:31:56 EDT
Received: by ucsd.edu; id AA00355
        sendmail 5.64/UCSD-2.1-sun
        Mon, 15 Oct 90 04:29:50 -0700 for hb9zz
Received: from sics.se by ucsd.edu; id AA00339
        sendmail 5.64/UCSD-2.1-sun via SMTP
        Mon, 15 Oct 90 04:29:38 -0700 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -ftcp-group-relay tcp-group-list
Received: from sarapis.sics.se by sics.se (5.61-bind 1.5+ida/SiteCap-3.0)
        id AA09221; Mon, 15 Oct 90 12:29:26 +0100
Received: from localhost by sarapis.sics.se (5.61-bind 1.4+ida/SiteCap-3.0)
        id AA06837; Mon, 15 Oct 90 11:56:45 +0100
Message-Id: <[e-mail]>
To: "JAMES C MANKIN (814)-863-4348" <[e-mail]>
Cc: [e-mail]
Subject: Re: NOS Mbox forwarding
In-Reply-To: Your message of Sun, 14 Oct 90 15:36:00 -0400.
             <[e-mail]>
Date: Mon, 15 Oct 90 11:56:41 +0100
From: [e-mail]

James,

(I am Cc:ing this to tcp-group.)

>   Thanks, changing that line solved the problem.  Another thing I notice now
> is that the nos mailbox doesnt disconnect cleanly after forwarding, it seems
> to do a reset because the connection disappears from the ax status display
> without an ax25 disconnect packet being sent.

This is really odd, has anybody else noticed this?

>  Is there a way to send a message that is for a user at a bbs, rather than
> the bbs's owner?  I can do it if I edit the .txt file in the mail directory
> to have the To: address I want, so my problem is how does one get a message
> for kb3kj @ w3ya  to be placed in the w3ya  mail area.  There must be
> something I am overlooking.

When a message is entered to the mailbox, the address is rewritten according
to rules in the /spool/rewrite file. The first word on each line in the
rewrite file is an address using wildcards. If that address matches the
address you are trying to rewrite, it is rewritten according to the format of
the second word. If the third word is an 'r', the rewrite procedure will be
repeated, now using the new address as input.

Ok, so here is a sample /spool/rewrite file for a machine with the hostname
sk0we.ampr.org:

*!* $2@$1 r
*@sk0we.ampr.org $1 r
*@*.ampr.org $1@$2.ampr.org
sm0rgv@* sm0rgv
*@w3ya* w3ya
*@k* $1%k$[e-mail]

The first line means that addresses written in the "host!user" format should
be rewritten to "user@host" and then the rewrite procedure should be repeated.

The second line converts the address "[e-mail]" into the local
address "user" and then repeats the rewrite procedure.

The third line seems to do nothing. It just converts "[e-mail]" to
"[e-mail]". But it also exits the rewrite procedure since the line
does not end with an 'r'. Any address ending with ".ampr.org" will not be
converted further.

The line "sm0rgv@* sm0rgv" will keep mail for sm0rgv on the local machine even
if it is mistakenly addressed to another BBS, such as "sm0rgv@w3iwi". The line
will however fail to convert addresses such as "[e-mail]" because
of the line described in the previous paragraph.

The line "*@w3ya* w3ya" will leave mail for "user@w3ya" in the local message
area named "w3ya". The same goes for mail using some sort of hierarchical
routing designators such as "[e-mail]". The only exception is for
mail addressed to "[e-mail]" as described above.

The line "*@k* $1%k$[e-mail]" is an example of
how to establish an Internet "wormhole." Suppose I want to forward all mail to
stations with callsigns starting with K to W3IWI through the Internet. The
line quoted above would do it. But if the mail for "user@kxxxx" is received by
w3iwi.ampr.org with SMTP, there might be some problems because the rewrite
file is not scanned when mail is received with SMTP. This could easily be
changed however. Let me know if this is causing you any inconveniencies.

Anders

                                    BM.RC

# configuration file for Bdale's Mailer... format is:
#        host <space> this_host_name
#        user <space> this_user_name
#        fullname <space> your full name for mail headers (optional)
#        reply <space> your reply address if not this machine (optional)
#                  useful for pc on large network off smart hosts
#        smtp <space> path to mailboxes          default /spool/mail
#        edit <space> path your editor (optional)
#        mbox <space> name of file used as default for s command (optional)
#        folder <space> name of directory for save mailby s command (optional)
#        record <space> name of file save a copy of sent mail (optional)
#        maxlet <space> max number of message in mbox ( optional default 300)
#        screen direct | bios video mode ( turbo C only default direct )
#
host g1emm.ampr.org
user g1emm
fullname Kelvin Hill - IO91oe - PSTN [phone]
reply [e-mail]
screen direct
edit \tcpip\qe.exe
smtp /spool/mail
mbox /folder/mbox
record /folder/outmail
folder /folder
maxlet 400

                                  DOMAIN.TXT

#Phil Chapman, nr Manchester, ?
g4lhx.ampr.org. IN      A       44.131.1.1
g4lhx.ampr.     IN      CNAME   g4lhx.ampr.org.
#Nigel Watkinson, Altrincham, IO83uj
g1ula.ampr.org. IN      A       44.131.1.2
g1ula.ampr.     IN      CNAME   g1ula.ampr.org.
#Roger James, Morecambe, IO84nb
g4tot.ampr.org. IN      A       44.131.1.3
g4tot.ampr.     IN      CNAME   g4tot.ampr.org.
#Micheal Lord, Congleton, IO83ls
g3zau.ampr.org. IN      A       44.131.1.4
g3zau.ampr.     IN      CNAME   g3zau.ampr.org.
#David ?, Southport, IO83mp
g4tup.ampr.org. IN      A       44.131.1.5
g4tup.ampr.     IN      CNAME   g4tup.ampr.org.
#Chris McMahon, Blackpool, IO83lu
g6fci.ampr.org. IN      A       44.131.1.6
g6fci.ampr.     IN      CNAME   g6fci.ampr.org.
#Neil ?, Caton, IO87b
g3uvq.ampr.org. IN      A       44.131.1.7
g3uvq.ampr.     IN      CNAME   g3uvq.ampr.org.
#John Heaton, Bolton, IO83sn
g1yyh.ampr.org. IN      A       44.131.1.8
g1yyh.ampr.     IN      CNAME   g1yyh.ampr.org.
#Alban ?, ?, ?
g8nvw.ampr.org. IN      A       44.131.1.9
g8nvw.ampr.     IN      CNAME   g8nvw.ampr.org.
#Ian Marchant, Congleton, IO83ve
g1rsw.ampr.org. IN      A       44.131.1.10
g1rsw.ampr.     IN      CNAME   g1rsw.ampr.org.
#Brian Lewis, Ingleton,
g4vps.ampr.org. IN      A       44.131.1.11
g4vps.ampr.     IN      CNAME   g4vps.ampr.org.
#John Greenwood, Bolton, IO83vi
g4xhs.ampr.org. IN      A       44.131.1.12
g4xhs.ampr.     IN      CNAME   g4xhs.ampr.org.
#Mike Skyner, Sandbach, IO83ud
g4ght.ampr.org. IN      A       44.131.1.13
g4ght.ampr.     IN      CNAME   g4ght.ampr.org.
#North West Digipeater, Altrincham,
gb7nwp.ampr.org.        IN      A       44.131.1.14
gb7nwp.ampr.    IN      CNAME   gb7nwp.ampr.org.
#Martin Smith, Poyton, ?
g4fik.ampr.org. IN      A       44.131.1.15
g4fik.ampr.     IN      CNAME   g4fik.ampr.org.
#Alan Yates, Stockport, ?
g3wec.ampr.org. IN      A       44.131.1.16
g3wec.ampr.     IN      CNAME   g3wec.ampr.org.
#Ken Wood, Northwich, IO83rh
g3wcs.ampr.org. IN      A       44.131.1.17
g3wcs.ampr.     IN      CNAME   g3wcs.ampr.org.
#Ian Springle, Congleton, IO83vd
g1opb.ampr.org. IN      A       44.131.1.18
g1opb.ampr.     IN      CNAME   g1opb.ampr.org.
#Dave ?, Penrith, ?
g6bsk.ampr.org. IN      A       44.131.1.19
g6bsk.ampr.     IN      CNAME   g6bsk.ampr.org.
#Alan Abbott, ?, IO83vi
g1gop.ampr.org. IN      A       44.131.1.20
g1gop.ampr.     IN      CNAME   g1gop.ampr.org.
#Dave Wrigley, Rochdale, IO83vo
g6gxk.ampr.org. IN      A       44.131.1.21
g6gxk.ampr.     IN      CNAME   g6gxk.ampr.org.
#Steve Cumberlidge, Hoylake, ?
g7bbf.ampr.org. IN      A       44.131.1.22
g7bbf.ampr.     IN      CNAME   g7bbf.ampr.org.
#Neil ?, ?, ?
g4oar.ampr.org. IN      A       44.131.1.23
g4oar.ampr.     IN      CNAME   g4oar.ampr.org.
#Brian ?, Hoylake, ?
g7bbg.ampr.org. IN      A       44.131.1.24
g7bbg.ampr.     IN      CNAME   g7bbg.ampr.org.
#Phil ?, ?, ?
g0jsb.ampr.org. IN      A       44.131.1.25
g0jsb.ampr.     IN      CNAME   g0jsb.ampr.org.
#Chris ?, ?, ?
g0dvv.ampr.org. IN      A       44.131.1.26
g0dvv.ampr.     IN      CNAME   g0dvv.ampr.org.
#John ?, ?, ?
g8uzz.ampr.org. IN      A       44.131.1.27
g8uzz.ampr.     IN      CNAME   g8uzz.ampr.org.
#Richard ?, ?, ?
g8ndd.ampr.org. IN      A       44.131.1.28
g8ndd.ampr.     IN      CNAME   g8ndd.ampr.org.
#Paul ?, ?, ?
g4dly.ampr.org. IN      A       44.131.1.29
g4dly.ampr.     IN      CNAME   g4dly.ampr.org.
#Jeremy ?, ?, ?
g4noy.ampr.org. IN      A       44.131.1.30
g4noy.ampr.     IN      CNAME   g4noy.ampr.org.
#Julian Ross, Winsford, IO83re
g0lbo.ampr.org. IN      A       44.131.1.31
g0lbo.ampr.     IN      CNAME   g0lbo.ampr.org.
#Hans Field, Winsford, IO83re
g4xfd.ampr.org. IN      A       44.131.1.32
g4xfd.ampr.     IN      CNAME   g4xfd.ampr.org.
#Brian Heslop, Stockport, IO83??
g7ame.ampr.org. IN      A       44.131.1.33
g7ame.ampr.     IN      CNAME   g7ame.ampr.org.
#Andy ?, Bury, ?
g8lir.ampr.org. IN      A       44.131.1.35
g8lir.ampr.     IN      CNAME   g8lir.ampr.org.
#Ron ?, Bury, ?
g4shc.ampr.org. IN      A       44.131.1.36
g4shc.ampr.     IN      CNAME   g4shc.ampr.org.
#John Tumath, Wallasey, ?
g1dbc.ampr.org. IN      A       44.131.1.38
g1dbc.ampr.     IN      CNAME   g1dbc.ampr.org.
#Eddie Wilkinson, Urmston, IO83tk
g4xht.ampr.org. IN      A       44.131.1.39
g4xht.ampr.     IN      CNAME   g4xht.ampr.org.
#Alec Butterworth, Shaw, IO83wn
g4uqc.ampr.org. IN      A       44.131.1.40
g4uqc.ampr.     IN      CNAME   g4uqc.ampr.org.
#Tony Walker, Urmston, IO83tk
g4xdr.ampr.org. IN      A       44.131.1.41
g4xdr.ampr.     IN      CNAME   g4xdr.ampr.org.
#David Tait, Manchester, IO83uk
g0jvy.ampr.org. IN      A       44.131.1.42
g0jvy.ampr.     IN      CNAME   g0jvy.ampr.org.
#Chris Baron, Gt Harwood, IO83ts
g6pwy.ampr.org. IN      A       44.131.1.43
g6pwy.ampr.     IN      CNAME   g6pwy.ampr.org.
#Roger Bulcock, Bury, ?
g6fuq.ampr.org. IN      A       44.131.1.44
g6fuq.ampr.     IN      CNAME   g6fuq.ampr.org.
#Steven Tucker, Sale, ?
g6eld.ampr.org. IN      A       44.131.1.45
g6eld.ampr.     IN      CNAME   g6eld.ampr.org.
#Andrew ?, Staybridge, ?
g6efi.ampr.org. IN      A       44.131.1.46
g6efi.ampr.     IN      CNAME   g6efi.ampr.org.
#Peter ?, Bury, ?
g8aen.ampr.org. IN      A       44.131.1.47
g8aen.ampr.     IN      CNAME   g8aen.ampr.org.
#Gary ?, Radcliffe, ?
g6xky.ampr.org. IN      A       44.131.1.48
g6xky.ampr.     IN      CNAME   g6xky.ampr.org.
#Andy Anderson, Atherton, IO83sm
g6ybc.ampr.org. IN      A       44.131.1.49
g6ybc.ampr.     IN      CNAME   g6ybc.ampr.org.
#Duncan Berry, Leigh, IO83rl
g8jnf.ampr.org. IN      A       44.131.1.50
g8jnf.ampr.     IN      CNAME   g8jnf.ampr.org.
#Dave ?, Bolton, IO83sn
g3tmz.ampr.org. IN      A       44.131.1.51
g3tmz.ampr.     IN      CNAME   g3tmz.ampr.org.
#Dennis Freedman, Manchester, IO83uk
g3vsh.ampr.org. IN      A       44.131.1.52
g3vsh.ampr.     IN      CNAME   g3vsh.ampr.org.
#Brian Curran, Hale, IO83ti
g4oqe.ampr.org. IN      A       44.131.1.53
g4oqe.ampr.     IN      CNAME   g4oqe.ampr.org.
#Bernie ?, Southport, IO83lp
g7dem.ampr.org. IN      A       44.131.1.54
g7dem.ampr.     IN      CNAME   g7dem.ampr.org.
#Les ?, Blackpool, ?
g0ffd.ampr.org. IN      A       44.131.1.55
g0ffd.ampr.     IN      CNAME   g0ffd.ampr.org.
#Roy Morrison, Hyde, ?
g6ckn.ampr.org. IN      A       44.131.1.56
g6ckn.ampr.     IN      CNAME   g6ckn.ampr.org.
#Frank Beesley, Hyde, ?
g8cze.ampr.org. IN      A       44.131.1.57
g8cze.ampr.     IN      CNAME   g8cze.ampr.org.
#Mike Dent, Heysham, IO84nb
g6phf.ampr.org. IN      A       44.131.1.58
g6phf.ampr.     IN      CNAME   g6phf.ampr.org.
#John Greenwood, Bolton, IO83vi
g4xhs2.ampr.org.        IN      A       44.131.1.59
g4xhs2.ampr.    IN      CNAME   g4xhs2.ampr.org.
#Donald Appleton, Wigan, IO83pn
g4kcp.ampr.org. IN      A       44.131.1.60
g4kcp.ampr.     IN      CNAME   g4kcp.ampr.org.
#Dave Staniforth, Heysham, IO84nb
g6crv.ampr.org. IN      A       44.131.1.61
g6crv.ampr.     IN      CNAME   g6crv.ampr.org.
#Peter Jones, Widnes, ?
g1xtj.ampr.org. IN      A       44.131.1.62
g1xtj.ampr.     IN      CNAME   g1xtj.ampr.org.
#David Pryle, Wigan, IO83pm
g7eea.ampr.org. IN      A       44.131.1.63
g7eea.ampr.     IN      CNAME   g7eea.ampr.org.
#Steve Cumberlidge, Moreton, IO83kj
g7bbf2.ampr.org.        IN      A       44.131.1.64
g7bbf2.ampr.    IN      CNAME   g7bbf2.ampr.org.
#Alan ?, Moreton, IO83kj
g1xyp.ampr.org. IN      A       44.131.1.66
g1xyp.ampr.     IN      CNAME   g1xyp.ampr.org.
#Derek ?, ?, ?
g7cwe.ampr.org. IN      A       44.131.1.67
g7cwe.ampr.     IN      CNAME   g7cwe.ampr.org.
#Harold Heath, Ripon, IO94cd
g1oqq.ampr.org. IN      A       44.131.2.1
g1oqq.ampr.     IN      CNAME   g1oqq.ampr.org.
#John Kirk, Leyburn, IO94bg
g4lpq.ampr.org. IN      A       44.131.2.2
g4lpq.ampr.     IN      CNAME   g4lpq.ampr.org.
#Malcolm Newsome, Stillington, IO94kc
g6guw.ampr.org. IN      A       44.131.2.3
g6guw.ampr.     IN      CNAME   g6guw.ampr.org.
#Dave Lockwood, Wakefield, IO93fp
g4cli.ampr.org. IN      A       44.131.2.4
g4cli.ampr.     IN      CNAME   g4cli.ampr.org.
#Phil Green, Sheffield, ?
g4phl.ampr.org. IN      A       44.131.2.5
g4phl.ampr.     IN      CNAME   g4phl.ampr.org.
#Martin Taylor, Leconfield, IO93rv
g3vxn.ampr.org. IN      A       44.131.2.6
g3vxn.ampr.     IN      CNAME   g3vxn.ampr.org.
#Martin Taylor, Leconfield, IO93rv
test.g3vxn.ampr.org.    IN      A       44.131.2.7
test.g3vxn.ampr.        IN      CNAME   test.g3vxn.ampr.org.
#Steve Collins, Leeds, IO93fu
g0fcw.ampr.org. IN      A       44.131.2.8
g0fcw.ampr.     IN      CNAME   g0fcw.ampr.org.
#Mike Parks, Leeds,
g4upd.ampr.org. IN      A       44.131.2.9
g4upd.ampr.     IN      CNAME   g4upd.ampr.org.
#Keith ?, Leeds, ?
g4vrw.ampr.org. IN      A       44.131.2.10
g4vrw.ampr.     IN      CNAME   g4vrw.ampr.org.
#Wakefield Digipeater, Wakefield,
gb7yax.ampr.org.        IN      A       44.131.2.11
gb7yax.ampr.    IN      CNAME   gb7yax.ampr.org.
#Kevin Hawkins, Huddersfield, IO93cp
g8kio.ampr.org. IN      A       44.131.2.12
g8kio.ampr.     IN      CNAME   g8kio.ampr.org.
#Robert Brown, Grimsby, IO93wi
g1sco.ampr.org. IN      A       44.131.2.13
g1sco.ampr.     IN      CNAME   g1sco.ampr.org.
#Rob Bartholomew, Sheffield, IO93hi
g1brv.ampr.org. IN      A       44.131.2.14
g1brv.ampr.     IN      CNAME   g1brv.ampr.org.
#Jim Lodge, Leeds, IO93et
g6xpc.ampr.org. IN      A       44.131.2.15
g6xpc.ampr.     IN      CNAME   g6xpc.ampr.org.
#Ken Collins, Harrogate, IO94fa
g4fip.ampr.org. IN      A       44.131.2.16
g4fip.ampr.     IN      CNAME   g4fip.ampr.org.
#Mike Johnson, Northallerton, IO94gi
g0gck.ampr.org. IN      A       44.131.2.17
g0gck.ampr.     IN      CNAME   g0gck.ampr.org.
#Lloyd Delapp, Harrogate, IO93fx
g0lbu.ampr.org. IN      A       44.131.2.18
g0lbu.ampr.     IN      CNAME   g0lbu.ampr.org.
#Darley ARC, Darley, IO94da
g0fos.ampr.org. IN      A       44.131.2.19
g0fos.ampr.     IN      CNAME   g0fos.ampr.org.
#Ken ?, Leeds, ?
g4oww.ampr.org. IN      A       44.131.2.20
g4oww.ampr.     IN      CNAME   g4oww.ampr.org.
#Doug Shore, Huddersfield, IO93cp
g0eoj.ampr.org. IN      A       44.131.2.21
g0eoj.ampr.     IN      CNAME   g0eoj.ampr.org.
#GB7EXP Gateway, Huddersfield, IO93cp
gb7exp.ampr.org.        IN      A       44.131.2.22
gb7exp.ampr.    IN      CNAME   gb7exp.ampr.org.
#John Goodwin, Sheffield, IO93hi
g6cnx.ampr.org. IN      A       44.131.2.23
g6cnx.ampr.     IN      CNAME   g6cnx.ampr.org.
#Richard Horton, Harrogate, IO93fx
g3xwh.ampr.org. IN      A       44.131.2.24
g3xwh.ampr.     IN      CNAME   g3xwh.ampr.org.
#Bill Dunbar, Harrogate, IO93fx
g4puk.ampr.org. IN      A       44.131.2.25
g4puk.ampr.     IN      CNAME   g4puk.ampr.org.
#Mick Taylor, Allerton Bywate, ?
g0gya.ampr.org. IN      A       44.131.2.26
g0gya.ampr.     IN      CNAME   g0gya.ampr.org.
#John Goodwin, Sheffield, IO93hi
g6cnx.ampr.org. IN      A       44.131.2.27
g6cnx.ampr.     IN      CNAME   g6cnx.ampr.org.
#Andy McMullin, Edgbaston, ?
g8tqh.ampr.org. IN      A       44.131.3.1
g8tqh.ampr.     IN      CNAME   g8tqh.ampr.org.
#Neil Rimmer, Daventry, ?
g4jty.ampr.org. IN      A       44.131.3.2
g4jty.ampr.     IN      CNAME   g4jty.ampr.org.
#Adrian Booth, Tamworth, ?
g4jbx.ampr.org. IN      A       44.131.3.3
g4jbx.ampr.     IN      CNAME   g4jbx.ampr.org.
#?, Tamworth, ?
g8osx.ampr.org. IN      A       44.131.3.4
g8osx.ampr.     IN      CNAME   g8osx.ampr.org.
#R Evans, Lichfield, ?
g8khv.ampr.org. IN      A       44.131.3.5
g8khv.ampr.     IN      CNAME   g8khv.ampr.org.
#Andy Witts, Wolverhampton, IO82vo
g1dil.ampr.org. IN      A       44.131.3.6
g1dil.ampr.     IN      CNAME   g1dil.ampr.org.
#Hayden Bate, Sutton Coldfiel, IO92bn
g8amd.ampr.org. IN      A       44.131.3.7
g8amd.ampr.     IN      CNAME   g8amd.ampr.org.
#Martin Cole, Coventry, IO92gj
g0dkr.ampr.org. IN      A       44.131.3.8
g0dkr.ampr.     IN      CNAME   g0dkr.ampr.org.
#Paul Fisher, Coventry, IO92gk
g6zxd.ampr.org. IN      A       44.131.3.9
g6zxd.ampr.     IN      CNAME   g6zxd.ampr.org.
#Steve ?, Rugby, ?
g8lyb.ampr.org. IN      A       44.131.3.10
g8lyb.ampr.     IN      CNAME   g8lyb.ampr.org.
#Robin ?, Sutton Coldfied, IO92cn
g1ahn.ampr.org. IN      A       44.131.3.11
g1ahn.ampr.     IN      CNAME   g1ahn.ampr.org.
#Brian Lonnon, B'Ham, IO92dm
g3zum.ampr.org. IN      A       44.131.3.12
g3zum.ampr.     IN      CNAME   g3zum.ampr.org.
#Mike Martin, Nuneaton, IO92gl
g4vrq.ampr.org. IN      A       44.131.3.13
g4vrq.ampr.     IN      CNAME   g4vrq.ampr.org.
#Mike Tubby, Worcester, IO82vf
g8tic.ampr.org. IN      A       44.131.3.14
g8tic.ampr.     IN      CNAME   g8tic.ampr.org.
#Jonathan Naylor, Wirksworth, IO93fb
g4klx.ampr.org. IN      A       44.131.4.1
g4klx.ampr.     IN      CNAME   g4klx.ampr.org.
#Mike Wilson, Lincoln, IO93ve
g4gou.ampr.org. IN      A       44.131.4.2
g4gou.ampr.     IN      CNAME   g4gou.ampr.org.
#William Armitage, Nottingham, ?
g8rwk.ampr.org. IN      A       44.131.4.5
g8rwk.ampr.     IN      CNAME   g8rwk.ampr.org.
#Nottingham University, Nottimgham, ?
ux.g3unu.ampr.org.      IN      A       44.131.4.6
ux.g3unu.ampr.  IN      CNAME   ux.g3unu.ampr.org.
#Nottingham University, Nottimgham, ?
pc.g3unu.ampr.org.      IN      A       44.131.4.7
pc.g3unu.ampr.  IN      CNAME   pc.g3unu.ampr.org.
#Nottingham University, Nottimgham, ?
am.g3unu.ampr.org.      IN      A       44.131.4.8
am.g3unu.ampr.  IN      CNAME   am.g3unu.ampr.org.
#Mick Allen, Long Eaton, IO92iv
g4xmh.ampr.org. IN      A       44.131.4.9
g4xmh.ampr.     IN      CNAME   g4xmh.ampr.org.
#GB7LED Digipeater, Long Eaton, IO92iv
gb7led.ampr.org.        IN      A       44.131.4.10
gb7led.ampr.    IN      CNAME   gb7led.ampr.org.
#Andy Soars, Loughborough, IO92js
g4vcn.ampr.org. IN      A       44.131.4.11
g4vcn.ampr.     IN      CNAME   g4vcn.ampr.org.
#Len Fennelow, Wisbech, JO02cq
g0dwi.ampr.org. IN      A       44.131.5.1
g0dwi.ampr.     IN      CNAME   g0dwi.ampr.org.
#Ian Wade, nr Bedford, IO91sx
g3nrw.ampr.org. IN      A       44.131.5.2
g3nrw.ampr.     IN      CNAME   g3nrw.ampr.org.
#Tim Haynes, Luton, ?
g8ptp.ampr.org. IN      A       44.131.5.3
g8ptp.ampr.     IN      CNAME   g8ptp.ampr.org.
#David Brooke, Over nr Cambrid, ?
g6gzh.ampr.org. IN      A       44.131.5.4
g6gzh.ampr.     IN      CNAME   g6gzh.ampr.org.
#Bob Compton, nr Sandy, IO92vc
g1zpu.ampr.org. IN      A       44.131.5.5
g1zpu.ampr.     IN      CNAME   g1zpu.ampr.org.
#Dwight Ernest, Toddington, ?
g0kcu.ampr.org. IN      A       44.131.5.6
g0kcu.ampr.     IN      CNAME   g0kcu.ampr.org.
#Ian Bultitude, Biggleswade, IO92vc
g6khw.ampr.org. IN      A       44.131.5.7
g6khw.ampr.     IN      CNAME   g6khw.ampr.org.
#Dave Bailey, Ely, ?
g0gwo.ampr.org. IN      A       44.131.5.8
g0gwo.ampr.     IN      CNAME   g0gwo.ampr.org.
#Tony Stimson, Banbury, IO92ia
g1bje.ampr.org. IN      A       44.131.5.9
g1bje.ampr.     IN      CNAME   g1bje.ampr.org.
#Bob Lewin, Banbury, IO92ia
g1ydy.ampr.org. IN      A       44.131.5.10
g1ydy.ampr.     IN      CNAME   g1ydy.ampr.org.
#Paul ?, Towcester, ?
g4bki.ampr.org. IN      A       44.131.5.11
g4bki.ampr.     IN      CNAME   g4bki.ampr.org.
#Paul Young, Northampton, ?
g0hwc.ampr.org. IN      A       44.131.5.12
g0hwc.ampr.     IN      CNAME   g0hwc.ampr.org.
#Jon ?, Northampton, ?
g7cia.ampr.org. IN      A       44.131.5.13
g7cia.ampr.     IN      CNAME   g7cia.ampr.org.
#Chris Smith, Biggleswade, IO92vc
g1fef.ampr.org. IN      A       44.131.5.14
g1fef.ampr.     IN      CNAME   g1fef.ampr.org.
#Peter Robinson, Cambridge, JO02be
g3mrx.ampr.org. IN      A       44.131.5.15
g3mrx.ampr.     IN      CNAME   g3mrx.ampr.org.
#Richard Baker, Cambridge, ?
g6fvb.ampr.org. IN      A       44.131.5.16
g6fvb.ampr.     IN      CNAME   g6fvb.ampr.org.
#Phil ?, Earith, ?
g4bik.ampr.org. IN      A       44.131.5.17
g4bik.ampr.     IN      CNAME   g4bik.ampr.org.
#Mike ?, Godmanchester, ?
g3tej.ampr.org. IN      A       44.131.5.18
g3tej.ampr.     IN      CNAME   g3tej.ampr.org.
#Mike Hibbert, Milton, ?
g6coq.ampr.org. IN      A       44.131.5.19
g6coq.ampr.     IN      CNAME   g6coq.ampr.org.
#John Young, St Ives, IO92xi
g4bxn.ampr.org. IN      A       44.131.5.20
g4bxn.ampr.     IN      CNAME   g4bxn.ampr.org.
#Julian Tether, Towcester, IO92mc
g6loh.ampr.org. IN      A       44.131.5.21
g6loh.ampr.     IN      CNAME   g6loh.ampr.org.
#Hazel Tether, Towcester, IO92mc
g1nod.ampr.org. IN      A       44.131.5.22
g1nod.ampr.     IN      CNAME   g1nod.ampr.org.
#Julian Tether, Towcester, IO92mc
g7abi.ampr.org. IN      A       44.131.5.23
g7abi.ampr.     IN      CNAME   g7abi.ampr.org.
#Chris Osborn, Huntingdon, IO92vh
g4uxv.ampr.org. IN      A       44.131.5.24
g4uxv.ampr.     IN      CNAME   g4uxv.ampr.org.
#Mike Ferriday, Reading, IO91lk
g1nqw.ampr.org. IN      A       44.131.6.1
g1nqw.ampr.     IN      CNAME   g1nqw.ampr.org.
#Slough College, Slough, IO91qm
g6cgd.ampr.org. IN      A       44.131.6.2
g6cgd.ampr.     IN      CNAME   g6cgd.ampr.org.
#Paul Taylor, High Wycombe, IO91po
g1plt.ampr.org. IN      A       44.131.6.3
g1plt.ampr.     IN      CNAME   g1plt.ampr.org.
#Paul Shayler, Slough, IO91rm
g6tsf.ampr.org. IN      A       44.131.6.4
g6tsf.ampr.     IN      CNAME   g6tsf.ampr.org.
#Andy Chivers, Penn, IO91pp
g4bio.ampr.org. IN      A       44.131.6.5
g4bio.ampr.     IN      CNAME   g4bio.ampr.org.
#Kevin Quinlan, Hazlemere, IO91pp
g7dzd.ampr.org. IN      A       44.131.6.6
g7dzd.ampr.     IN      CNAME   g7dzd.ampr.org.
#Andy Scott, Chesham, IO91qr
g4tnu.ampr.org. IN      A       44.131.6.7
g4tnu.ampr.     IN      CNAME   g4tnu.ampr.org.
#Andrew ?, Milton Keynes, ?
g8ugc.ampr.org. IN      A       44.131.6.8
g8ugc.ampr.     IN      CNAME   g8ugc.ampr.org.
#Colin ?, Hazlemere, IO91pc
g1lla.ampr.org. IN      A       44.131.6.9
g1lla.ampr.     IN      CNAME   g1lla.ampr.org.
#Peter ?, Olney, IO92od
g1zqn.ampr.org. IN      A       44.131.6.10
g1zqn.ampr.     IN      CNAME   g1zqn.ampr.org.
#? ?, ?, ?
g6xqb.ampr.org. IN      A       44.131.6.11
g6xqb.ampr.     IN      CNAME   g6xqb.ampr.org.
#Mike ?, Hanslope, IO92oc
g1ert.ampr.org. IN      A       44.131.6.12
g1ert.ampr.     IN      CNAME   g1ert.ampr.org.
#Chris Sillence, Bletchley, IO91px
g6wzd.ampr.org. IN      A       44.131.6.13
g6wzd.ampr.     IN      CNAME   g6wzd.ampr.org.
#Paul Taylor, High Wycombe, IO91po
sys2.g1plt.ampr.org.    IN      A       44.131.6.14
sys2.g1plt.ampr.        IN      CNAME   sys2.g1plt.ampr.org.
#Clive Payne, High Wycombe, Bucks, IO91pp
g0gnh.ampr.org. IN      A       44.131.6.15
g0gnh.ampr.     IN      CNAME   g0gnh.ampr.org.
#?, ?, ?
g4pzk.ampr.org. IN      A       44.131.6.251
g4pzk.ampr.     IN      CNAME   g4pzk.ampr.org.
#New Malden Digipeater, New Malden, IO91vj
gb3xp.ampr.org. IN      A       44.131.7.1
gb3xp.ampr.     IN      CNAME   gb3xp.ampr.org.
#Bob Geddes, New Malden, IO91vj
relay.g8ggi.ampr.org.   IN      A       44.131.7.2
relay.g8ggi.ampr.       IN      CNAME   relay.g8ggi.ampr.org.
#Bob Geddes, New Malden, IO91vj
g8ggi.ampr.org. IN      A       44.131.7.3
g8ggi.ampr.     IN      CNAME   g8ggi.ampr.org.
#Edward Batts, Kingston, IO91uk
g8lwy.ampr.org. IN      A       44.131.7.4
g8lwy.ampr.     IN      CNAME   g8lwy.ampr.org.
#Kingston Digipeater, Kingston, IO91uk
gb3kp.ampr.org. IN      A       44.131.7.5
gb3kp.ampr.     IN      CNAME   gb3kp.ampr.org.
#Kelvin Hill, Farnham, IO91oe
g1emm.ampr.org. IN      A       44.131.7.6
g1emm.ampr.     IN      CNAME   g1emm.ampr.org.
#Paul Dicken, Cobham, IO91ti
g1pcd.ampr.org. IN      A       44.131.7.7
g1pcd.ampr.     IN      CNAME   g1pcd.ampr.org.
#John Danks, Surbiton,
g5ds.ampr.org.  IN      A       44.131.7.8
g5ds.ampr.      IN      CNAME   g5ds.ampr.org.
#Don Fields, Henley on Thame, IO91mm
g3xtt.ampr.org. IN      A       44.131.7.9
g3xtt.ampr.     IN      CNAME   g3xtt.ampr.org.
#John Baker, Reigate, IO91vf
g0hwo.ampr.org. IN      A       44.131.7.10
g0hwo.ampr.     IN      CNAME   g0hwo.ampr.org.
#Colin Wantling, Camberley, IO91ph
g3tne.ampr.org. IN      A       44.131.7.11
g3tne.ampr.     IN      CNAME   g3tne.ampr.org.
#Ian Matheson, Camberley, IO91ph
g3rra.ampr.org. IN      A       44.131.7.12
g3rra.ampr.     IN      CNAME   g3rra.ampr.org.
#Justin Brickwood, Camberley, IO91ph
g1ttg.ampr.org. IN      A       44.131.7.13
g1ttg.ampr.     IN      CNAME   g1ttg.ampr.org.
#?, Camberley, ?
g8kwi.ampr.org. IN      A       44.131.7.14
g8kwi.ampr.     IN      CNAME   g8kwi.ampr.org.
#Tim Fitzgerald, Camberley, IO91pi
g4uqe.ampr.org. IN      A       44.131.7.15
g4uqe.ampr.     IN      CNAME   g4uqe.ampr.org.
#John Holton, Farnham, IO91of
g8ogr.ampr.org. IN      A       44.131.7.16
g8ogr.ampr.     IN      CNAME   g8ogr.ampr.org.
#Mike Willis, Guildford, IO91QF
g6vdo.ampr.org. IN      A       44.131.7.17
g6vdo.ampr.     IN      CNAME   g6vdo.ampr.org.
#Kelvin Hill, Farnham, IO91oe
g1emm2.ampr.org.        IN      A       44.131.7.18
g1emm2.ampr.    IN      CNAME   g1emm2.ampr.org.
#Ignatius Tan, Catford, ?
g7gbq.ampr.org. IN      A       44.131.7.19
g7gbq.ampr.     IN      CNAME   g7gbq.ampr.org.
#Ignatius Tan, Catford, ?
pc.g7gbq.ampr.org.      IN      A       44.131.7.20
pc.g7gbq.ampr.  IN      CNAME   pc.g7gbq.ampr.org.
#Keith Brazington, Rochester, JO01gj
g4lzv.ampr.org. IN      A       44.131.8.1
g4lzv.ampr.     IN      CNAME   g4lzv.ampr.org.
#Ashford Digipeater, Ashford, ?
gb7ck.ampr.org. IN      A       44.131.8.2
gb7ck.ampr.     IN      CNAME   gb7ck.ampr.org.
#Keith Brazington, Rochester, JO01gj
g4lzv2.ampr.org.        IN      A       44.131.8.3
g4lzv2.ampr.    IN      CNAME   g4lzv2.ampr.org.
#Smudge Lundegard, Swanley, JO01di
g3gjw.ampr.org. IN      A       44.131.8.4
g3gjw.ampr.     IN      CNAME   g3gjw.ampr.org.
#Dave Turner, Ashford, ?
g4idx.ampr.org. IN      A       44.131.8.5
g4idx.ampr.     IN      CNAME   g4idx.ampr.org.
#Sue Squibb, Teynham, JO1ji
g1tzu.ampr.org. IN      A       44.131.8.6
g1tzu.ampr.     IN      CNAME   g1tzu.ampr.org.
#Geoff Squibb, Teynham, JO01ji
g4mpa.ampr.org. IN      A       44.131.8.6
g4mpa.ampr.     IN      CNAME   g4mpa.ampr.org.
#Tony Kempton, Bromley, JO01aj
g1bys.ampr.org. IN      A       44.131.8.7
g1bys.ampr.     IN      CNAME   g1bys.ampr.org.
#John Wellard, Canterbury, JO01oh
g6zaa.ampr.org. IN      A       44.131.8.8
g6zaa.ampr.     IN      CNAME   g6zaa.ampr.org.
#Phil Coull, Folkestone,
g3xvy.ampr.org. IN      A       44.131.8.9
g3xvy.ampr.     IN      CNAME   g3xvy.ampr.org.
#Quentin North, Brighton,
g1ikj.ampr.org. IN      A       44.131.8.10
g1ikj.ampr.     IN      CNAME   g1ikj.ampr.org.
#Rob ?, Dover, ?
g4fxe.ampr.org. IN      A       44.131.8.11
g4fxe.ampr.     IN      CNAME   g4fxe.ampr.org.
#Derek ?, Bromley, JO01ak
g1hsn.ampr.org. IN      A       44.131.8.12
g1hsn.ampr.     IN      CNAME   g1hsn.ampr.org.
#Bill Green, Biggin Hill, JO01ah
g3tdg.ampr.org. IN      A       44.131.8.13
g3tdg.ampr.     IN      CNAME   g3tdg.ampr.org.
#Tony Kempton, Bromley, JO01aj
g1bys-1.ampr.org.       IN      A       44.131.8.14
g1bys-1.ampr.   IN      CNAME   g1bys-1.ampr.org.
#Christopher Leigh, Beckenham, ?
g1vsl.ampr.org. IN      A       44.131.8.15
g1vsl.ampr.     IN      CNAME   g1vsl.ampr.org.
#Nick Lawes, Crayford, JO01dj
g8zhr.ampr.org. IN      A       44.131.8.16
g8zhr.ampr.     IN      CNAME   g8zhr.ampr.org.
#Ray Euden, Erith, ?
g6jha.ampr.org. IN      A       44.131.8.17
g6jha.ampr.     IN      CNAME   g6jha.ampr.org.
#Nigel Mundy, Burgess Hill, IO90wx
g1tdm.ampr.org. IN      A       44.131.8.18
g1tdm.ampr.     IN      CNAME   g1tdm.ampr.org.
#Mike Mundy, Burgess Hill, IO90wx
g0gnv.ampr.org. IN      A       44.131.8.19
g0gnv.ampr.     IN      CNAME   g0gnv.ampr.org.
#Burgess Hill Digipeater, Burgess Hill, IO90wx
gb7zzz.ampr.org.        IN      A       44.131.8.20
gb7zzz.ampr.    IN      CNAME   gb7zzz.ampr.org.
#Chris Kenny, Hove, IO90vu
g3ljk.ampr.org. IN      A       44.131.8.21
g3ljk.ampr.     IN      CNAME   g3ljk.ampr.org.
#Peter Meiring, Plymouth, IO70wj
g0bsx.ampr.org. IN      A       44.131.9.1
g0bsx.ampr.     IN      CNAME   g0bsx.ampr.org.
#Barry Cresswell, Plymouth, IO70wh
g1mrg.ampr.org. IN      A       44.131.9.2
g1mrg.ampr.     IN      CNAME   g1mrg.ampr.org.
#Simon Rodda, Penzance,
g4pem.ampr.org. IN      A       44.131.9.3
g4pem.ampr.     IN      CNAME   g4pem.ampr.org.
#Iain Dunsworth, Saltash, IO79vj
g4snl.ampr.org. IN      A       44.131.9.4
g4snl.ampr.     IN      CNAME   g4snl.ampr.org.
#Stuart Charles, Plymouth, IO70wj
g8nvw.ampr.org. IN      A       44.131.9.5
g8nvw.ampr.     IN      CNAME   g8nvw.ampr.org.
#John Veale, Plymouth, ?
g4sca.ampr.org. IN      A       44.131.9.6
g4sca.ampr.     IN      CNAME   g4sca.ampr.org.
#Major ?, Beer, ?
g1dii.ampr.org. IN      A       44.131.9.7
g1dii.ampr.     IN      CNAME   g1dii.ampr.org.
#Ray ?, Launceston,
g6ujb.ampr.org. IN      A       44.131.9.8
g6ujb.ampr.     IN      CNAME   g6ujb.ampr.org.
#Fred Bourne, Plymouth, IO70vj
g3yjq.ampr.org. IN      A       44.131.9.9
g3yjq.ampr.     IN      CNAME   g3yjq.ampr.org.
#Nick Smith, Plymouth, IO70wj
g7auq.ampr.org. IN      A       44.131.9.10
g7auq.ampr.     IN      CNAME   g7auq.ampr.org.
#Peter Meiring, Plymouth, IO70wj
pc.g0bsx.ampr.org.      IN      A       44.131.9.11
pc.g0bsx.ampr.  IN      CNAME   pc.g0bsx.ampr.org.
#Tony Glover, Plymouth, IO70wj
g0dwk.ampr.org. IN      A       44.131.9.12
g0dwk.ampr.     IN      CNAME   g0dwk.ampr.org.
#John Bewley, Plymouth, IO70vj
g1sqi.ampr.org. IN      A       44.131.9.13
g1sqi.ampr.     IN      CNAME   g1sqi.ampr.org.
#John Woods, Plymouth, ?
g3tgr.ampr.org. IN      A       44.131.9.14
g3tgr.ampr.     IN      CNAME   g3tgr.ampr.org.
#Peter ?, Exeter, ?
g7agm.ampr.org. IN      A       44.131.9.15
g7agm.ampr.     IN      CNAME   g7agm.ampr.org.
#Allan Baker, Plymouth, ?
g3kfn.ampr.org. IN      A       44.131.9.16
g3kfn.ampr.     IN      CNAME   g3kfn.ampr.org.
#Tony King, Plymouth, IO70wj
g7any.ampr.org. IN      A       44.131.9.17
g7any.ampr.     IN      CNAME   g7any.ampr.org.
#Dave Morgan, Exmouth, IO80hp
g7bwo.ampr.org. IN      A       44.131.9.18
g7bwo.ampr.     IN      CNAME   g7bwo.ampr.org.
#Ken ?, ?, ?
g4mpq.ampr.org. IN      A       44.131.9.19
g4mpq.ampr.     IN      CNAME   g4mpq.ampr.org.
#Tony Rider, Ipplepen, ?
g6glp.ampr.org. IN      A       44.131.9.20
g6glp.ampr.     IN      CNAME   g6glp.ampr.org.
#Phil ?, ?, ?
g0kdt.ampr.org. IN      A       44.131.9.21
g0kdt.ampr.     IN      CNAME   g0kdt.ampr.org.
#David Reed, Plymouth, ?
g4ydr.ampr.org. IN      A       44.131.9.22
g4ydr.ampr.     IN      CNAME   g4ydr.ampr.org.
#Mike Waterfall, Redruth, ?
g8nxd.ampr.org. IN      A       44.131.9.23
g8nxd.ampr.     IN      CNAME   g8nxd.ampr.org.
#Peter ?, St Tudy, ?
g4axc.ampr.org. IN      A       44.131.9.24
g4axc.ampr.     IN      CNAME   g4axc.ampr.org.
#Ray ?, Exeter, ?
g3ybk.ampr.org. IN      A       44.131.9.25
g3ybk.ampr.     IN      CNAME   g3ybk.ampr.org.
#Tim ?, Launceston, ?
g1zlh.ampr.org. IN      A       44.131.9.26
g1zlh.ampr.     IN      CNAME   g1zlh.ampr.org.
#Maurice ?, ?, ?
g3iue.ampr.org. IN      A       44.131.9.27
g3iue.ampr.     IN      CNAME   g3iue.ampr.org.
#Joe Jones, Plymouth, ?
g1rxr.ampr.org. IN      A       44.131.9.28
g1rxr.ampr.     IN      CNAME   g1rxr.ampr.org.
#Graham Jones, Swansea, ?
gw4uck.ampr.org.        IN      A       44.131.10.1
gw4uck.ampr.    IN      CNAME   gw4uck.ampr.org.
#Ray Gordon, Swansea, ?
gw1xrn.ampr.org.        IN      A       44.131.10.2
gw1xrn.ampr.    IN      CNAME   gw1xrn.ampr.org.
#Univ College Swansea, Swansea, ?
gw3uws.ampr.org.        IN      A       44.131.10.3
gw3uws.ampr.    IN      CNAME   gw3uws.ampr.org.
#Richard Artym, Swansea, ?
gw7exm.ampr.org.        IN      A       44.131.10.4
gw7exm.ampr.    IN      CNAME   gw7exm.ampr.org.
#Gavin Stewart, Belfast, IO74an
gi4tvv.ampr.org.        IN      A       44.131.15.1
gi4tvv.ampr.    IN      CNAME   gi4tvv.ampr.org.
#Ivan Andrews, Chelmsford, JO01mr
g6aal.ampr.org. IN      A       44.131.16.1
g6aal.ampr.     IN      CNAME   g6aal.ampr.org.
#Dirk Koopman, East Dereham, JO02lq
g1tlh.ampr.org. IN      A       44.131.16.2
g1tlh.ampr.     IN      CNAME   g1tlh.ampr.org.
#Richard ?, nr Harlow, ?
g6tcj.ampr.org. IN      A       44.131.16.3
g6tcj.ampr.     IN      CNAME   g6tcj.ampr.org.
#John Melton, Southminster, JO01jq
n6lyt.ampr.org. IN      A       44.131.16.4
n6lyt.ampr.     IN      CNAME   n6lyt.ampr.org.
#John Sager, Ipswich, JO02pa
g8onh.ampr.org. IN      A       44.131.16.5
g8onh.ampr.     IN      CNAME   g8onh.ampr.org.
#Ipswich Digipeater, Ipswich, JO02ob
gb7mx.ampr.org. IN      A       44.131.16.6
gb7mx.ampr.     IN      CNAME   gb7mx.ampr.org.
#John Lord, Bury St Edmonds, JO02ig
g4xrk.ampr.org. IN      A       44.131.16.7
g4xrk.ampr.     IN      CNAME   g4xrk.ampr.org.
#?, Mildenhall, JO02gj
g4zgy.ampr.org. IN      A       44.131.16.8
g4zgy.ampr.     IN      CNAME   g4zgy.ampr.org.
#Colin Ferryman, Colchester, JO01kw
g4diw.ampr.org. IN      A       44.131.16.9
g4diw.ampr.     IN      CNAME   g4diw.ampr.org.
#Peter ?, ?, JO01bk
g1uws.ampr.org. IN      A       44.131.16.10
g1uws.ampr.     IN      CNAME   g1uws.ampr.org.
#Neal ?, ?, JO02FI
g0brm.ampr.org. IN      A       44.131.16.11
g0brm.ampr.     IN      CNAME   g0brm.ampr.org.
#Nick Martin, Saffron Walden, ?
g6nhk.ampr.org. IN      A       44.131.16.12
g6nhk.ampr.     IN      CNAME   g6nhk.ampr.org.
#Nigel Hinderwell, Witham, JO01ht
g8ifn.ampr.org. IN      A       44.131.16.13
g8ifn.ampr.     IN      CNAME   g8ifn.ampr.org.
#Charles Brain, Chelmsford, JO01gr
g4guo.ampr.org. IN      A       44.131.16.14
g4guo.ampr.     IN      CNAME   g4guo.ampr.org.
#Malcolm Salmon, Witham, JO01ht
g3xvv.ampr.org. IN      A       44.131.16.15
g3xvv.ampr.     IN      CNAME   g3xvv.ampr.org.
#Dave Castle, Chelmsford, JO01fs
g6oqj.ampr.org. IN      A       44.131.16.16
g6oqj.ampr.     IN      CNAME   g6oqj.ampr.org.
#Alan Heaysman, Chelmsford, JO01fs
g1ibp.ampr.org. IN      A       44.131.16.17
g1ibp.ampr.     IN      CNAME   g1ibp.ampr.org.
#Nigel Hull, Chelmsford, JO01fr
g6zvv.ampr.org. IN      A       44.131.16.18
g6zvv.ampr.     IN      CNAME   g6zvv.ampr.org.
#Ted Hansen, Braintree, JO01gv
g8npf.ampr.org. IN      A       44.131.16.19
g8npf.ampr.     IN      CNAME   g8npf.ampr.org.
#John Ray, Loughton, JO01ap
g8dzh.ampr.org. IN      A       44.131.16.20
g8dzh.ampr.     IN      CNAME   g8dzh.ampr.org.
#SAMAIR Club, Braintree, JO01gv
g7dwb.ampr.org. IN      A       44.131.16.21
g7dwb.ampr.     IN      CNAME   g7dwb.ampr.org.
#Brian Wiseman, Basingstoke, IO91kf
g6kqz.ampr.org. IN      A       44.131.17.1
g6kqz.ampr.     IN      CNAME   g6kqz.ampr.org.
#Clive Sanders, Southampton, ?
g4kcm.ampr.org. IN      A       44.131.17.2
g4kcm.ampr.     IN      CNAME   g4kcm.ampr.org.
#Iain Dunsworth, Saltash, IO79vj
g4snl2.ampr.org.        IN      A       44.131.17.3
g4snl2.ampr.    IN      CNAME   g4snl2.ampr.org.
#Ed Harland, Weymouth, IO80ro
g3vpf.ampr.org. IN      A       44.131.17.4
g3vpf.ampr.     IN      CNAME   g3vpf.ampr.org.
#Lloyd Arrow, Southsea, IO90lt
g1jar.ampr.org. IN      A       44.131.17.5
g1jar.ampr.     IN      CNAME   g1jar.ampr.org.
#?, Bishops Waltham,
g4zrt.ampr.org. IN      A       44.131.17.6
g4zrt.ampr.     IN      CNAME   g4zrt.ampr.org.
#Jim ?, Basingstoke, IO91kf
g1wkk.ampr.org. IN      A       44.131.17.7
g1wkk.ampr.     IN      CNAME   g1wkk.ampr.org.
#Ron Collins, Farnborough, ?
g6vug.ampr.org. IN      A       44.131.17.8
g6vug.ampr.     IN      CNAME   g6vug.ampr.org.
#Penny Collins, Farnborough, ?
g1bpk.ampr.org. IN      A       44.131.17.9
g1bpk.ampr.     IN      CNAME   g1bpk.ampr.org.
#Mathew Walden, Alton, IO91md
g4xwv.ampr.org. IN      A       44.131.17.10
g4xwv.ampr.     IN      CNAME   g4xwv.ampr.org.
#Richard Simpson, Farnborough, IO91pg
g1dgl.ampr.org. IN      A       44.131.17.11
g1dgl.ampr.     IN      CNAME   g1dgl.ampr.org.
#Stan Pratt, Fareham, IO90jv
g7drd.ampr.org. IN      A       44.131.17.14
g7drd.ampr.     IN      CNAME   g7drd.ampr.org.
#? ?, ?, ?
g1maa.ampr.org. IN      A       44.131.17.100
g1maa.ampr.     IN      CNAME   g1maa.ampr.org.
#Andrew ?, Sunderland, IO94hu
g4nxh.ampr.org. IN      A       44.131.18.1
g4nxh.ampr.     IN      CNAME   g4nxh.ampr.org.
#Neil Imrie, Guisborough, IO94mm
g7doj.ampr.org. IN      A       44.131.18.2
g7doj.ampr.     IN      CNAME   g7doj.ampr.org.
#Gordon ?, Stockton on Tee, IO94in
g0bzc.ampr.org. IN      A       44.131.18.3
g0bzc.ampr.     IN      CNAME   g0bzc.ampr.org.
#Andrew ?, Sunderland, IO94hu
pc.g4nxh.ampr.org.      IN      A       44.131.18.4
pc.g4nxh.ampr.  IN      CNAME   pc.g4nxh.ampr.org.
#Neil Imrie, Guisborough, IO94mm
pc.g7doj.ampr.org.      IN      A       44.131.18.5
pc.g7doj.ampr.  IN      CNAME   pc.g7doj.ampr.org.
#Joe Gordon, Sunderland, IO94hv
g4lia.ampr.org. IN      A       44.131.18.6
g4lia.ampr.     IN      CNAME   g4lia.ampr.org.
#Terry Elliott, Sunderland, IO94hv
g0ehx.ampr.org. IN      A       44.131.18.7
g0ehx.ampr.     IN      CNAME   g0ehx.ampr.org.
#Jim Emerson, Sunderland, IO94hw
g0ban.ampr.org. IN      A       44.131.18.8
g0ban.ampr.     IN      CNAME   g0ban.ampr.org.
#Steve Green, Sunderland, IO94gu
g4ekm.ampr.org. IN      A       44.131.18.9
g4ekm.ampr.     IN      CNAME   g4ekm.ampr.org.
#Alan Johnson, Sunderland, IO95dw
g7aem.ampr.org. IN      A       44.131.18.10
g7aem.ampr.     IN      CNAME   g7aem.ampr.org.
#John Foster, Hartlepool, IO94jp
g0fzz.ampr.org. IN      A       44.131.18.11
g0fzz.ampr.     IN      CNAME   g0fzz.ampr.org.
#Bernie McIntosh, Stockton, IO94hn
g4wzg.ampr.org. IN      A       44.131.18.12
g4wzg.ampr.     IN      CNAME   g4wzg.ampr.org.
#Peter Przybyla, Washington, IO94fv
g0epp.ampr.org. IN      A       44.131.18.13
g0epp.ampr.     IN      CNAME   g0epp.ampr.org.
#Ken Robinson, Cramlington, IO95ea
g0lce.ampr.org. IN      A       44.131.18.14
g0lce.ampr.     IN      CNAME   g0lce.ampr.org.
#Peter Duncan, Sunderland, IO94gv
g4hix.ampr.org. IN      A       44.131.18.15
g4hix.ampr.     IN      CNAME   g4hix.ampr.org.
#Dail Przybyla, Gateshead, IO94fw
g1adp.ampr.org. IN      A       44.131.18.16
g1adp.ampr.     IN      CNAME   g1adp.ampr.org.
#Harry Whitfield, Consett, IO94bv
g6auc.ampr.org. IN      A       44.131.18.17
g6auc.ampr.     IN      CNAME   g6auc.ampr.org.
#Gareth Howell, Letchworth, IO91vx
g6kvk.ampr.org. IN      A       44.131.19.1
g6kvk.ampr.     IN      CNAME   g6kvk.ampr.org.
#Hugh Davies, St Albans, ?
g0cnr.ampr.org. IN      A       44.131.19.2
g0cnr.ampr.     IN      CNAME   g0cnr.ampr.org.
#Rod Hewitt, Ware, JO01at
g6ttd.ampr.org. IN      A       44.131.19.3
g6ttd.ampr.     IN      CNAME   g6ttd.ampr.org.
#Rod Hewitt, Ware, JO01at
g6ttd2.ampr.org.        IN      A       44.131.19.4
g6ttd2.ampr.    IN      CNAME   g6ttd2.ampr.org.
#Nigel Leaney, Buntingford, IO91xw
g1jkf.ampr.org. IN      A       44.131.19.5
g1jkf.ampr.     IN      CNAME   g1jkf.ampr.org.
#K Jones, London, JO01ao
g1sls.ampr.org. IN      A       44.131.19.6
g1sls.ampr.     IN      CNAME   g1sls.ampr.org.
#Phil Webber, St Albans, IO
g8klc.ampr.org. IN      A       44.131.19.7
g8klc.ampr.     IN      CNAME   g8klc.ampr.org.
#Bob Holton, Northwood, IO91to
g0bst.ampr.org. IN      A       44.131.19.8
g0bst.ampr.     IN      CNAME   g0bst.ampr.org.
#Ray Gordon, Edgware,
g1xrn.ampr.org. IN      A       44.131.19.9
g1xrn.ampr.     IN      CNAME   g1xrn.ampr.org.
#Keith Maton, Ealing, IO91um
g6nhu.ampr.org. IN      A       44.131.19.10
g6nhu.ampr.     IN      CNAME   g6nhu.ampr.org.
#Andy Adamson, Stevenage, IO91vw
g4spv.ampr.org. IN      A       44.131.19.11
g4spv.ampr.     IN      CNAME   g4spv.ampr.org.
#Mike Waterman, Letchworth, IO91vx
g6adx.ampr.org. IN      A       44.131.19.12
g6adx.ampr.     IN      CNAME   g6adx.ampr.org.
#Steve Richards, Reed, IO92xa
g4hpe.ampr.org. IN      A       44.131.19.13
g4hpe.ampr.     IN      CNAME   g4hpe.ampr.org.
#Steve McIver, East Ham,
g1sju.ampr.org. IN      A       44.131.19.14
g1sju.ampr.     IN      CNAME   g1sju.ampr.org.
#Mike Faithfull, Hatfield, ?
g6ubh.ampr.org. IN      A       44.131.19.15
g6ubh.ampr.     IN      CNAME   g6ubh.ampr.org.
#John Musgrave, Baldock, ?
g6kbs.ampr.org. IN      A       44.131.19.16
g6kbs.ampr.     IN      CNAME   g6kbs.ampr.org.
#Gareth Howell, Letchworth, IO91vx
ppc.g6kvk.ampr.org.     IN      A       44.131.19.17
ppc.g6kvk.ampr. IN      CNAME   ppc.g6kvk.ampr.org.
#Richard Wickham, Hitchin, IO91uw
g4jqb.ampr.org. IN      A       44.131.19.21
g4jqb.ampr.     IN      CNAME   g4jqb.ampr.org.
#S Blackmore, Hertford, IO91xu
g4tio.ampr.org. IN      A       44.131.19.22
g4tio.ampr.     IN      CNAME   g4tio.ampr.org.
#Andy Rutter, London, IO91wo
g8hck.ampr.org. IN      A       44.131.19.23
g8hck.ampr.     IN      CNAME   g8hck.ampr.org.
#The Instruction Set RC, London, IO91wn
g7bdh.ampr.org. IN      A       44.131.19.24
g7bdh.ampr.     IN      CNAME   g7bdh.ampr.org.
#Andy Rutter, London, IO91wo
g8hck2.ampr.org.        IN      A       44.131.19.25
g8hck2.ampr.    IN      CNAME   g8hck2.ampr.org.
#Mike Banahan, London, IO91vl
g4buh.ampr.org. IN      A       44.131.19.26
g4buh.ampr.     IN      CNAME   g4buh.ampr.org.
#Chris Rutt, Hatfield, IO91vr
g0amg.ampr.org. IN      A       44.131.19.27
g0amg.ampr.     IN      CNAME   g0amg.ampr.org.
#Martin Stubbs, ?, ?
g8imb.ampr.org. IN      A       44.131.20.1
g8imb.ampr.     IN      CNAME   g8imb.ampr.org.
#David Hough, Bristol, IO81sm
g4wrw.ampr.org. IN      A       44.131.20.2
g4wrw.ampr.     IN      CNAME   g4wrw.ampr.org.
#Mike Chace, Bath, IO81tj
g6dhu.ampr.org. IN      A       44.131.20.3
g6dhu.ampr.     IN      CNAME   g6dhu.ampr.org.
#Steve Gibbs, Vale, ?
gu3mbs.ampr.org.        IN      A       44.131.21.1
gu3mbs.ampr.    IN      CNAME   gu3mbs.ampr.org.
#Chris ?, ?, ?
gu4ymv.ampr.org.        IN      A       44.131.21.2
gu4ymv.ampr.    IN      CNAME   gu4ymv.ampr.org.
#Guernsey Digipeater, ?, ?
gb7gur.ampr.org.        IN      A       44.131.21.3
gb7gur.ampr.    IN      CNAME   gb7gur.ampr.org.

                                   FTPUSERS

# F T P U S E R S
#
# Note: NET.EXE ignores all lines which start with a pound sign (#).
#
#
# The FTPUSERS file provides access control over the users of
# your host computer. It consists of 4 elements:
#        username    password    /path     permissions
#
# where
#      username is the users's login name for ftp
#       password is the password they are required to
#                use. A password of '*' allows anything
#                typed to be accepted.
#       /path is the allowable prefix on accessible files.
#                Think of this as the root of the directory
#                subtree this user is allowed to access.
#       permissions is a decimal number granting permission
#                for read, create, and write operations.
#                Bit 0x1 is read, bit 0x2 is create if not
#                overwriting, bit 0x4 allows overwriting an
#                existing file, and deleting files.
#                For example: a user with read AND create
#                would have a permission of 3 (1+2). A user
#                with full read/write/overwrite would have a
#                permission of 7 (1+2+4). Until such time as
#                an encryption system for passwords is
#                incorporated into TCP/IP caution should be
#                used in authorizing full access to your
#                system.
#
#----------------------------------------------
#
# This first entry is used to define a user "anonymous", who has read-only
# access to a directory which you have set up and arbitrarily named 'public',
# and all subdirectories of 'public'. In effect this is his root directory
# on your system.  This is the default entry everyone should have, so that
# new users who don't have a specific entry in this file can still get in
# and look at what's available, download a few things, etc.  When logging in
# to a machine using this entry, use your callsign or something else unique
# as the password, to identify yourself. Any password will work since there
# is a "*" in the password field.
#
anonymous * /public 3
#
bbs * /bbs 3
#
# The following entry for kelvin with a password of dummy has full
# access to your root directory and full read/write/overwrite/delete
# functions. You'll want to think twice before giving this access to
# others :-) .
#
kelvin dummy / 7
g1emm yy101179 / 255
#
# The following entry for guest with a password of guest has read and
# write access to /public and all its subdirectores.
# This is a good entry for someone
# you trust to upload files to your system, but who you don't want deleting
# things that are already there.
#
guest guest /public 3
colin g3tne / 3
ian g3rra / 3
bob g8ggi / 3
paul g1pcd / 3
ron g6vug / 3
brian g6kqz / 3
#
# THE END

                                  NODES.ARP

#---------------------------------------------------
#
# Define the mapping of internal host names to the 'real world' names.
#
arp add [44.131.0.0] ax25 qst
arp add g0gnh ax25 g0gnh
arp add g0gnh netrom g0gnh
arp add g1bys ax25 g1bys
arp add g1bys netrom g1bys
arp add g1maa ax25 g1maa
arp add g1maa netrom g1maa
arp add g1plt ax25 g1plt
arp add g1plt netrom g1plt
arp add g1ttg ax25 g1ttg
arp add g1ttg netrom g1ttg
arp add g1wkk ax25 g1wkk-1
arp add g1wkk netrom g1wkk-1
arp add g3rra ax25 g3rra
arp add g3rra netrom g3rra
arp add g3tne ax25 g3tne
arp add g3tne netrom g3tne
arp add g4bio ax25 g4bio
arp add g4bio netrom g4bio
arp add g4tnu ax25 g4tnu
arp add g4tnu netrom g4tnu
arp add g4uqe ax25 g4uqe
arp add g4uqe netrom g4uqe
arp add g4pzk ax25 g4pzk
arp add g4pzk netrom g4pzk
arp add g4xwv ax25 g4xwv
arp add g4xwv netrom g4xwv
arp add g5ds ax25 g5ds
arp add g5ds netrom g5ds
arp add g6kqz ax25 g6kqz
arp add g6kqz netrom g6kqz
arp add g6kvk ax25 g6kvk-1
arp add g6kvk netrom g6kvk-1
arp add g6vug ax25 g6vug
arp add g6vug netrom g6vug
arp add g7gbq netrom g7gbq
arp add g8kwi ax25 g8kwi
arp add g8kwi netrom g8kwi
arp add g8ogr ax25 g8ogr
arp add g8ogr netrom g8ogr
arp add g8zhr ax25 g8zhr
arp add g8zhr netrom g8zhr
arp add g1emm2 ax25 g1emm-2
arp add g1emm2 netrom g1emm-2
arp add gb3xp ax25 g8ggi-1
arp add gb3xp netrom gb3xp-1
arp add g6xqb ax25 g6xqb
arp add g6xqb netrom g6xqb
#
#---------------------------------------------------
#
# The END
#

                                  NODES.FIL

#---------------------------------------------------
#
# Define the NET/ROM view of the 'real world'.
#
netrom nodefilter add g1emm-2 tnc 255
netrom nodefilter add g1plt tnc 40
netrom nodefilter add g1wkk-1 tnc 90
netrom nodefilter add g3rra tnc 80
netrom nodefilter add g4bio tnc 100
netrom nodefilter add g6vug tnc 30
netrom nodefilter add g8kwi tnc 100
netrom nodefilter add g6xqb tnc 100
#
#---------------------------------------------------
#
# The END
#

                                  NODES.ROU

#---------------------------------------------------
#
# Define the 'real world' routing to other remote nodes.
#
route add g1emm loopback
#
route add g4bio tnc
route add g1wkk tnc
#
# route addprivate g6xqb tnc
# route addprivate g6hpe tnc
#
route addprivate g3rra tnc
route addprivate g8kwi tnc
route addprivate g1ttg tnc
#
route addprivate g1bys netrom
route addprivate g1plt netrom
route addprivate g6kqz netrom
route addprivate g6kvk netrom
route addprivate g8zhr netrom
route addprivate gb3xp netrom
route addprivate g4pzk netrom
route addprivate g4lzv netrom
route addprivate g4tnu netrom
route addprivate g7gbq netrom
route addprivate g0gnh netrom
#
#---------------------------------------------------
#
# The END
#

                                  PRIVS.DOC

                         /* Permission flag bits */

#define FTP_READ        1       /* Read files */
#define FTP_CREATE      2       /* Create new files */
#define FTP_WRITE       4       /* Overwrite or delete existing files */
#define AX25_CMD        8       /* Allow use of (G)ateway */
#define TELNET_CMD      16      /* Allow use of (T)elnet */
#define NETROM_CMD      32      /* Allow use of (N)etrom */
#define SYSOP_CMD       64      /* Allow use of @ command & sysop privs */