HISTORY NETchl  ordered by command/subject          17 may 1995
==========================================

Below you will find the history of NETchl by Rob, PE1CHL.
The history made bij Rob is ordered by time (version). This makes finding
changes and additions made in commands and the NET software not very easy.
The fastest way to find info about a subject is using the search facility from
a suitable editor. This is why I decided to put everything together by subject,
it makes finding info about changes in NETchl a lot easier.
Not all the info mentioned in the history are in this history by
subject. Not mentioned are bugfixes and subject like the framesammler and EMS
in the PC-version. Both are taken out NETchl after much trouble with it.
All the general information is gathered together. The specific info about a
version (Atari, PC, Unix) are gathered at the end of the document.
The first version was released after version 930430. This second release
has been updated until version 950429.


73' Thomas PA3CEF@PI8DRE






NB
- All commands are partly given in CAPITAL letters for easy recognition in the
  text. You will know that all the commands in NETchl have to be given in
  lowercase letters.


        Contents
        ========
        net> commands   ARP             general, proxy
                        AT
                        ATTACH          general, com, encap, kiss, packet
                        AX25            general, exclude, lq, lqdump,
                                        maxframe, mbox, persist, status
                                        start tnc2, t1 t2, txq, uigrab
                        BROADCAST       general, abort, blocktype,
                                        cleanup, complete, download,
                                        ihave, kick, post, request,
                                        server, start, status, stop, trace
                        CLS
                        DATE            get, request, set, started,
                                        tzset
                        DELETE
                        DIR             /o
                        EXIT
                        FKEY
                        FTL0            general, cancel, directory,
                                        download, homedir, kick, post,
                                        server, status, trace, upload
                        FTPSTAT
                        HOSTNAME
                        IP multicast    general, mcastgroup, routing,
                                        tunnel
                        LOG
                        MEMSTAT         g, s
                        MKDIR
                        NETROM          bcdest, bcnodes, downlink, exclude,
                                        filter, info, interface,
                                        logmask, nodefilter, nodetimer,
                                        param 3, param 4, route, status
                                        tcpip, users
                        PING
                        RCMD
                        RECORD          general, silent
                        RMDIR
                        ROUTE           general, merge, trace
                        SCCSTAT         general, b, c, f
                        SESSION         #, c tekst, trace
                        SETENV
                        SHELL
                        SMTP            expiry, hold, maxcli,
                                        maxsessions, mode forward,
                                        post, release, timer
                        TCP             general, active, kick, tos,
                                        ubound
                        TRACE           general, seperator
                        TTYLINK
                        TYPE
                        UNPROTO
                        UPLOAD          off, verbose
                        VERSION
                        WATCHDOG
        Servers         FTP             general, ascii, binary, dir, get,
                                        put, mput, reget, tput
                        NODEINFO
                        RCMD
                        SMTP
                        TELNET          debug, display, echo, eol, mode,
                                        send
                        TNC2-emulation
                        TIME
        Environment     NETRCMD
                        NETSESSIONS
                        TZ of TIMEZONE
        Default parameters NETchl
        NET/ROM info
        NET/ROM commands (in net/rom)   bye, info, mheard, nodes, ports,
                                        quit, routes, users
        BBS forwarding      
        SCC / ESCC                      param, attach, buffers
        X-25 (Eicon-card)
        SSID scheme
        Hosts.net
        ICMP
        Onexit.net
        Other info
        PC version      general
                        VERSIONS
                        G8BPQ           general, active, ports, status
                        SCREEN          swap
        Atari version
                        ATTACH asy
                        GREP
                        LOG proc
                        MEMSTAT         <number>, dump
                        SCREEN          bios, direct, tos, font
                        SHELL
                        Server FTP - TPUT
        Unix/Xenix version
                        UNIX general
                        ATTACH asy
                        AX25 start tnc2
        Linux version
                        LINUX general
                        HOST.NET
                        HOST            closedb, comment, export, import
                                        lookup, reorg, update

ARP general
-----------
no longer sends a burst of requests when an ARP entry times out while
an FTP or SMTP session is running.  only a single ARP request is
sent and up to 10 packets are buffered waiting for a reply.
RARP request/reply added to tracing.

ARP entries added to the table as a result of ARP packets received will
now be marked with the interface of their origin.  It is no longer assumed
that an address received on some interface is also valid on another.
Interfaces may be specified in arp add, drop and publish commands using
the syntax "<type>:<interface>".  e.g. arp add pe1chl ax25:144 pe1chl-2
This was primarily done to solve the problems that occur when 4800 baud and
1200 baud modems are used in parallel on the same frequency. Now it is no
longer necessary to enter fixed ARP entries for 4800 baud.
The selected method of specification of the interface keeps the "arp" command
compatible with earlier releases of the program.

ARP proxy
---------
The command "arp proxy [<iface> ...]" is to enable PROXY ARP on one or
more interfaces.  PROXY ARP means an ARP request for a destination is
answered with the local hardware address, when a route to that
destination is known and is not on the same interface as where the
request came in.
This feature is mostly useful on an ethernet segment where UNIX machines
are present that can not route packets for the same network address to
different destination machines.  It should probably not be used on AX.25
interfaces (or only with great care)!


AT
--
Introduced "at" command to run NET command at certain time-of-day.  Syntax is:
         at hh:mm command [params]
example: at 18:00 stop ftp

"at" command without params prints a list of scheduled commands.  Only one
command can be started at each time.  Use "source" command to start a sequence
of commands. (stored in a file)

"at" command corrected, now it always uses the local time.

Calculation of local time for "at" command changed.  Now, it should no longer
be so sensitive to the setting of the TZ variable.

ATTACH general
--------------
Async interface for kiss and slip devices is now under control of an external
device driver, an interrupt driven int 14 handler (COMBIOS). This can be either
MBBIOS or FOSSIL, well known with w0rli & wa7mbl sysops, and FOSSIL is from the
world of fido / opus phone bbs systems.

see documentation within "MBBIOS.ARC" and "X00Vxxxx.ARC" for more info about
mbbios and fossil.

Enhanced tracing of Ethernet packets.  Can now also display IEEE 802.3
packets, and knows some names for non-IP Ethernet types.

When a packet driver has class "Ethernet" or "IEEE 802.3", the extra keyword
"anytype" at the end of the attach packet statement will allow all types of
packet to be received.   This can be useful when tracing the traffic on an
ethernet.  It is also possible to specify up to 4 ethernet types in HEX.
Examples:
     attach packet 60 0 enet 8 1500 anytype
     attach packet 60 0 enet 8 1500 800 806 8137

Interface MTU in attach commands is set to 128 when a smaller value is
specified (which would lead to a crash when IP frames had to be fragmented
to very small parts)

ATTACH com
----------
to attach a COM port use:

attach com <number> slip|ax25|nrs <label> <mtu> <baudrate> <handshake> [<call>]

        <number> is the COM port number (1, 2, ...)
        slip, ax25 of nrs specificies the protocol to be used (ax25=KISS)
        <label> is the name of interface (144, 430 etc)
        <mtu> is the maximal transmission unit (paclen) (256 for ax25)
        <baudrate> can be selected from these values:
                110, 150, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200,
                28800, 38400, 57600, 115200, 330400.
                The high baudrates (> 9600) mean "asking for problems".
                A standard XT can reliably run up to 4800, a fast AT can
                probably manage 9600 baud.
        <handshake> is a letter "n" of "h", and specifies the use of hardware
                handshaking (RTS/CTS) on the COM port.  This would normally not
                be used, but it is rumored that AEA TNCs which exhibit the
                wellknown KISS bug would run more reliable when hardware
                handshake is in effect.
        <call> is needed for ax25 and nrs interfaces only. It is the IP call
                used for this interface.

Examples:

attach com 1 ax25 144 256 4800 n pe1chl-2
attach com 2 ax25 430 256 9600 h pe1chl-7
attach com 3 slip sl0 1024 9600 n

Remember that the translation of COM port number to hardware address is now
performed by the MBBIOS or FOSSIL. These programs must be properly configured
to match your installation.  Read the documentation of these programs!

ATTACH encap
------------
Added AX.25-in-IP encapsulation.  Like with the IP-in-IP encapsulation
described above, an entire AX.25 packet is sent as an IP datagram.  The
AX.25-in-IP variant allows AX.25 traffic over local area networks for
which no AX.25 drivers are available, e.g. SLIP or ethernet.
To use this encapsulation, an encapsulation 'pseudo-interface' is
attached which will serve as the interface for all AX.25 operations.
Any AX.25 packet sent to this interface will be sent to an IP host
determined by checking a special routing table.  The following commands
are used:
	attach encap ax25 axip 256 <callsign>
	param axip <callsign> <ip-address>	(add a route)
    param axip <callsign> d             (drop a route)
	param axip default <ip-address>		(set default route)
After attach, only a default route to [255.255.255.255] is in the table.
Using only this route should be adequate for use on a shack ethernet (at
least when packets to [255.255.255.255] are routed to this network).
As the routing table entries are SSID-dependant, you may have to enter
several routes for the same station when different SSIDs have to be
reachable via the encapsulation interface.

Added IP-in-IP encapsulation.  Encapsulation means that an entire IP
datagram is (again) sent as an IP datagram, i.e.  another IP header is
added in front of it, and it is sent to some other IP host for further
routing.  This allows (temporary) fixing of routing problems, and/or
transport of datagrams through networks that do not route net-44
traffic.
Example of a case where IP-in-IP is useful:
	A --->- B --->- C --->- D
Assume, A wants to route IP traffic to D through the gateways B and C.
Normally, that means that each gateway must have set up an entry in its
route table to forward traffic to D to the next system.  Now, assume
that for some reason B does not know that traffic to D has to be routed
via C, but it does correctly route traffic to system C, and C does route
traffic to D correctly.  It may be that B is a system which does not
understand the subnetting used in net-44, and can therefore not route
traffic for different net-44 hosts via different gateways. Encapsulation
can be used in this case to send datagrams for D encapsulated in
datagrams for system C.  System B will route the datagrams as if they
are for C, and C will see that it is an encapsulated IP datagram and
will route the original content to D.
To set this up, the following commands are necessary at A:
	attach encap ip ipip 512
	route add D ipip C
This will attach an encapsulation 'pseudo-interface' called "ipip" (for
IP-in-IP encapsulation), and will route all traffic for D to this
interface with C specified as a gateway.  NET will encapsulate all
traffic for D in IP datagrams sent to C.  C will route the original
datagram to the original destination D according to its local routing
table.  A single encapsulation pseudo-interface can be used for all
encapsulation routes you may want to define (unless you want to define
different values for MTU, in which case you can attach multiple
encapsulation interfaces) Take care that encapsulation does not create
routing loops, as these can cause a lot of traffic bouncing back and
forth, and are difficult to break.

ATTACH kiss
-----------
Added support for multi-channel KISS TNCs.  These boxes encode the radio
channel number in the upper nibble of the KISS type byte.
To use this feature:
Attach the physical device using "attach asy" or "attach com", as before.  The
channel number zero will be accessed using the defined parameters.
To access channels 1 to 15, use:
attach kiss <parent> <channel> <label> <mtu> <call>
The <parent> is the physical interface attached before.  <channel> is the
channel number used by the TNC (1..15).
e.g.: attach kiss ax0 1 ax1 256 pe1chl-7
This will make the second channel of the KISS TNC available as "ax1", with
a maximum IP packet length of 256 and a callsign "pe1chl-7".

ATTACH packet
-------------
Packet driver: It is now possible to specifiy a packet driver class when
attaching, instead of getting the default class from the driver and using
that.  When a packet driver supports multiple classes (e.g. Ethernet and
IEEE 802.3) it is now possible to select the alternative class. Specify 0
when the default class is to be used. The <class> values for packet drivers
are:
     ETHERNET  1
     PRONET_10 2
     IEEE8025  3
     OMNINET        4
     APPLETALK 5
     SERIAL_LINE    6
     STARLAN        7
     ARCNET         8
     AX25      9
     KISS      10
     IEEE8023  11
     FDDI      12
     INTERNET_X25   13
     LANSTAR        14
     SLFP      15
     NETROM         16
     PPP       17
Syntax of the attach packet command:
 attach packet <int#> <class>|0 <label> <buffers> <mtu>
[<call>|anytype|<types>]

"packet driver" buffer allocation scheme has been modified, to
pre-allocate enough buffers at attach time, and using these buffers when
data is coming in (which is in an interrupt handler).  Advantage is that
interrupts do not need to be disabled during buffer allocation, which
should result in less overruns on SCC channels.  Disadvantage is that a
buffers*MTU memory area is permanently allocated for this, and the data
needs to be copied out of this buffer in the main loop, causing more CPU
overhead.  The old method can still be selected by specifying a negative
<buffers> in the "attach packet" call, e.g. -8 for 8 buffers using the
old method.

Added AX.25-over-ethernet capability compatible with G8BPQ node.  This
can be used to operate a node running NET together with one or more
machines running applications (BBS, DXcluster) using BPQCODE on the
application machines.
Setup BPQCODE for ethernet usage using "odidrv" according to the
supplied documentation.  NET supports only Ethernet_II frame type
with PID=08FF, so you have to configure BPQ like that (the default).
Install a "packet driver" for the ethernet card in the machine running
NET, and attach it using:
    attach packet <int#> g8bpq <label> <buffers> <mtu> <call> [<enet>]
example:
    attach packet 60 g8bpq bpq 8 256 pe1chl-10 ff:ff:ff:ff:ff:ff

This provides you with an AX.25-type interface that sends its packets
on the ethernet in a format that G8BPQ will understand.  To use it,
you will have to register it as a NET/ROM interface in the usual way.
The ethernet address is optional, and defaults to the multicast address
01:42:50:51:00:00 like G8BPQ does.  You can enter the broadcast address
ff:ff:ff:ff:ff:ff here, or the address of another card (when you use
only two systems on the network).
Note that there can be problems that may force you to use the broadcast
address or a specific card address instead of the default address.  NET
will try to set the receive mode of the packet driver according to the
address specified (or defaulted): when it is a multicast address, it
will try to select receive mode 5 ("receive all multicast").  This can
only be done when no other protocol uses the packet driver yet.
Therefore, when you want to attach the ethernetcard for IP use as well,
put the "attach packet ... g8bpq" command first.  When you want to run
other protocols that are started before NET (such as Novell Netware),
you may want to use the "pktmode" program supplied with the packet
drivers to select mode 5 before loading the other protocol.  When this
cannot be done and/or the packet driver you use does not support mode 5,
you will have to use the broadcast address.  This has to be configured
in BPQCODE as well.
NET does not directly support ODI drivers.  When you want to run Netware
on the same card, use ODIPKT to simulate a packet driver on top of ODI,
or use PDETHER to provide an ODI interface on top of a packet driver.

AX25 general
------------
Extended sequence number (modulo-128) option added to AX.25 coding.  This
allows the use of a high maxframe value on highspeed half-duplex links,
especially when they are point-to-point.
Most useful for links between NET/ROM nodes.
The command "ax25 extended <call> [<iface>]" enables the modulo-128 mode for
the specified station.   A connection will be opened using SABME instead of
SABM.  When the other station replies with a DM or FRMR, a re-try is done
using SABM, and the connection is set up in standard modulo-8 sequence number
mode.  Be careful!  Not all AX.25 implementations reply to an SABME!  The
"ax25 extended" command should only be used when it is certain that the other
station can handle the modulo-128 option, and ONLY on point-to-point links.
The command "ax25 maxframe" now accepts two values for MAXFRAME.  The first
is used on modulo-8 connections as before, and can be 1-7.
The second is used on modulo-128 connections, and can be 1-127.
Because modulo-128 mode is only established during connection setup, and
packets sent on this connection have a 2-byte control value, bit number 6 in
the SSID field of the SOURCE call is cleared to indicate that the packet
belongs to a modulo-128 connection.  This is used to display the correct
format when tracing.

AX25 exclude
------------
improved handling of AX.25 excluded calls.  these cannot be connected
anymore, also from bridge, netdigi etc.

AX25 lq
-------
Added AX.25 link quality measurement.  UI frames are periodically
broadcast on NET/ROM interlink interfaces, and counters are kept on each
side to find the percentage of lost frames.
The "ax25 lq [<interface>]" command prints a table of callsigns, and the
statistics gathered.  Each AX.25 link quality frame also contains the
locally stored statistics for up to 10 stations, so that the "ax25 lq"
command can independently report the link quality for both directions of
the link.
The first (or only) line for each callsign shows the percentage of
frames received locally, the second line (if present) shows the
statistics received from the other side (i.e. the percentage of our
frames that were received at the other side)
The LastRX field shows the time since the last update of the
information.

On interfaces where "link quality measurement" (ax25 lq) is running, it is
now possible to switch automatically between "datagram" and "virtual circuit"
mode of IP encapsulation.  This is selected by adding the "auto" keyword
after the mode command:
	mode 144 vc auto
	mode 430 datagram auto
The automatic selection will select datagram mode when the link quality is
above a certain threshold, which depends on the length of the packet.
Virtual circuit mode is automatically selected when the link quality drops
below this threshold.  The mode explicitly selected in the "mode" command
(vc or datagram) will be used when no link quality figure is available for
the destination of the packet.

AX25 lqdump
-----------
Results gathered by "ax25 lq" can be dumped to a file for later analysis.
The commands are:
    ax25 lqdump <filename>
	dump link quality data to specified file.  when - is specified
	for the filename and the scheduled dump (see below) is active,
	the filename given for the scheduled dump is used.
    ax25 lqdump <filename> <interval>
	arranges for the link quality data to be dumped every <interval>
	hours.
Example:
    ax25 lqdump c:\public\linkqual.dat 24
in onexit.net:
    ax25 lqdump -
It is a good idea to dump the link quality data to a file in the public
FTP area, so others can download and analyse it.  When the file becomes
large, rename it to another name, e.g. "c:\public\linkqual.old".  The
new data will then be written to a newly created file, and the old file
can be removed after it has been downloaded.
A program to analyse the data still has to be written...  the file format
is available on request.

AX25 maxframe
-------------
Further improvements in the dynamic adjustment of MAXFRAME on AX.25
connections.  NET will always start at MAXFRAME 1 when a connection is made,
and will gradually increase the MAXFRAME up to the specified value when the
connection is error-free.  When a REJ or RNR frame is received the effective
MAXFRAME steps back to 1.  When a re-try is necessary to get a frame
acknowledged, the MAXFRAME is halved.  This algorithm should improve the
channel efficiency by avoiding large MAXFRAME values on poor links, but still
allows a large MAXFRAME when it causes no problems.

Variable-maxframe computations in AX.25 now also use the interface speed
and length of packets when determining an optimal value for maxframe.

AX25 mbox
---------
Added the W9NK TCP/IP mailbox.  This is an AX.25 server that allows AX.25
stations to send SMTP mail to the owner of the box and to other TCP/IP
stations to which the box owner can forward SMTP mail.
The mailbox accepts forwarding from the de-facto standard BBS systems.
To use the mailbox, initialize AX.25 port #6, and start the ax25 mbox server:

        ax25 port 6 conn pe1chl-1
        ax25 start mbox \net\finger\rob.txt

The (optional) filename specified after the start command specifies the "info"
file for your box, sent to the connected user when he types an "i".
Incoming mail is only routed (to the local user or to others) when the SMTP
timer ticks.  You'll have to set your "smtp timer" to a reasonable time to
receive your mail without long delays (say, up to 7200 seconds).
Added capability to write (or append) incoming mail to a specified file.
This can be used to keep a file in the public area uptodate using a
mailing list.  (e.g. hostsfiles, tcp-group mail)
When the first line of a "mailbox" file (mail\xxxx.txt) is of the form:
write c:\net\public\hosts.137
or:
append c:\net\public\tcpgroup
the incoming mail will be written (or appended) to the specified file,
not to the mailbox file.
When a suitable "alias" file entry is made, it is possible to write the
mail both to a file and to a mailbox.

Incoming mail is now marked with the source (when "new mail arrived" is
printed on the console)

Mail can now be terminated with ^Z anywhere on a line, not only on first
position.  The part of the line before the ^Z will be written to the mail,
but a CR/LF will allways be appended.
Necessary when F6FBB BBS forwards mail to it, because FBB leaves partial
lines ending in ^Z in mails, and hangs the forwarding.
Other boxes do the same as NET.PE1CHL now does, avoiding the problem...

Added mail distribution optimizer as suggested by PA2AGA.  When the mail is to
be sent to multiple users at the same host (e.g. via an alias entry that is
used as a mailing list), the message is sent to that host only once, with
multiple recepients.  This is done by scanning the recepient list for equal
hostnames.  Aliases for the same host are not recognized as such.

Added (L)ist command to AX.25 mailbox, allowing users to list their own
messages (a message which has the user's call appearing somewhere in the
output line from "smtp list").  Allows users to check if they have mail
pending at a local SMTP server, and to check if their mail has already
been delivered.

AX25 persist
------------
The "ax25 persist" command can only work on AX.25 interfaces where the
driver allows setting of the persistence.  This is true for KISS TNC's
attached to a COM port, and for SCC cards.  It is not possible to set
the persistence with drivers attached via "attach packet", so "ax25
persist" cannot be used with those.  NET now detects this condition and
removes the "ax25 persist" setting, instead of printing an "Invalid
parameter" message every time the "ax25 persist" routine wants to change
the persistence.

AX25 start tnc2
---------------
"ax25 start tnc2" command now accepts optional /<kissrx> suffix to each
argument.  The result is that the TNC2 will be started in KISS mode, with
the KISSRX parameter set to the specified value.  This can be useful in
systems where an MSYS or BPQ program is connected to a node running NET,
using the KISS protocol on a serial link.
Example: ax25 start tnc2 1=lap/3

AX25 status
-----------
In the "ax25 status" command, both bytes and number of packets are reported.

AX25 t1 t2
----------
Added "DCD-gated timing" for AX.25.  While a signal is received or the
transmitter is sending a packet, on a half-duplex channel, the AX.25 T1
and T2 timers will be halted. This causes less unnecessary re-transmissions
when the channel is so heavily loaded that the transmitter cannot be keyed.
Because a KISS TNC does not report this information to the computer, this
feature is only available when using the SCC driver, with a plugin board
like the PA0HZP OptoPcScc, DRSI PC*PA etc.
The commands "ax25 t1" and "ax25 t2" now accept two values, the first of
which is used for KISS interfaces, and the second is used for an SCC
interface.  The second value can be much smaller, as only the channel-idle
time will be counted.  Suggested values are:
     ax25 t1 15000 5000
     ax25 t2 2000 500

AX.25 timers T1 and T2 values are now randomized +/- 10% from their
preset values, to reduce the risk that two or more stations are
constantly colliding when their timers run out at exactly the same time.
It was reported that this often occurred on point-to-point links, where
both stations were sending RR(P) frames at the same time, and continued
doing so until the retry limit was exceeded and the link failed.

AX.25 T1 time calculation based on smoothed round trip time.  Enabled only
for NET/ROM links on interfaces without uplink capability (pure interlinks),
and for FTL0 links.  This should improve performance on fast dedicated links,
especially when they are fullduplex.

AX25 txq
--------
Added "ax25 txq <axcb> [a|h|l]" command to display the contents of an AX.25
transmit queue.

AX25 uigrab
-----------
Added command to grab UI frames sent to specified (or all) destinations. This
can be used to get satellite telemetry, and other data sent as UI frames.
The grabbed frames are appended to a file, further processing is required to
make them readable.  This is supposed to be done in an external program.
Only those frames not locally processed by other protocols can be grabbed.
Commands:
        ax25 uigrab
        ax25 uigrab <filename> [<dest>...]
        ax25 uigrab off
The first form displays the current state and destinations.  The second form
enables the grabbing, specifying an output file and 0 or more destinations.
When no destinations are given, ALL non-handled UI frames are grabbed.  One
or more destinations (like QST QST-1 MAIL TLM) can be specified to limit the
amount of data grabbed, especially when TCP/IP traffic is present.
The third form of the command stops the grabbing.
The data is dumped in the output file as a sequence of headers and packets. The
headers are formatted like this:
    struct axui_header
    {
        unsigned long   magic;          /* magic number for re-sync */
#define AXUI_MAGIC      0x41585549L
        long            rxtime;         /* timestamp */
        char            ifname[6];      /* interface name */
        short int       len;            /* length of following data */
    };
The rxtime is the number of seconds since 1970 at the time the packet was
processed.  The ifname field contains the first 6 characters of the interface
name, \0-terminated when it is shorter.  len specifies the number of bytes
in the received packet.
The received packet immediately follows the header.  It includes the AX.25
header, consisting of shifted-ASCII addresses, ctl byte (03 or 13) and PID.

BROADCAST general
-----------------
Added trace code for the "broadcast" protocol used on microsats (K8KA/NK6K).

Added Pacsat Broadcast Protocol reception capabilities.  The system can
receive files transmitted using this protocol.  Currently OSCAR14 and
OSCAR16 use it, and OSCAR19 will follow shortly.

The broadcast receiver kicks a 60-second timer each time a broadcast packet is
received.  When this timer elapses (i.e. after 60 seconds without incoming
broadcast packets), the list of incoming files is examined and all complete
files are moved to their destination directory.  The same thing is done when
a "broadcast stop" is executed.  This implementation allows full CPU attention
during the highspeed transmissions from OSCAR14, assuming that the timer only
elapses after the satellite is out of reach.  When you want to exit NET before
the timer has elapsed, execute a "broadcast stop" to update and close all
files.

Any broadcast packets received for files "under construction" are first stored
in a temporary file (the name of this file is shown in the "broadcast status"
output).  Only when the file is complete it is moved to it's destination.
The directory for temporary files can be modified by setting the TMP
environment variable (or TMPDIR on the Atari ST).  This can be done using
"setenv" (see below).

When a file received with broadcast is 100% complete, a message is printed.
At that time, you could enter a new broadcast request. (the current software
on the satellites allows only a single broadcast request per user)
The program still waits for 1 minute without received broadcast packets before
it writes all the received data to the permanent files in the broadcast
directory.

Enhanced disk-full checking when receiving broadcast (those UoSAT-22 pictures,
you know...)
Also changed fill character to 0x00 when incomplete files are saved.  This is
useful when receiving raw pictures.  (filler used to be '?')

The first fragment of a file is now always saved when received during
broadcast.  Useful when changing files are broadcast.

Rudimentary support for "directory broadcast" added to the PACSAT
broadcast protocol.  Any directory broadcast packets are saved in a file
"dirfile.dbp" located in the directory used for broadcast files.  No
attempt has yet been made to detect duplicate entries, or to request
hole-fills when parts of the directory are missing.  After the pass of
the satellite, one should clean this file using "pfh -c dirfile.dbp" and
then convert it to a printable directory using "pfh -d dirfile.dbp >dirlist".
When the file grows too large to maintain it this way, simply delete it
and a new file will be created at the next satellite pass.  Note that
the "dirfile.dbp" file remains open during the pass, and gets closed
only when the 1-minute broadcast idle timer runs out, or when the
"broadcast kick" command is issued.

BROADCAST abort
---------------
broadcast abort <bcst_CB>: this terminates the specified broadcast file
reception and throws away all received data (unlike "broadcast complete" which
saves it, even when the file is incomplete)
broadcast request <iface> <call> <file_id> [<blocksize> [hole]]: sends a
broadcast request to the specified call, requesting transmission of file_id.
the blocksize specifies the packet length and can be up to 244.
When "hole" is specified, the hole-list (list of missing packets) is sent
with the request. (note: this is not yet supported by the satellite...)

Adding the keyword "perm" to the "bcst abort <bcst_CB>" command now aborts
the file AND marks it as "received", so that no further attempts will be made
to assemble the file. (e.g. to prevent reception of a big file you have upload
yourself, or you are otherwise not interested in receiving)

BROADCAST blocktype
-------------------
New command "broadcast blockftype" will block all files of specified filetypes.
This can be used to block "Satgate" traffic, CCD camera files, etc.
Examples:
     broadcast blockftype          will list currently blocked types
     broadcast blockftype none     all blocked types will be cleared
     broadcast blockftype 02 d3    type 02 and d3 (hex) are blocked

BROADCAST cleanup
-----------------
"broadcast cleanup [<percentage>]" will abort all files that have
less data than a specified percentage (default 10%).  This provides a quick
way to get rid of those files of which only a few fragments were received.

BROADCAST complete
------------------
broadcast complete <bcst_CB>: Forces the storage of a received file.  When this
        command is given for a file that is not yet complete, the gaps in the
        file will be filled with question marks '?'.

BROADCAST download
------------------
"Broadcast download" command added, that allows unattended, automatic
downloading of files from a Pacsat Broadcast server (satellite).
A "broadcast server" has to be defined (usually this is done in autoexec.net)
"broadcast download <servername> <file_id>" adds a file to the list of files
to be downloaded.  As soon as a PBLIST packet is received from the specified
server, NET automatically sends "broadcast request" packets to get the
specified file(s).
"broadcast download <servername>" without file_id prints the list of files
queued for download.  A "*" indicates the file currently being requested.
Files can be canceled from the queue using "broadcast cancel <rqst_CB>", where
the <rqst_CB> can be found in the list.

Extra option to "broadcast download" allows insertion at the front of the
download queue, for higher priority when selecting a file to be downloaded.
Usage: broadcast download <sat> <file> prio
Use this when you want to download a personal message while there is already
a number of other files in the queue.

BROADCAST ihave
---------------
broadcast ihave: Shows a list of all files that have been stored away in the
        directory specified in the "broadcast start" command.
        This list is kept to prevent duplicate reception of files.

BROADCAST kick
--------------
Command: "broadcast kick", causes current broadcast file to be closed, and
complete files to be written to the bcst directory.  Same thing as happens
after 1 minute without incoming broadcast packets.

BROADCAST post
--------------
Command "broadcast post [<command>]" runs a command whenever the
dirfile.dbp file is closed (after two minutes without receiving broadcast
packets).  This command can start a program to compact the dirfile.dbp
and search for certain files that are to be downloaded.

BROADCAST request
-----------------
"broadcast request" command: the blocksize is now optional, and defaults to
244. so, you can now request the broadcast of a specific file using a
command like:
        b r 9k6 uosat3-11 af7
the blocksize *must* be given when you want to send a hole-list:
        b r 9k6 uosat3-11 af7 244 hole
note that this is still not supported in the onboard satellite software.

Added printout of "ack" message sent by satellite on "broadcast request".

Added "broadcast request" to stop a broadcast, like:
        broadcast request 9k6 uosat3-11 af7 244 stop

A new form of "broadcast request" can now use the information stored in this
way.  Usage:
    broadcast request <servername> <file_id> [hole|stop]
This saves the typing of interface name, callsign and blocksize for each
request, as this information can now be referred to using the server name.
The old form of the "broadcast request" command still works, and can be used
when an alternative blocksize is to be specified.

New command "broadcast request <server> <file_id> p" requests only the
PFH of the file, e.g. when you see a large file in the status listing
and want to check what it is.  Because only a few bytes are requested
you will always be put at the front of the queue, and get your PFH
updated quickly.

BROADCAST server
----------------
"Broadcast servers" can be defined (like FTL0 servers), using:
    broadcast server <servername> <iface> <call> <blocksize> <reqwait> [<minw>
<maxw> <UIdest>]
        defines a Broadcast server (satellite). a user-chosen name can be
        assigned to each server, and the remaining parameters are defined as
        required for the different satellites available.  examples:
            broadcast server uo14 9k6 uosat3-11 244 6
            broadcast server uo22 9k6 uosat5-11 244 6 1 3 pblist-1
        parameters can be modified by re-entering the command
    broadcast server
        shows a list of servers defined using the above command

[the last four parameters of the command are not yet used - experimenting...]

BROADCAST start
---------------
broadcast start "pathname":  This will enable the storage of received
        broadcast frames.  The pathname refers to a directory where the
        completed files fill be stored.  Example: broadcast start "c:\bcst".

The directory specified in the "broadcast start" command holds a file
"ihave.bc",
which is updated when a file is stored away.  A copy of this file is kept in
memory for fast lookup when a broadcast packet is received.  Any packets
belonging to files in the list are ignored.  To save memory, it is best to remove 
the old entries from this file when it is certain that they are no longer broadcast.
This can be done using a text editor.  It is also possible to delete the file.
The broadcast receiver will store incoming files in subdirectories of this same
directory, named after the sourcecall used in the broadcast packets.  e.g.:
files received from OSCAR14 will be stored in the directory UOSAT3, because this
satellite sends broadcast data as UOSAT3-11->QST-1.
The individual files will be named iiiiiiii.tt, where iiiiiiii is the 8-digit
HEX file ID (as assigned by the satellite) and tt is the 2-digit HEX filetype (as
assigned by the uploader).

BROADCAST status
----------------
broadcast status: Shows the status of the broadcast receiver, including some
        statistics and the status of each incomplete file.  The fragment list
        of an incomplete file can be shown using "broadcast status <bcst_cb>".
        The file currently (or last) being received is marked with a '*'.

BROADCAST stop
--------------
broadcast stop: Disable the broadcast receiver.  All completed files will be
        moved to the directory specified in broadcast start, and all fragments
        of incomplete files will be discarded.

When "broadcast stop" is executed, the fragments of files received will be
saved in a file "frags.bc" in the broadcast directory, that will be reloaded
when broadcast is started again.  When the "broadcast stop" command is in the
file "onexit.net", this allows exit from NET and a later re-start, while
retaining the data for partially received files.

BROADCAST trace
---------------
Command "broadcast trace [<hexval>]" controls the unsolicited messages
printed by the broadcast receiver (like "ftl0 trace" does for the FTL0
messages). Parameter <hexval> is the (hexadecimal) OR of the following values:
        0001:   print PBLIST packets sent by server
        0002:   show which commands are sent to server
        0004:   print ACK packets received from server
        0008:   print "file 100%" messages
        0010:   print completed file messages

CLS
---
The command screen can be cleared and set to the NETATTROUTPUT colors by
using the command "cls", when NETCLS is set to the sequence "^[[2J".

DATE [mmddhhmmss[yy]]
---------------------
Prints or sets the system date and time.

DATE get
--------
date get <host> [<port> [<tos>]]
     requests the time from an RFC868 Time Protocol server, which is
     normally located on UDP port 37.  Prints the difference with the
     local clock, when a reply is received.  When reply is received within
     15 seconds, sets the local system clock to date/time received.
     This command can be used to keep the system clock in sync with the
     clock on another machine.  You can define a "date get" command to be
     executed at some time each day, e.g.: at 03:00 date get pe1chl

DATE request
------------
The "date" command now has a number of subcommands:
date request <host> [<port> [<tos>]]
     requests the time from an RFC868 Time Protocol server, which is
     normally located on UDP port 37.  Prints the difference with the
     local clock, when a reply is received.

DATE set
--------
date set mmddhhmmss[yy]: sets the date and time

DATE started
------------
date started:        shows program uptime and starttime

DATE tzset
----------
date tzset <zone>:       sets timezone, consisting of name and offset
                westwards from UT, e.g. "GMT0", "MET-1".
                you *must* use this form instead of the older
                "setenv TZ MET-1", to get meaningful responses from
                the Time Protocol server.

DELETE
------
Added -f flag to "delete", "rmdir" and "mkdir" commands, to make
these silent in case errors occur.  Useful to clearout temp directories and
lockfiles from AUTOEXEC.NET, without getting complaints about the non-existence
of these files.  Use it like "del -f ${NETMAILQ}*.lck".

DIR /o
------
On Atari ST and MSDOS, the "/o" option of "dir" requests an unsorted
directory (as it appears on disk).  This can be useful to evaluate the
result of "INFO cmdname" and "HELP cmdname" commands in the NET/ROM, as
the first file found in the directory that matches the cmdname is shown.

EXIT
----
When "exit" command is used to terminate NET, all outstanding data on
transmit queues is sent, and one second is allowed for interrupt-driven
buffers to clear.  This solves problem with "param <interface> 255" in
onexit.net, which is supposed to let a TNC leave KISS mode.  (that
didn't always work).

FKEY
----
Added a new command "fkey" to define function keys.  It has always been
possible to do this using the capabilities of ANSI.SYS or another external
program, but as this was not widely understood amongst NET users, it has now
been added as an internal command to NET.  This also allows for a more
convenient setup of the programmed keystrings, e.g. from CONFIG.NET
The "fkey" command can program any sequence of characters for the function
keys F1..F10.  Examples:
     fkey f1 "ax25 status" 13
     fkey f2 "connect 144 "
     fkey f9 -2 24 "session t" 13
A string will be stored literally, and has to be enclosed in quotes when it
contains a space. A numeric value can be used to define a control character
or other special key.  Values for special keys are:
     -20: HOME -19: UP          -18: PgUP       -17: LEFT
     -16: RIGHT     -15: END       -14: DOWN       -13: PgDN
     -12: INS  -11: F1          -10: F2      -9: F3
      -8: F4         -7: F5        -6: F6         -5: F7
      -4: F8         -3: F9        -2: F10
When only "fkey f1" is entered, without any values, the programming for that
key is erased. The command "fkey" by itself will print a list of programmed
keys, with unprintable characters represented by [decimal_value].
FTL0 general
------------
FTL0 client support built in, to upload files to PACSAT-type satellites.

When the client has a link to a server, it attempts to execute all queued jobs
for that server.  When this is finished, it disconnects the server immediately.
Re-connection takes place when new jobs are submitted, or when the "ftl0 kick"
command is issued.
When the link fails, it is not necessary to re-queue any of the jobs.  These
are held as long as the program is running.  Should it be necessary to exit from
NET and lateron resume an upload, the upload must be re-queued using the file_id
received at the first attempt.  This file_id can be found in the output of the
"ftl0 status" command, and is also logged in the logfile.

FTL0 client doesn't connect the server anymore when an upload request is
queued.  An explicit "ftl0 kick" is required to connect the server, or the
automatic connect feature must be used.

Idle-timers for FTL0 connections have been changed to accomodate for long
processing delays aboard the satellite.  Now, instead of disconnecting after
timeout the program first tries to poll using RR(P) and simply resets the
connection when there is no reaction.  Hopefully this prevents the looping
behaviour that was often seen when the link failed.

It is possible to cancel an FTL0 request even while it is active.  In
this case the server will be disconnected to cancel the execution of the
request.  This allows the cancellation of a directory request when the link
has failed and the server had been immediately re-connected.  You can then
display the directory and re-issue the request with an updated "hightime".

FTL0 cancel
-----------
ftl0 cancel <Req_CB>  to cancel a queued request.  <req_cb> can be
found in the "ftl0 status" output.  Active requests cannot be canceled.

FTL0 directory
--------------
ftl0 directory <server> f <file_id>
ftl0 directory <server> t <dest_address>
        gets a directory from the specified server, and stores it in the file
        "dirfile.dl" in the directory specified using "ftl0 homedir".
        (see below).  The first form gets a directory of all files with a
        file number above the specified value, the second form searches for
        files with the specified destination address.  The wildcard characters
        "?" and "*" can be used in the destination address.
        example: ftl0 dir uo14 t *pe1chl*

ftl0 directory <server> a <yymmddhhmmss>
    gets a directory like described below.  selection is on upload_time
    later than the specified date/time.  part of the date/time spec can
    be omitted, defaulting to zeroes.

ftl0 directory <server> s <selection>
    intended for use by an external selection compiler. <selection> is a
    string of hexvalues, forming a valid FTL0 SELECTION.

Note that the form "ftl0 directory <server> a <yymmddhhmmss>" is most
efficiently processed by the satellite software.  All other forms can take
a long time to execute onboard the satellite, with the danger of losing the
connection in the meantime.

"ftl0 dir" commands with "f" (file_id) and "t" (to_addr) specification now
accept an optional extra parameter, the HIGHTIME to be used for the selection.
This allows more efficient selections to be made with the current satellite
software implementation, that optimizes it's search when a HIGHTIME is given.
Example: To get "all messages sent to me and all messages sent to ALL after"
910622 01:05:00", use the follwing two commands:
        ftl0 dir uo14 t *all* 910622010500
        ftl0 dir uo14 t pe1chl 910622010500
Then run PFH with the -c option to compact and re-sort DIRFILE.DL, and run PFH
with the -d option to display the directory.  The next time, use the HIGHTIME
indicated by PFH on the last line of the -d display.  Using this technique,
one can keep track of all personal messages and bulletins without having to
download all of the satellite's directory.

In the "ftl0 dir <server> a <date+time>" command it is now possible to add a
list of filetypes that are not to be included in the directory. This allows
to get a directory without all the automated-gateway files.  Example:
     ftl0 dir uo22 a 920503160410 02

FTL0 download
-------------
ftl0 download <server> <file_id> [<register_dest> [<lock_dest>]]
    queues a file for download from an FTL0 server.
    <file_id> is the id of the file to download (on the FTL0 server)
    <register_dest> and <lock_dest> are sent as specified in the FTL0 spec.
    when omitted these default to 0, as required for ordinary file
    downloads.

FTL0 download: files are now named *.pdl during download, and renamed to *.dl
when download succesfully completes.

FTL0 downloads and broadcast requests or downloads of already complete files
now prints an error message, instead of transmitting a request which results
in nothing useful.

FTL0 homedir
------------
ftl0 homedir <directory-name>
    sets the directory used by FTL0 download and directory commands to
    store the received files.  A subdirectory will be created, named using
    the callsign part of the source address (e.g. UOSAT3 or PACSAT).

FTL0 kick
---------
ftl0 kick <server>
    try to establish a link to the specified server, to attempt to execute
        all queued requests for that server.
        must be issued when a BUSY was returned at the "upload" command, or
        when the link failed for some reason.

FTL0 post
---------
ftl0 post <server> <command>  specifies a command (and parameters) to be
executed whenever all queued requests for that server
have been successfully executed.  The command is started at the moment the
FTL0 server is disconnected.  It can be used to process the results of
the FTL0 session in an automated system.  Example:
        ftl0 post uo14 source c:\net\uo14post.net
Use "ftl0 post <server> #" to clear a previously specified command.

FTL0 server
-----------
ftl0 server
    shows a list of servers defined using the above command

ftl0 server <servername> <iface> <call> <paclen> <maxframe> <frack>
    defines an FTL0 server (satellite). a user-chosen name can be assigned
    to each server, and the remaining parameters are defined as required
    for the different satellites available.  examples:
         ftl0 server uo14 9k6 uosat3-12 130 2 4
         ftl0 server po16 psk pacsat-12 130 1 6
    parameters can be modified by re-entering the command

Automatic connection of FTL0 server built in.  When there is work queued, and
the server is heard sending a specific UI frame, the connection is
automatically set up.  For this purpose, the "ftl0 server" command has been
extended with optional <UIdest> and <UIstring> parameters specifying the
destination address and a string to be matched in the UI frame.  For UOSAT3
and PACSAT these parameters would be specified as "BBSTAT" and "Open", e.g.:
        ftl0 server uo14 9k6 uosat3-12 130 2 2 bbstat "Open"
When a packet to <UIdest> is received while work is queued, it is printed.

FTL0 has been enhanced with a p-persistant automatic connect.  Now, when the
"Open" packet is received, the connection attempt will be made after a random
delay between "minw" and "maxw" seconds.  These values *must* be specified in
the ftl0 server command, just before the bbstat.  PG uses minw=1 and maxw=3.
Example:
        ftl0 server uo14 9k6 uosat3-12 130 2 2 1 3 bbstat "Open"

FTL0 status
-----------
ftl0 status <servername>
    shows the status of that server (including any requests queued)

FTL0 trace
----------
ftl0 trace [<hexval>]
    sets the trace level for FTL0 transactions.  the hex value is the OR
    of the following values:
    0001:   print BBSTAT packets sent by server (only when jobs are queued)
    0002:   show which commands are sent to server
    0004:   show state changes on AX.25 link (connected, busy etc)
    0008:   print alert message when link disconnected permaturely
    0010:   audible feedback of ack'ed and received packets
            a high click is sounded when the server acks an upload packet,
            a lower-pitched click sounds for each received packet.

            Added audible FTL0 feedback for PC too.  It does not sound as
            nice, and it ties up the CPU for 5 milliseconds, but well...
            there is no sound-generator chip, so...
            Unless you turn it off using "ftl0 trace",
            - a high beep is sounded when the server acks an upload packet,
            - a lower-pitched beep sounds for each received packet.

FTL0 upload
-----------
ftl0 upload <server> <filename> [<file_id>]
    queues a file for upload to the specified server.  the filename should
    be a full pathname to avoid problems when a "cd" is done.
    of course the file must have a valid Pacsat File Header!
    when the <file_id> is specified the upload is treated as a continuation
    of an earlier attempt.
    when no link exists to the server, the "ftl0 upload" command tries to
    establish it.

Adding the keyword "delete" to an "ftl0 upload" command now causes the file
to be deleted after it has been upload successfully.  This is indicated in
the "ftl0 status" output by the indication "[del]".

Added bytes/second timing to "ftl0 upload".  The running average is
shown in the "ftl0 status" command, and the final figure is printed and
logged when the upload completes.  Note that this figure only reflects
the performance during the last connect to the server, when multiple
connects were necessary to upload the entire file.

FTPSTAT
-------
Command "ftpstat" shows the status of all active FTP sessions, both client
and server.  More detail about one session can be shown using "ftpstat <ftp>",
where <ftp> is the control block address obtained from the first listing.

IP multicast routing - general
------------------------------
IP Multicast routing has been implemented.  This allows the efficient
distribution of datagrams through a network of IP nodes, by sending them
to a Multicast IP address (an address in the range 224.0.0.0 to
239.255.255.255).  In general, multicast datagrams are only forwarded
between network nodes.  However, applications running in user stations
can request forwarding of certain multicast IP addresses on the local
access frequency, using the IGMP protocol.
To setup a node for IP multicasting, some study of the links to
neighboring nodes and other participating nodes is required.
When all nodes in the network run multicasting-capable software and
are directly connected, each node only has to set for each interface
to a neighboring node:
    ip multicast interface <name> forward
and for each local-access frequency:
    ip multicast interface <name> all igmp
This results in packets being forwarded on the interlinks when they do
not arrive on that same interface.  On the local access, all packets are
forwarded, but subject to requesting via the IGMP protocol.
When one single interface is used for a link to more than one neighbor,
the command for that interface should be:
    ip multicast interface <name> all
This results in all packets being forwarded, also those that were heard
on that same interface, so that neighbor #2 can hear them when they were
received from neighbor #1 on that same interface.
The setup becomes more complicated when multicast datagrams need to be
sent to stations that are not immediate neighbors, e.g. because the
immediate neighbor runs software that is not multicast-capable.  In this
case, a "tunnel" needs to be setup to direct the multicast packets
through this gap.  Because of the nature of multicasting, the tunnel
should be a quickly operating path, preferably not a VC-oriented path
like a NET/ROM route.  A tunnel is setup using:
    ip multicast tunnel <destination_IP> <mode>
The <mode> is selected from this list:
    dir	- direct transmission to specified IP addr (one hop only)
    ip	- IP-in-IP encapsulation
    sr	- source routing
    off - delete this entry
"dir" is the preferred mode, but it can only be used to help the
multicast over a single IP routing hop, using a fixed ARP entry which
can contain a number of AX.25 digipeaters.  When it cannot be used "sr"
can be tried, but it is known to be buggy in many versions of NET and
NOS.  In that case, use "ip".  It is less efficient, but should always
work.
Example:
    ip multicast tunnel pi8daz dir
Finally, to enable multicast routing, include the command:
    ip multicast routing on
User stations that want to send multicast datagrams but do not need to
route them, should not enable multicast routing but should use an entry
in the IP routing table:
    route add multicast <interface>
or:
    route add [224.0.0.0]/4 <interface>


IP mcastgroup
-------------
A Multicast address is requested using "ip mcastgroup <iface> <address>",
and can be deleted by a "d" after the address.  This is all still
experimental and mainly useful for my debugging...

IP multicast routing
--------------------
IGMP implementation completed.  When "ip multicast routing on", an IGMP
Host Membership Query will be sent with 1800 second interval.  Any system
wanting to receive Multicast packets will respond with a Report of the
address(es) it wants to receive.  When another system is heard reporting,
the report is canceled.

IP multicast tunnel
-------------------
Multicast tunnels are monitored (using ping) to check if the delay is
not too long for proper Multicast protocol operation.  If so, they are
temporarily disabled until the delay is OK again.
The "ip multicast tunnel" command displays the status (Enabled/Disabled)
and the reason for disabling: 1=too-long RTT observed recently,
2=average RTT too long, 3=no ping replies received, 4=last ping reply
too long ago.
This change makes the use of slow AX.25 links for multicast tunnels
safer.  Note it is still better to use only reasonably fast links for
these tunnels, and to avoid the use of tunnels as much as possible.
Slow tunnels cause duplicated multicast packets in the network.

HOSTNAME
--------
The "hostname" command can now optionally specify the domain name.  When
this is done, the lookup of hosts (e.g. when sending mail) is speeded up
because the domain name will be stripped off before looking in hosts.net,
thus making multiple passes through this file unnecessary.  Note that
earlier versions just stripped off the domain suffixes one by one, and
scanned the hosts.net file each time.  This took a lot of time, but it
meant that mail with mistyped addresses could often be delivered to the
correct host.  Now, such mail will bounce back to the sender.
Usage of the "hostname" command:
    hostname <full.domainized.host.name> <domain.name>
e.g.:
    hostname sys2.pe1chl.ampr.org ampr.org
    hostname $CALLSIGN.ampr.org ampr.org

LOG
---
Log command now also flushes the buffer contents to the logfile.

Log now flushed every time, log without params doesn't flush anymore

Stopping FTP/SMTP/RCMD servers does not produce a log message anymore

MEMSTAT
-------
Memstat command gives the # of malloc errors not at the beginning, but at
the end of the list

MEMSTAT g
---------
Keeping some of the "freeing garbage" messages in memory so that they
can be re-displayed (using "mem g").  This also allows checking of freeing
garbage situations when accessing a remote system via RCMD.
The displayed info is still of limited use except when a symbol table
of the running version of the program is available.

MEMSTAT s
---------
Command "mem s" displays some allocation statistics that can be
useful when searching for memory leaks.  Please include a "mem s" output
when you think you have discovered a leak.

MKDIR
-----
Added -f flag to "delete", "rmdir" and "mkdir" commands, to make
these silent in case errors occur.  Useful to clearout temp directories and
lockfiles from AUTOEXEC.NET, without getting complaints about the non-existence
of these files.  Use it like "del -f ${NETMAILQ}*.lck".

NETROM bcdest
-------------
NET/ROM routing broadcasts are made configurable.  The "netrom bcdest" command
can add or drop destinations to/from a list for each NET/ROM interface:
        netrom bcdest <iface> add <dest> [<digi1> [<digi2>]]
        netrom bcdest <iface> drop <dest> [<digi1> [<digi2>]]
"netrom bcnodes <interface> poll" command sends a modified NODES
broadcast that will be recognized by neighboring nodes (running NET or
NOS) and instruct them to send their NODES broadcast soon.  Using this
in the autoexec.net will ensure quick updating of the NET/ROM tables
after a restart.

The existing destinations can be displayed using "netrom bcdest <iface>".
By default, only the destination NODES exists.  It can be dropped using
"netrom bcdest <iface> drop nodes".  One or more destinations can be added
to the list.  Keep in mind that the node broadcast can be very lengthy when
you add multiple destinations, and some temporary memory is needed at that
time to queue all the packets.  Limit the number of destinations to the
minimum. Node broadcasts can now be completely disabled on a single interface
while still having NET/ROM capability on that interface, by dropping all
destinations.

NETROM bcnodes
--------------
The "netrom bcnodes <interface> poll" command sends a modified NODES
broadcast that will be recognized by neighboring nodes (running NET or
NOS) and instruct them to send their NODES broadcast soon.  Using this
in the autoexec.net will ensure quick updating of the NET/ROM tables
after a restart.

NETROM downlink
---------------
Added possibility to hard-wire downlink ports for the NET/ROM.  When a certain
AX.25 station is known to be present on some port only, a "connect" request to
that station can be automatically directed to that port.  This makes the use
of a dedicated port for a BBS less confusing for the users, and can also
enforce
the use of a highspeed downlink when available.
Usage: netrom downlink <call> <port> [<digipeaters>]
E.g.:  netrom downlink pi8utr lap.48

"netrom downlink" command now also accepts "circuit" as an interface
name, indicating a hardwired connection via a NET/ROM circuit.  This is
useful when a BBS is attached to a node using a NET/ROM link, and the
BBS callsign is different from the callsign of the node associated with
the BBS.  (which is often the case in the Netherlands)
Example:
    netrom downlink pi8bbs circuit pi1bbs
When a NET/ROM user connects PI8BBS, the node will setup a NET/ROM
circuit to PI1BBS, and send a "C PI8BBS" there.

NETROM exclude
--------------
netrom exclude <nodecall> [d]: excludes certain nodes from the nodelist.  The
"d" option removes a call from the exclude list.  This can be used when it is
known that a node has it's parameters set up in such a way that a connect will
not be possible because a retour route can not be established.
(so-called "Belgian parameters")

"netrom exclude" command has been changed to allow "patterns" instead of
only straight callsigns.  The patterns used in this matching are the
same as for the NET/ROM NODES command, see the history entry for version
"PE1CHL.930808".  This allows things like "netrom exclude p[a-e]*" to
exclude any callsign in the PA..PE range from the netrom node list.
A new command "netrom include" allows exceptions from this rule.  A node
is only excluded from the NET/ROM node list when it matches none of the
patterns in the "netrom include" list, AND it matches at least one of
the patterns in the "netrom exclude" list.
The new "netrom exclude" command is not entirely compatible with the
original version, as the patterns must explicitly match the node
callsigns including SSID.  To convert existing "netrom exclude" commands
to the new format, just add a * at the end of each callsign in the
existing commands.  This will match any SSID in that position.
Try to keep these lists as short as possible, as the processing of these
generic patterns takes considerably more CPU time than the literal
matches that were done in previous versions.  This processing is done
for each call received in a NODES broadcast.

NETROM filter
-------------
Command, "netrom filter" has been added to allow selective filtering
of certain patterns from NET/ROM uplink or downlink traffic.  This can be
used to inhibit bulletin forwarding on busy local channels during certain
times of the day (in combination with the "at" command).
Subcomands are:
    netrom filter call [<call> <iface>|d]
     enters a callsign in the table of stations whose traffic is to be
     monitored, and the interface where the uplink/downlink traffic is
     to be monitored.  normally you would enter the callsigns of all
     local BBS stations in this table.  The SSID is not used in the
     matching.  Specification of "d" instead of the interface will delete
     the callsign from the table.  The "netrom filter call" command without
     further parameters will display the callsign table.
    netrom filter mode [y|n]
     shows the status of the filter, or sets it ON (y) or OFF (n).
     would normally appear in an "at" command, e.g.:
     at 18:00 netrom filter mode y
     at 00:00 netrom filter mode n
    netrom filter pattern <pattern1> [<pattern2>....]
     sets one or more patterns to be matched.  when a packet matches one
     of these patterns, and the call of the connected station appears in
     the callsign table, and the mode is "y", the packet is deleted.
     this way, one can effectively obstruct certain types of traffic, e.g.
     bulletin forwarding.  for a description of patterns see the pattern
     matching description below.  Examples of useful patterns:
     '^SB [A-Z0-9]* @ [!-_]* < [A-Z0-9]* \$[!-_]*$'         (RLI/MBL boxes)
     '^F[AB] B [A-Z0-9]* [!-_]* [A-Z0-9]* [!-_]* [0-9]*$'   (FBB boxes)

NETROM info
-----------
netrom info <filename>
        sets the name of the file to be sent after the normal response to the
        "INFO" NET/ROM cmd. It can be used to send a station description.
        Keep this file small!!  The length should not exceed 1 kilobyte!

NETROM interface
----------------
netrom interface <iface> <alias> <quality> [lap|uplink]
        the extra option "lap" must be given on only ONE of the "netrom
interface"
        lines to specify the default interface for downlink AX.25 connects.
        (Local Access Point).
        the option "uplink" can be given on other lines, to specify that
        user-uplinks are allowed on that particular interface.  when neither
        "uplink" nor "lap" are given, the netrom will not process commands when
        connected.

NET/ROM interface specification made more versatile.  It is now
possible to specify an interface as "bbs", which indicates a private
link to a BBS or DXCLUSTER.  Such an interface will only boradcast the
callsign(s) of the node itself, not callsigns learned from other nodes.
This is useful when a BBS or DXCLUSTER is attached using a NET/ROM link
(e.g. BPQCODE) but the attached system should not receive all the
network nodes.
Also, it is now possible to limit the number of uplinks via the same
digipeater (similar to the limitation on links from the same user introduced
in 930808, see below), and the maximum number of digipeaters used to
access the node on each interface.
Syntax:
	netrom interface <iface> <alias> <quality>
		[lap|uplink|bbs [<#uplinks> [<#digilinks> [<#digis>]]]]
Example:
	netrom interface lap4k8 ALIAS 100 lap 4 2 1
This command defines a NET/ROM interface "lap4k8" which acts as the default
local access point interface, accepts 4 connects from the same user, accepts
2 connects from users coming in via the same digipeater, and accepts only
a single digipeater between the user and the node.

NETROM logmask
--------------
The command "netrom logmask" has been added to allow selection of the events
to be logged.  The logmask is a hex number, being the OR of the following
values:
        0x0001  user connected NET/ROM (AX.25)
        0x0002  user connected NET/ROM (NR4 circ)
        0x0010  downlink okay
        0x0020  downlink fail
        0x0040  circuit okay
        0x0080  circuit fail
        0x0100  link failed

NETROM nodefilter
-----------------
NET/ROM nodefilter mode "exclusive" added.  Works like "accept", but
additionally no NET/ROM transport packets are accepted from stations not
listed.  Only stations in the "netrom nodefilter" list are accepted for
NET/ROM traffic.

"netrom nodefilter mode" now can be set per interface.
Specify the interface name as an extra parameter.  When name is omitted, the
value is set for all interfaces, as before.  Because these commands now only
act on actually initialized interfaces, these commands have to be moved from
their original location in CONFIG.NET to a line below the "netrom interface"
commands in AUTOEXEC.NET.

NETROM nodetimer
----------------
"netrom nodetimer" now can be set per interface.
Specify the interface name as an extra parameter.  When name is omitted, the
value is set for all interfaces, as before.  Because these commands now only
act on actually initialized interfaces, these commands have to be moved from
their original location in CONFIG.NET to a line below the "netrom interface"
commands in AUTOEXEC.NET.

NETROM param 3
--------------
Added NET/ROM level 3 parameter "maxfail".  When more than this number of
link failures occurs on an AX.25 link to a neigbor, all non-permanent routes
via this neighbor are dropped (until we next hear a broadcast from him).
This should limit the forever-retrying on dead links (dead nodes).
Set "maxfail" to zero to disable this feature.

Added NET/ROM level 3 parameter "maxqueue", specifying the maximum number of
AX.25 packets allowed on an outgoing AX.25 queue.  Any packets that have to be
queued above this limit are dropped, and an alternative route to this
destination is chosen, if possible.

NETROM param 4
--------------
Set the "netrom param 4" parameters to 0 to disable net/rom level 4.
Then, the node will always return "busy" when connected from another
net/rom node, and node connects from the net/rom always fail.

NETROM route
------------
Added "netrom route drop * <iface> <neighbor>", to drop all NET/ROM routes
via specified neighbor (e.g. when you know it has been taken out of service).
This only affects non-permanent routes.

NETROM status
-------------
In "netrom status" command, the timers now show the number of remaining
seconds before the timer expires, instead of the elapsed time. (there is no
room for the expiry time in this layout)

NETROM tcpip
------------
Implemented "netrom tcpip interlink" to let the NET/ROM pass only visible
nodes and #TCPIP.  (#others are not broadcast, but appear in the nodelist)
This is similar to the "TheNet I-version", but without the disadvantage of
inhibiting TCP/IP traffic.  When "netrom nodefilter exclusive" mode is 
selected, this provides very good control over the number of nodes in the
broadcast and the NET/ROM traffic through the node.

NETROM users
------------
New command: netrom users
Displays the local NET/ROM users, just like the "users" command when connected
to the NET/ROM.

PING
----
ping length [<value>]
  default <value> is 0
  defines the number of extra bytes to be send with each ICMP echo reply.
  useful for testing path and modem quality.
  maximum value <value> is 4095

RCMD
----
Command "rcmd", same as "telnet" but defaults to TCP port number 333,
and performs automatic login to an rcmd server.

Example:
     rcmd pi8rni    (the password should be in file "\net\rcmd\pi8rni")
NET will wait for the login challenge (3 groups of 5 numbers), and will
randomly select one of them.  It will then send the corresponding password
characters as defined in the password file \net\rcmd\pi8rni.  When the password
is correct, the remote system will respond with its prompt.

The port number for "rcmd" has now been officially registered at the
IANA, and is now 459.  Please change all references to port number 333
in your autoexec.net files from 333 to 459.  ("start rcmd" command)

RECORD general
--------------
Record <filename>
  now also works with ftp and finger sessions.

RECORD <filename> silent
------------------------
Command "record silent" should now also work with FTP and Finger.

Recording of incoming data in telnet and AX.25 sessions can now be done
without displaying all of the data.  When the command:
    record <filename> silent
is used, recording will continue but data won't be displayed when the
session is not current (on screen).  To see if data is still coming in,
select the session, and it will be displayed as usual.
This feature can be useful to record a large number of messages being
read on a BBS, while making other QSO's on different sessions.

RMDIR
-----
Added -f flag to "delete", "rmdir" and "mkdir" commands, to make
these silent in case errors occur.  Useful to clearout temp directories and
lockfiles from AUTOEXEC.NET, without getting complaints about the non-existence
of these files.  Use it like "del -f ${NETMAILQ}*.lck".

ROUTE general
-------------
route info <ip addr> command will print the IP route to another host

"route" command reports usage count for each entry, so that unused
routes can be found and evaluated.


ROUTE merge
-----------
Command "route merge" to merge route table entries. (remove
redundant routes, combine routes to adjacent subnets)
Add a "route merge" at the end of autoexec.net (or at least after the
last "route add" command) to optimize the routing table.

ROUTE trace
-----------
Command "route trace <host> [udp|echo [<tos>]]" for tracing IP
routes (like "hop check" in some NOS versions).  Uses UDP datagrams or
ICMP ECHO requests with increasing TTL to find the route to a specified
host.  Returned ICMP "TTL EXCEEDED" messages are used to find the gateways.
The "route trace" commands starts a session to report the output.  When
in the session, incoming replies are displayed.  Use RETURN to
re-display the list in sorted order, when out-of-sequence info has been
printed.  The following commands can be entered while in the "route
trace" session:
	k	kick (re-try probes for which no answer has been received)
	q	quit (close session)
The "route trace" procedure ends when a reply is received from the
specified host, or some "unreachable" message has been returned.  The
state of the session then changes from "Active" to "Complete".  Note
that the final reply may be "Unreachable Port" in UDP mode (when the
host is not running the UDP echo server), or the host may not reply at
all.  Also note that some hosts may be unwilling to return ICMP messages
on ICMP ECHO requests, and others may not allow the routing of packets
for the UDP protocol, so experimentation is required.
When the situation changes during the session, or when gateways internally
modify TTL during ARP resolution, "route trace" gets terribly confused...

SCCSTAT general
---------------
SCC driver: the sccstat command now accepts a channel number to display info
about a single channel.

SCCSTAT b
---------
New command "sccstat b" shows the percentage of time that an AX.25 interface
was busy.  Separate columns are shown for the DCD (carrier detect) and RTS
(request to send) signals.  Note, however, that some modems will assert
the DCD line when RTS is activated, so it may be that the percentage DCD
also includes the percentage RTS.
The command "sccstat b c" can be used to clear the counters and start a
new measurement.

SCCSTAT c
---------
Added "calibrate" facility to SCC driver: sccstat c <chan#> sends 30 seconds
of zeroes (NRZI pattern 101010...) on AX.25-type interfaces.  This is intended
for tune-up of TCM3105 modems and for link tests.  When 30 seconds isn't
enough, simply re-issue the command (we're still waiting for that SCC card
test program)

SCCSTAT f
---------
New command "sccstat f <chan#>" sends 30 seconds of 'flags' on AX.25-type
interfaces.  This is useful when evaluating the performance of certain
modems (especially the HAPN 4800 baud modem) on a scope.

SESSION #
---------
"session #" displays the maximum number of sessions.  This is a configuration
constant, that can be modified by setting the environment variable NETSESSIONS
to a numeric value *before NET is started*, e.g. in a .BAT file.

SESSION c tekst
---------------
The "session" command can now send a line of text to a session.  Usage:
session 1 "one line of text"
This sends the argument (if more than one word is has to be quoted) to
session 1.  When "session c" is specified it is sent to the current session.
This can be used in "source" files and/or with the "at" command to start
FTP transfers at a convenient time, or to login to an FTP session.  One could
put the following in a file and execute it using "source":
ftp pe1chl
ses c "user guest"
ses c "pass rob"
ses c "type i"

SESSION trace
-------------
"session trace" switches to "trace" screen (when screen swapping enabled).
Return to command screen by pressing a key.  This key will also be the
first command character, i.e. one switches back to command mode simply by
starting to type a new command.

SETENV
------
Temporary files in the PC Turbo C version are now created in a fixed place,
instead of in the current directory.  This should also eliminate the failure
to remove the tempfiles, that occurred when the current directory was changed
between creation and deletion of a tempfile (a bug in the Turbo C library).
When the environment variable TMP has been set, it's value is used as the
directory name for tempfiles.  If not, they are created in the root directory.
Put something like "setenv TMP C:\tmp" in autoexec.net to define TMP, and
make sure the directory exists.

The keyboard input routine can send a sequence before and after all keyboard
input characters echoed to the screen.  This can be used to set a different
attribute for text entered at the keyboard, and text displayed by NET.
In a session screen, this will make it easier to differentiate between the
text one has typed, and the text received from the other station.
To enable this feature, use "setenv" to store the desired escape sequence
in the following variables:
    NETATTRECHO     sent before echoed characters
    NETATTROUTPUT   sent before program output (after echoed characters)
    NETATTRCMD      sent when returning to command mode (from session)
Example (for use on MSDOS systems with ANSI.SYS loaded):
    setenv NETATTRECHO    "<ESC>[0;1m"
    setenv NETATTROUTPUT "<ESC>[0m"
    setenv NETATTRCMD     "<ESC>[0m"
Note that you have to include a line like this in your CONFIG.SYS:
    device=c:\dos\ansi.sys

More screen attribute settings strings introduced, to allow
customization of colors (mainly useful in MSDOS version).  There is even
a simple status line capability.
The following environment variables can be set to change screen colors:
    NETATTRCMD		defines attributes for the "net>" prompt
    NETATTRECHO		defines attributes for character echo
    NETATTREXIT		sent before exiting to restore default colors
    NETATTRMESG		defines attributes of asynchronous messages
    NETATTROUTPUT	defines attributes of command screen output
    NETATTRSES		defines attributes of output on session screens
    NETATTRTRACE	defines attributes of trace output
    NETCLS		sent to clear the screen (using current attributes)
    NETSTATUSLINE	defines position and attributes of status line
These variables are normally set using "setenv" commands in the
configuration file, and should contain ANSI escape sequences that are
interpreted by the ANSI.SYS device driver (or equivalent, like NNANSI).
Because the values are not yet known at the time NET prints its startup
messages, these always appear in the screen colors active at that time.
The command screen can be cleared and set to the NETATTROUTPUT colors by
using the new command "cls", when NETCLS is set to the sequence "^[[2J".
The STATUSLINE has some information about the active sessions.  Each
session is shown like "1: PI8NOS Con RTU", where 1: is the session
number (1* when it is the current session), PI8NOS is the call of the
connected station, 'Con' is the status (Connected), R indicates data is
in the receive queue, T indicates data is in the transmit queue, and U
indicates an "upload" is still in progress.  Note that the statusline
can interfere with some screen output.  It can be turned off by simply
not setting the NETSTATUSLINE variable in the configuration file.

SHELL
-----
shell can now start a dos program. (instead of an interactive shell)
syntax:
shell /c <program name> [<program options>]

In fact, "shell" starts the program identified by the environment variable
COMSPEC, and passes it the parameters you specify. See your DOS manual for
an explanation of the /c option (which is interpreted by COMMAND.COM).

SMTP
-----------
See also SMTP server

SMTP expiry
-----------
Messages that are on the SMTP queue for a long time can now be automatically
returned to the sender.   Use "smtp expiry <days>" to define the number of days
message are allowed to wait for delivery.  "smtp expiry 0" disables this
feature.  The filetime of the .wrk file of the message is taken as the
reference time of the message (normally it is equal to the time at which the
message arrived at the station).  Each time an outgoing SMTP session gets
RESET, each message on the queue for that session is examined.When the time
it is on the queue (current time - .wrk filetime) exceeds the number of days
specified in the "smtp expiry" command, the message is returned to the sender
with a short header explaining the problem.  Reasons why an SMTP session gets
RESET include:
    - ICMP "Unreachable" message received in SYN Sent state
    - timeout in SYN Sent state (the timeout is set to "smtp expiry" days)
    - "exit !" from NET
    - manual reset by operator (tcp reset <tcb>)

"smtp expiry" now sets shorter timeout when the mail is already on the
system for some time (e.g. when previous attempt ended because of a
system crash).  Now mail even gets returned when the program does not
keep running for "smtp expiry" days.  The minimum timeout is 25 hours.

SMTP hold
---------
"smtp hold" command added to allow the sysop of a 24-hour station to "hold"
smtp mail which matches a certain pattern in "source address", "destination
address", or "destination host".  This can be required when the mail is
destined to a gatway to another network (e.g. Internet), and the sysop is
required (by license conditions) to monitor all mail going through that
gateway.  Subcommands are:
    smtp hold dest <pattern1> [<pattern2>....]
    smtp hold host <pattern1> [<pattern2>....]
    smtp hold source <pattern1> [<pattern2>....]
     set patterns for destination, host and source fields.  (as appearing
     in "smtp list" output).   The patterns are constructed following the
     rules defined in the section about "pattern matching" below.
    smtp hold mode [y|n]
     enable (y) or disable (n) the smtp hold feature.
When "smtp hold" is in use, the sysop has to check using "smtp list" if jobs
are being held, and if he wants to release them.  The held jobs are indicated
with a character D, H or S in the first column of the "smtp list" output.
After they are released, the first character will be R.      Note that
exit/restart
of NET, or a RESET on the SMTP connection with another host, may reset the
status of a message to 'blank', and thereafter again to D, H or S.

SMTP maxcli
-----------
Removed limit of 10 on "smtp maxcli".  You can set any limit now, but
understand that the program can open only 20 files and that failure to open
a file may occur if too many sessions are active.  This does not include any
sessions in "SYN sent" state.

SMTP maxsessions
----------------
Command "smtp maxsession" defines the maximum number of incoming SMTPs
from one remote host.  Default is 1.  When an incoming SMTP session would
cause the maximum to be exceeded, the oldest connection is closed.
This feature was introduced in an attempt to defend against other software
that resets connections after a small number of retries, thereby leaving
open SMTP sessions that will never complete.  These SMTP sessions occupy
resources (memory, open files) on the system and may eventually lead to
problems.  Note that resetting a connection on which data is still outstanding
is against the SMTP and TCP specs, so it is really the remote system which
is at fault.

SMTP mode forward
-----------------
Mode "smtp mode forward".  works like "smtp mode route", except that it
won't write new .txt files in the mail directory.  useful for unattended nodes
that can forward mail (using "alias" file or the user%host1@host2 construct),
but do not want to accept local mail.

SMTP post
---------
Command "smtp post" defines a command to be executed after new mail
has arrived.  Each new mail triggers a 5-minute timer, and the command
is only executed when this timer elapses.  So, more than one mail could
have arrived by then.

SMTP release
------------
smtp release <job_id>
release the specified smtp job, when it was in hold status.

SMTP timer
----------
Added a second parameter to "smtp timer": the time to be used when a
mail needs to be forwarded.
Whenever a mail arrives that has to be forwarded the "smtp timer" will be
set to this value and re-started.  This allows a long time between polls
of the mailqueue, while still forwarding mail within reasonable time.
This parameter should not be set too low, to allow more than one mail to
be queued and the SMTP session to be terminated before the forwarding is
started.  Recommended value is 500 seconds.
The main timer can now be set to slightly more than one hour, to set the
time between attempts of the AX.25 BBS forwarding.  Exactly one hour is
not recommended because this could synchronize the attempts with normal
inter-BBS forwarding.  4000 seconds is a good value. (smtp timer 4000 500)

TCP general
-----------
Increased initial TCP local port number from 1001 to 1024, because HP-UX
(and possibly other systems) refuse FTP data channels with a port number
below 1024.

TCP active
----------
Command "tcp active" shows only those TCP sessions that are not in the
"Listen (S)" state.  This gives a shorter list, especially when many servers
are started.

TCP kick
--------
To calm down certain people, "tcp kick" commands are now only acted upon when
they are spaced at least 10 seconds.

A kick of a TCP session with no outstanding bytes will now re-send the
last transmitted ACK.  This can sometimes wakeup the distant station.
Also, when a RESET comes back it is known that the other station has
restarted the system and it is no longer necessary to wait for data.
A manual kick no longer increases the backoff.

TCP tos
-------
Added support for "Type of Service" as offered by TCP.
TOS is composed of characters 0-7,D,T,R for precedence, low delay, high
throughput, high reliability.  Low-delay will force UI frames to be used,
High-reliability will force connected mode, both overriding the selected
default mode (using "mode" command).
Other TOS selections may be effective for particular IP implementations
and/or subnetworks, but are currently not acted upon by NET.
With "telnet" and "ftp" and "start", specify TOS using a 3rd/4th parameter.
Otherwise set/change the TOS using the "tcp tos <tcb> <tos>" command.
You cannot change the precedence of an existing connection.

TCP ubound
----------
Introduced "tcp ubound <time>" command to set an upper bound to the
Retransmission Timer used by TCP.
This will clip the timeout to a certain level when the backoff increases,
so that there is a better chance that the session stays alive.
<time> is specified in seconds, with a minimum of 1800.  A value of 0 will
turn off this feature (and restore operation as it always was).

TRACE general
-------------
Tracing of AX.25 packets now shows the state of the two "reserved" bits in
the SSID byte. Normally these two bits are set to '1', and nothing will be
shown.    When one or both of the bits are '0', the indication [d], [e] or [de]
is shown after the SSID, like in: PE1CHL-7[e]->PI8RNI-1[d].
The [d] corresponds to bit 5 in the SSID byte being clear, and this is in use
to indicate a DAMA master.  The [e] corresponds to bit 6, and indicates the use
of extended sequence numbering when present in the source call field.

AX.25 packet tracing now includes the packet length, to make it easier to find
packets that exceed certain length limits.

TRACE seperator
---------------
A user-defined sequence of characters may be inserted between trace output
lines.    The sequence will be inserted just before the date/time header.
The default is "*** ", it can be changed using the command
"trace separator <string>".  In the string, "\n" can be used to insert a
newline character.  Example: trace separator "\n**** "

TTYLINK
-------
Command "ttylink", same as "telnet" but defaults to TCP port number 87
instead of 23.

TYPE
----
Type command has an extra parameter: the number of lines to type
      example:  cd \spool  ;go to spool dir
                log        ;flush buffer to file
                type net.log -10  ; list last 10 lines of net.log
                                    to see who is doing what.
UNPROTO
-------
Command "unproto" sets up an UNPROTO session.  Any data typed on such
a session is sent as UI packets (line by line), and any UI packets received
on the interface specified during setup will be displayed.
This can be useful for "chat nets" on a quiet frequency, and it is also
useful as a general activity watch.  When used on a PACSAT it will display
the general information that these satellites send as beacon frames.
Syntax: unproto <interface> <callsign> [via] [<digipeaters>]
The specified callsign will be used as destination for the UI packets.It
does not influence the display of received packets.

UPLOAD off
----------
Upload off
  aborts an uploading session.

UPLOAD verbose
--------------
The "verbose" option causes all data to be displayed while it is being
uploaded.  This can make it easier to notice when uploading is finished.

VERSION
-------
Command "version" re-displays the program version and copyright, that is
normally displayed only at startup.  Please mention the version number (date)
when you report any bugs.

WATCHDOG
--------
Added watchdog timer (called from timer interrupt, reset from main loop).
The "watchdog" command sets timeout values (in seconds) for 2 cases: the
first value is used while in NET, the second when executing a SHELL.
When a 3rd arg is given, it's (HEX) value will be put out on bit 0 of the
printer port every time the watchdog is reset, followed by a zero value.
This can be used to trigger an external (hardware) watchdog timer.
This should not affect printer operation, as no strobe pulse is sent, only
a change on the datalines.
(for now, watchdog functions are only present in the Atari version)

"watchdog" command now also installed in PC version.  It can only drive an
external watchdog timer.  The syntax of the watchdog command is:
        watchdog [<port> <value>]
When specified, the <port> and <value> select the output port to be used for
the watchdog.  The value is OR-ed to the value read (input) from the port, and
this value is output to the port.  Some time later the value is complemented
and
AND-ed to the port value.  The result should be that one or more output bits
toggle at each pass through the main loop.
The watchdog triggering can be stopped by specification of a zero <value>.

Also, built extra test in watchdog so that "watchdog ?" no longer causes the
PC to crash.  Now, specification of 0 or a non-numerical port number also
disables the watchdog (instead of clobbering port 0, the DMA controller).
Of course, this still leaves plenty of opportunities to scramble the system
through specification of weird port numbers.  Be careful!

SERVERS
=======

Server FTP - general
====================
FTP server indicates the transfer type (ASCII or IMAGE) when opening a data
connection, to hint certain common mistakes (e.g. getting a .ARC file in
ASCII mode)

Added "SYST", "SIZE" and "MDTM" commands to FTP server (mainly for UNIX
compatability, the "ftp" command does not use them)

FTP subcommand - ASCII
----------------------
Added subcommand to "ftp", like those available in the UNIX ftp command:
	ascii		same as "type a"

FTP subcommand - BINARY
-----------------------
Added subcommand to "ftp", like those available in the UNIX ftp command:
	binary		same as "type i"

FTP subcommand - DIR
--------------------
FTP server has an extra feature: a lister for the contents of .ARC files.
usage: (ftp subcommand!)
  dir <filename>.arc
This also works with the dir command at the net>_ prompt.


FTP subcommand - GET and PUT
----------------------------
FTP transfers can now be restarted, when the session had to be reset and the
destination file was correctly closed.  Make sure that you have set up the same
environment as during the failed FTP (i.e. the same directory and transfer
"TYPE"), and then issue one of the following command versions:
     get <remotefile> <localfile> restart
     put <localfile> <remotefile> <restart_offset>
You have to specify both filenames, even when they are the same.  To restart a
"get" command, you only need to add the keyword "restart".  To restart a "put",
determine the number of bytes that have been transferred during the previous
attempt, using a "dir" command.     Then, pass that number as a third argument
to the "put" function.   You cannot restart a "put" when you don't have
"overwrite" access at the remote system.
Always make sure that the previous connection has been reset, before restarting
a transfer!  When a "dir" displays "0" for the filesize, or you are uncertain
if the remote system has reset it's connection (e.g. because your machine
crashed and the remote does not know that) *DO NOT* restart the transfer!
First ask the operator of the remote system to reset the FTP session!
Failure to observe this rule will result in a damaged file at the receiving
end, because it is opened for write twice, and conflicts occur.
The restarting is done by sending a REST command plus a byte offset,
immediately before the RETR or STOR command that starts the transfer.  Although
the FTP spec specifies this use of the REST command, it does so only for the
"block" and "compressed" modes of transfer, not for the "stream" mode that NET
supports.  Therefore, restarting a transfer is not compatible with other FTP
implementations, and should only be used between machines running NET.
When the remote system refuses the REST command, "abort" the transfer and
start all over.

FTP subcommand - MPUT
---------------------
Added subcommand to "ftp", like those available in the UNIX ftp command:
	mput		like "tput", but does not send the contents of
                subdirectories

FTP subcommand - REGET
----------------------
Added subcommand to "ftp", like those available in the UNIX ftp command:
	reget		same as "get" with "restart" option

FTP subcommand - TPUT
----------------------
Added "tput" FTP subcommand to put a (sub)tree.  Before using it, the target
directory must be set using "cd", and the file type (usually I) to be used
for all the transfers should be selected.  Then, a "tput <dirname>" or
a "tput <wildcard spec>" will start automatic creation of subdirectories and
transfer of files.  The session should remain selected to allow
display of messages and execution of further commands.  Use "abort" to
terminate the process.  DON'T change the local "current directory" when an
incomplete pathname was specified for the "tput".

Server NODEINFO
===============
A "node information" service has been implemented, to distribute some
information about network nodes.  Users can request this information on
other nodes using "NODES <callsign>".  The information is also used
internally in the software to help routing.  This service makes use of
the IP Multicasting protocol, so that has to be configured to make use
of this feature.  The IP Multicast address 224.0.1.31 is used, with UDP
port number 1535.  These numbers have been officially registered at IANA.
The new command "node" has a number of subcommands to define some
information about the node:
    node ittl <#hops to forward information>
    node lapinfo "Some information about LAP frequencies and baudrates"
    node locator XX11YY
    node neighbors <names of neighbor nodes>...
    node organization "Name of supporting organization or club"
    node qth "QTH of node"
    node rttl <#hops to forward routes>
    node scope <coverage_area>
	(0=test 1=local 2=regional 3=interregional 4=national
	 5=continental 6=worldwide)
    node subnets local_subnet/bits ...
    node sysop "Name and/or callsign of sysop(s)"

The information strings have a maximum length of 60 characters.  They
should be kept brief, to avoid very long information packets that have
to be fragmented before being sent.  When a certain entry (e.g.
"node organization") is not applicable, just omit the command.
"node ittl" determines the number of hops that the node information is
multicast.  Setting a reasonably low number here can limit the spread of
node information through the network.
"node rttl" determines the number of hops that the routing information
will travel, and should at least be enough to reach all nodes whose
routing decisions are dependent on information in the local routing
table.  It is not useful to use a higher number than "node ittl".
The "node neighbors" should list the IP hostnames or addresses of those
neighboring nodes that also route IP (e.g. those running NET or NOS).
"node scope" defines the relative importance of the node, and is used to
determine the spread of information through the network.  Nodes of local
importance do not need to be spread all across the continent, and this
level can be used to tune that spread.
"node subnets" defines the IP subnets that the node routes to local
access points, and that are supposed to be routed to this node by other
nodes in the network.  Only a single node should claim each subnet.
(when multiple nodes serve the same subnet, only a single node should
list the subnet in this command, the others should only have a set of
routes to the stations using that node)
Example:
    node ittl 8
    node lapinfo "430.750 MHz, 1200/4800 bps"
    node locator JO22NF
    node neighbors pi8ehv pi8esa pi8rni pi8vrz pi8wfl
    node organization "Scoop Hobbyfonds"
    node qth "Hilversum"
    node rttl 4
    node scope 4
    node subnets PA_NH2net/22 PA_FLnet/22
    node sysop "PE1CHL, PE1CRC"

To start the node information server, the following command is used
near the end of autoexec.net:
    start nodeinfo

The command "node status" shows information about all nodes known to the
information server.
To get more detail about a single node, use "node status <hostname>".

Included in the node information being multicast, is a list of routes to
IP stations that have been locally defined to other gateway addresses
than the neighbors, and are not in the local subnets.  This route
information is inserted as a volatile route in the routing tables of the
nearby nodes, when necessary to route the traffic for those IP stations.
E.g. a station in the PA_GLnet network wants to have his IP traffic
routed via the node in the PA_UTnet network, because he has better
propagation to that node.  He requests the sysop of the PA_UTnet node to
add a route to his IP address on one of the local access interfaces.
The PA_UTnet node will then send this information as part of the node
info, and all surrounding nodes will add a route to that address to go
via the PA_UTnet node.  No manual intervention is required on other
nodes.  To get this working:
    - the metric of the route must be below 8
    - the route must not be via a pseudo interface (netrom, encap)
    - the IP address must not be multicast, loopback, etc.
    - the route must not point to a neighbor node
    - the IP address must not be in one of the local subnets
    - our subnets must not be a subnet of the route
Automatic routes are only accepted in a node when it has set the "route
obsotimer".  Recommended value is: route obsotimer 600
Note that the automatic distribution of route info can make a station
unreachable when incorrect routing info is present in the tables.
Please check the routing table and make sure no out-of-date or otherwise
invalid entries are present.
When you have routing table entries that you do not want to be sent to
other nodes, use a metric of 8 or more.  Example:
    route add <hostname> <interface> <gateway> 8
    route add <hostname> <interface> "" 8

Checks for overlapping "subnet" in node info is made.  When an overlap
is detected, a warning message is printed (each time the offending node
info is received).  Please coordinate the claims of subnets with other
node sysops: each subnet should be claimed by one node only.

Received nodeinfo is now checked against NET/ROM "exclude" and "include"
lists, to enable lockout of non-network stations.
Additionally, "node exclude" and "node include" commands have been added
to control the nodes accepted into the nodeinfo list.  These commands
work like the NET/ROM "exclude" and "include", but they accept an IP
subnet and "node scope" as selection pattern.  Additionally, a flag
specifies if the entry filters all node info, or only the route info.
Examples:
    node exclude [44.137.0.0]/16 3
	all node info from nodes in this subnet, with scope 3 or lower
	is excluded
    node include [44.137.40.0]/24 0 i
	include nodes in this subnet (scope 0 or higher), but only accept
	the info (not the routes)
The filtering can be used to limit the spread of low-scope nodes that
are not of local significance.  This is done by excluding all nodes
below a certain scope, then including all nodes in nearby subnets.

Server RCMD
===========
rcmd (remote command server)

format:
start rcmd [<port> [<key string>]]

defaults: <port>=333, <key string> = null
e.g.: start rcmd 333 qwert2yuiop5asd8fgh6jkl1zxcvbnmqwe5uiashjkzxcbn1234567890

         (to be inserted in autoexec.net file, together with the
          starting of the smtp/telnet/ftp/echo/discard/finger servers)

accessible for remote stations with:
telnet <hostid> <port>
e.g.: telnet pe1zzz 333   (from net>_ command line)

the rcmd server then returns three series of random numbers, five each. One of
these series must be returned with the corresponding characters from the
key string.
e.g.:suppose that the server was started with this line:

start rcmd 333 gqweGrerDFtDyuWioGpRaYsdYJfJhIKjLzxYcfRGwevbFEnSWmlcfkHtldrDC

then, a session could look like this:

telnet pe1zzz 333
rcmd 871225.33.PE1CHL.881202 pe1zzz.ampr
58 24 3 18 32, 59 13 26 12 25, 71 23 12 8 44
ryJDY                              /* we choose the second series of numbers*/
pe1zzz.ampr net>_

At this point, the user is in complete control of pe1zzz's NET system !
This can be very dangerous, because there are dos commands like delete and
chdir, and your complete system is within reach.  It is important to make
the key string as long as is practical, for example 50 or 60 characters,
all for the sake of safety. In theory it is possible that someone
monitoring the channel can, after a while, reconstruct the key string.
Therefore it's a good practice to change the string after a while.  This
server is specially meant for automatic stations without operator. Don't
start the server just to impress other people !
To use this feature, a file must be present with the systemname as filename,
in the directory "\net\rcmd".
This file should contain the password of the system to login to.

File name used by "rcmd" command modified: periods in the hostname given
to the "rcmd" command are now first replaced by underscores.  Then, NET
tries to open the file named: RCMDDIR/hostname.portnum
where RCMDDIR is the rcmd directory (contents of the RCMDDIR environment
variable), hostname is the hostname passed to the "rcmd" command, and
"portnum" is the port number given to the "rcmd" command (or the default
333).  When this file cannot be opened, the file RCMDDIR/hostname is
tried.  This change allows different rcmd passwords for the same hostname
(but for different ports), and avoids trouble with systems which can
handle only a single period in a filename.

The directory for the password files can be changed by setting the environment
variable "NETRCMD" to a different value.

Server SMTP
===========
Seek also the SMTP command

SMTP server is now capable of automatic multi-hop forwarding:

  By adressing to: john%la4zzz%sm7zzz%oz2zzz%dl3zzz@pa0zzz

  When the smtp timer counts to zero, or a smtp kick cmd is given, the mail
is first sent to pa0zzz (the local station).  The mailer chops off the
rightmost call and @, replaces the rightmost % by an @, and puts the mail
in \spool\mqueue.  This process repeats itself (when everybody is working
with this version of NET) until john@la4zzz is reached.  Of course there
has to be a path of known stations running NET 24h/day.

Greatly improved error handling in SMTP server (disk full, out of mem)
Also introduced timeout in server (waiting on commands)

SMTP server now checks mail destination more throughly.  When the destination
system is not reachable the mail is refused.

SMTP server does not put a Received: header above mail when it is talking
to itself (e.g. after receiving AX.25 mail, or when expanding an alias)

SMTP server constructs a return path when mail is sent through
multiple systems. this should make it easier to reply to such mail,
and helps the server when it has to return a message to the sender.

Server TELNET
=============
end-of-line sequence has been slightly modified.  now, 3 different
sequences can be selected using the "eol" command:
eol standard:  CR+LF
eol null: CR+NUL
eol unix: LF
everyone should try to use "eol standard", and should only switch to
a different setting when this is really necessary when talking to
some nonstandard implementation.

after connection to the telnet service, the server will now send the
telnet option "WILL SUPPRESS GA", as required per RFC-1123.  3 bytes
are sent in both directions after session setup for this option.

Commands to control TELNET operation (the former "echo" and "eol"
commands) have been moved into a new command "tnoptions". Current
subcommands of the "tnoptions" command are:

    debug sets option negotiation debug mode.
          debug 0: no debugging
          debug 1: show option negotiation
    display    when the current session is a "Telnet" type session,
          the input mode and negotiated options are shown.
    echo  is the former "echo" command.
          echo accept: accept a "will echo" command from the remote
               side, setting the input mode to TELNET.
          echo refuse: refuse a "will echo" command from the remote
               side, setting the input mode to LINE.
    eol        is the former "eol" command.  determines the sequence
          sent when the ENTER or RETURN key is hit.
          eol standard:  CR+LF
          eol null: CR+NUL
          eol unix: LF
    mode  when the current session is a "Telnet" type session,
          sets the input mode.  valid modes are:
          mode line:     local echo, full line of text is sent when
                    RETURN is pressed.  Lines saved in history.
          mode raw: separate characters are sent with no
                    translation.
          mode telnet:   separate characters sent, special keys are
                    translated to TELNET-defined sequences:
                    Ctrl-B    -> Break
                    Ctrl-C    -> IP (Interrupt Process) + Synch
                    Ctrl-O    -> Flush Output
                    Ctrl-P    -> Synch
                    Ctrl-T    -> AYT (Are You There?)
                    Ctrl-_    -> EOR (End Of Record)
          mode unix:     like mode telnet, but the following
                    additional keys are translated:
                    Ctrl-D    -> EOF (End of File)
                    Ctrl-Z    -> Suspend Process
                    Ctrl-\    -> Abort Process
    send  send a telnet option or suboption.  intended primarily
          for debugging (in association with "tnoptions debug 1").
          the option to be sent must be given as a decimal number,
          please refer to the RFCs for details about options.


Handling of TELNET options has been significantly extended and debugged.
This does not really apply to the use of TELNET in the amateur radio
TCP/IP network, but is rather important when using TELNET to log in to a
host on a local area network.
The following options are handled by the telnet client:
    Transmit_binary, Suppress Go Ahead, Status, End of Record,
    Echo, Terminal Speed, Terminal Type, Window Size, X Display location.
These are handled according to the respective RFCs.  Some details:

    - Terminal Type option is accepted only when an environment variable
      "TERM" exists.  When the connected host asks for the terminal
      type, the contents of this variable are sent.  So, to get the type
      "ansisys" sent to the host, use: setenv TERM ansisys
    - X Display location option is accepted when the environment
      variable "DISPLAY" exists.  Like with TERM, the value of this
      variable is sent when the host asks for the X Display location.
      When the value of "DISPLAY" starts with a colon, the value sent is
      the local hostname followed by the DISPLAY variable.
    - The value sent for Terminal Speed is the speed of the interface where
      the output for the connected host is routed.  This may not reflect
      the speed of the entire path to the host...

Server TNC2-emulation
=====================
new ax25 server: tnc2 emulator
This server allows you to emulate a TNC2 running TAPR 1.1.6 code.  This
TNC2 can then be used by client programs running in the other section when
using doubledos. (from the 890720 version it is also possible to connect the
TNC2 emulator to an external COM port)
This allows you to run a BBS concurrently with NET, using the same hardware
(KISS tnc, SCC board or whatever) to interface to the radio(s).  Also, other
packet programs can be run this way, as long as they interface with the TNC
using INT 14H (as is the case with MBBIOS, COMBIOS etc).

The emulator tries to mimick the functional aspects of the TNC2 software as
well as possible.  Features not supported are:

- setting of operational parameters like timing, async port settings etc
- monitoring and it's associated parameters
- calibration and testing
- multiple streams (users)
- battery backed-up RAM

Most other features are supported, including CONVERSE and TRANS mode,
input line editing, and even KISS.

There is one extra command, not found in TNC2 software, that is introduced
to compromise the efficiency of CPU usage with the requirements of the client
program:

KISSRX  <number>

This command selects which frames will be "received" by the emulator when it
is running KISS mode (KISS ON, RESTART).  This can be set using param 6 when
KISS mode is already selected.  The meaning of the number is:

        0 receive nothing (transmit-only)
        1 receive frames addressed to "MYCALL" only (the call of ax25 port 5)
        2 receive all frames addressed to callsigns belonging to this station,
          and also to QST and NODES.  This is the default value.
        3 receive all frames that are already digipeated
        4 receive everything

To use the tnc2 emulator:

Run NET under DoubleDOS.  NET needs about 230K.  Find the exact requirement
by increasing the section size in small increments, until the free space
printed
by the "memstat" command immediately after startup does not increase any more.

- define ax25 port 5
- start ax25 server "tnc" with parameter list.  each parameter is of
  the form comnumber=interface.  example: ax25 start tnc2 3=144 4=430

After starting NET, run "NETCOM" in the other partition, specifying the TNC
port numbers (from above command).  You can also specify the /b flag, which
enables a buffer between the client program and NET.  Some BBS programs don't
like this, experiment with it.  Example:
  netcom /b 3 4

Therafter, you can use "YAPPB", "WA7MBL BBS" etc in that partition, configured
for COM3, COM4 etc.   Do NOT use any of the real com ports (COM1, COM2).

If you have more than 2 COM ports in the machine, use higher numbers.
NET allows up to COM255, but the packages you want to run may be more
limited.  For first experiments, use YAPPB <com#>.

PC version: Included the possibility to emulate a TNC2 on an external COM port.
Algorithm is now as follows: when COM1-COM6 is specified in the
"ax25 start tnc2" the code checks for the presence of an INT14 handler for
that port.  If it finds one, it will start the emulator on that external port.
MBBIOS or FOSSIL should be loaded for the selected port.  (the standard BIOS
handler will lose big time!!! no interrupt handling in the ROM BIOS...)
The baudrate of the external port is fixed to 9600 (8 bits, no parity, 1 stop).
When a port above 6 is used, or there is no INT14 handler present, the code
continues to use the "virtual COM port" accessible from the other doubledos
section to emulate the TNC.
NOTE: All this only works in versions compiled to support COMBIOS/MBBIOS/FOSSIL
instead of the built-in "asy" device.

PC version: timeout on transmit character emulation routine (virtual COM port)
increased from 5 to 25 seconds, to allow for very bad AX.25 links to a BBS
running on TNC2 emulation.  The WA7MBL bbs does not test for timeouts, and
therefore drops characters when one occurs.

TNC2 emulator can now XON/XOFF when FOSSIL driver is used

Some enhancements to the TNC2 emulator make it more compatible with a real TNC2.
Now, the "paclen", "maxframe", "frack", "resptime" and "check" parameters are
really used for TNC2 connections.  Of course the defaults are the same
unreasonable values as used by the TNC2 firmware, so these should be set before
a connection is made (especially "frack").

Server TIME
===========
RFC868 Time Protcol.  Start it using "start time".  It will return
the current date and time in the format specified by RFC868, when an empty
datagram is sent to its port (UDP port 37). Name is consistent with the
list of standard protocols in RFC-1340.

ENVIRONMENT
===========
NETRCMD
-------
The directory for the password files can be changed by setting the environment
variable "NETRCMD" to a different value.

NETSESSIONS
-----------
"session #" displays the maximum number of sessions.  This is a configuration
constant, that can be modified by setting the environment variable NETSESSIONS
to a numeric value *before NET is started*, e.g. in a .BAT file.

TZ of TIMEZONE
--------------
TZ or TIMEZONE (depending on machine+compiler) environment variable now gets
a default value GMT0 when it has not been set by the user.
This prevents funny behaviour when "at" is used (default was Pacific Standard
Time).  You can still set your own preferred timezone.

DEFAULT parameters NETchl
=========================
Many bug reports I have received lately turned out to be related to
configuration parameters.  Users unaware of subtle side-effects modified
critical parameters like "buffers" and "AX.25 timing", and later
complained about strange effects or memory problems.  Because the system
works best when everyone uses the same parameters anyway, most
configuration commands have now been removed, and the parameters have
internally been set to values that have proven to be fine during years
of experience.  This has the added benefit of reducing the program size,
and making it easier for newcomers to get the program running. The
affected parameters and their values are:

    buffers 8*nchan      (8 buffers per channel of SCC interface)
    smtp maxclients 10
    smtp maxsessions 1
    smtp timer 4000 500
    tcp irtt 15000
    tcp mss 512               (1K on an ethernet interface)
    tcp timeout 7200
    tcp ubound 3600
    ax25 maxframe 4 16
    ax25 paclen 128      (paclen depends on speed on SCC interface)
    ax25 pthresh 64
    ax25 retry 10
    ax25 t1 15000 5000
    ax25 t2 2000 500
    ax25 t3 600000
    ax25 t4 900000
    ax25 window 2048
    netrom param 3 50 6 5 20 3 24 3
    netrom param 4 120 3 10 180 10 16 1800
    netrom param 7 1 0 0
    flow on
This change has made the file "config.net" mostly redundant.  The few
remaining parameters have been moved to the autoexec.net files in the
examples.

NET/ROM info
============
NET/ROM "NODES <nodecall>" command (and NET "netrom route info") command
show smoothed round trip time and mean deviation for the specified node,
when this info is available.  (only when connect and/or info have been
exchanged with the specified node after it has been added to the nodelist)
The round trip time information is also used to calculate the NET/ROM
transport timeout when setting up new circuits.

NET/ROM "CONNECT" command now handles digipeaters the same way as a fast
connect on the uplink is handled.  So, a user can connect a station on
another node using:
	CONNECT <user> VIA <node>
Before, this resulted in an AX.25 downlink connect of <user>, with <node>
as a digipeater.
Also, it is now possible to specify more than 2 digipeaters in both a
fast connect and a CONNECT command to the node.  The remaining digipeaters
will be sent in the CONNECT command to the next node, so it should be possible
to connect through multiple nodes (when they run this version of the software,
or other software that understands "C <call> VIA <digi>...").  example:
	CONNECT <user> VIA <entrynode> <intermediatenode> <exitnode>

When a CONNECT to an AX.25 station is made, an interface is selected:
- For AX.25 connected stations: the interface they are connected on
- For NET/ROM connected stations: the default (LAP) interface
The interface can be changed by a "port <interface>" command before the
CONNECT.

NET/ROM now allows a fast connect to another station using the forms:
        connect <station> via <entrynode> <exitnode>
        connect <station> via <node>

This is similar to the facility offered by Flexnet.  You will get a connect
to the local node, and the link to the specified station will be automatically
set up.  When the local node detects a problem (e.g. <exitnode> not in
nodetable), it returns a DM (Busy).  When a problem at the remote node
occurs, the normal error message will be returned on the connection.
The old step-by-step connection method remains available.

When someone connects to the NET/ROM from another NET/ROM node (i.e. incoming
on a NET/ROM circuit), and asks for a NODES or NODES * list, those nodes that
can be reached via the same neighbor that is used to reach him will be omitted
from the list. A message (# NODES routed via XXXX not shown) is sent at the
end of the list to explain this.  The reason is that users connecting through
the network are only interested in nodes further down the path.
When a connect is made to another node, the same check is made to avoid that
nodes are connected that are reachable only via the same neighbor that the
incoming circuit also uses.  This avoids that a circuit is set up for which
all info packets have to be sent from one node to another, and then back to
the originating node.
A message "alias:call} No backward connects along incoming ROUTE" is shown when
such a circuit connect is attempted.
The second and third parameter of "netrom param 7" can be set to "1" to
restore the old behaviour (displaying all nodes, allowing all circuits).

netrom supports route [<call>] command.

NET/ROM: When a NODES broadcast comes in which contains routes to a certain
destination with a better quality than the currently active route, that better
route is again selected, even when it was dropped before because of a link
failure.  This is done to prevent infinite re-routing of NET/ROM links in case
of a temporary link problem (there used to be no mechanism to re-select a
dropped route...).  When the station receives NODES broadcasts from distant
nodes regularly, these nodes should be filtered out to prevent repeated tries
of the direct links to these nodes.

Improved NET/ROM handling of failing routes.  When a NET/ROM broadcast is
sent, nodes with only 0-quality routes are broadcast too (with that 0 quality).
When such a broadcast is received, the particular route is deleted.

Fixed problem in NET/ROM: when multiple NET/ROM level 4 packets were received,
some with the MORE bit set, and the total length of info was over 256, the
AX.25 link transmitted packets over 256 bytes in length.  Now these are split
in multiple packets each up to 256 bytes in length.

The answer to a often-asked question about NET/ROM:
You can use different calls for the NET/ROM on different interfaces (e.g. a PI1
call on 23cm).  Specify the calls you want to use in the "attach" commands for
the different interfaces.  Somewhere after these attach commands the
autoexec.net file contains the line "attach netrom $CALLSIGN-9".  When this
line is changed to "attach netrom" (without the callsign), the NET/ROM will use
the interface callsigns on each band.  Make sure that you use a "hidden" alias
(starting with a # sign) for the interlink nodes of the NET/ROM!  The alias can
be separately specified for each interface in the "netrom interface" lines.

When an outgoing NET/ROM link is set up, the AX.25 connection now ignores
incoming packets with pid=Text.  This has become necessary because more and
more NET/ROM clones are sending a connect text to everything issuing a connect,
causing the local side of the connection to start a NET/ROM level 7 session.
Because of this change, some programs will no longer be able to simultaneously
have a NET/ROM- and a normal TNC session with a station running NET.

The NET/ROM now also accepts node broadcasts via up to two digipeaters.

Changed NET/ROM: The output of the command-interpreter is now sent as
separate packets instead of a single message (with MORE bit set on all
packets but the last).  This was done to prevent crashes in old NET/ROM
nodes that occur when long messages are sent, e.g. the output of "N * *".
The consequences of this change are:
        1. the output is now sent in 236-byte packets (instead of 256)
        2. when the link fails you may receive an incomplete response

The alias for NET/ROM routes added automatically when a packet is received
from a node for which no route exists is changed to "######".  Previously,
such routes got no alias at all.

Failures of a NET/ROM link are now logged to the logfile.

NET/ROM downlinks are now made with a digistring containing both the source
node and the local node.  This allows easy reversal of the path to connect
back to the calling station.  "netrom param 7 0" can be used to disable
this feature.

The broadcasts of NET/ROM routes now include all routes that are above
the "minimum quality to be broadcast" and "minimum obsolescence to be
broadcast".  Previous versions tried to reduce the broadcast by omitting
routes that were received from the neighbor that the broadcast was
directed to.  This reduced the number of entries in the route table, but
it also limited the possibilities to recover from link failures.  With
the new memory management, the extra routes shouldn't be a problem.

Maximum number of simultaneous NET/ROM circuits has been increased from
32 to 64.  Please report when this is still insufficient.

NET/ROM transport layer packets received out-of-sequence are now held on
a resequencing queue.  Formerly, they were discarded and had to be
re-sent by the source after the missing packet was transferred.  I
believed that this would not be an issue, because the network links are
AX.25 virtual circuits.  In practice, maintaining the resequencing queue
seems to be worthwile.  (after receiving the NAK reply from the
destination node, the source node sends only a single packet, and the
next acknowledgement will indicate the correct reception of the packets
on the resequencing queue)

NET/ROM now detects hop-by-hop connecters, and issues a warning message
when a user has connected from a neighbor node and tries to setup a
circuit to another neighbor node.  It then reduces to NET/ROM window to
decrease the troughput on this circuit.  Users should be told to connect
from uplink to downlink node in one step (or as few steps as possible),
as this enables more efficient routing and reduces processing in each node.

NET/ROM can limit uplinks by a single user, to avoid over-use by some
people.  The default limit is 3, it can be changed by an aditional
parameter to "netrom interface":
	netrom interface <iface> <alias> <quality> lap|uplink [<uplinks>]
Of course this has only meaning when "lap" or "uplink" is present.  It
is suggested to set a low value (e.g. 2) on 1200 bps LAP, and a higher
value on a highspeed LAP interface.
Please note that you should NOT include "uplink" or "lap" on an interface
which is to be used for a NODE-to-NODE interlink!  The efficiency of the
link will be much higher when you omit the "uplink" capability!!!

NET/ROM now detects hop-by-hop connecters, and issues a warning message
when a user has connected from a neighbor node and tries to setup a
circuit to another neighbor node.  It then reduces to NET/ROM window to
decrease the troughput on this circuit.  Users should be told to connect
from uplink to downlink node in one step (or as few steps as possible),
as this enables more efficient routing and reduces processing in each node.

NET/ROM can limit uplinks by a single user, to avoid over-use by some
people.  The default limit is 3, it can be changed by an aditional
parameter to "netrom interface":
	netrom interface <iface> <alias> <quality> lap|uplink [<uplinks>]
Of course this has only meaning when "lap" or "uplink" is present.  It
is suggested to set a low value (e.g. 2) on 1200 bps LAP, and a higher
value on a highspeed LAP interface.
Please note that you should NOT include "uplink" or "lap" on an interface
which is to be used for a NODE-to-NODE interlink!  The efficiency of the
link will be much higher when you omit the "uplink" capability!!!

NET/ROM accepts command "*** LINKED to <callsign>", but only when issued
as the first command on a connection from the G8BPQ Hostmode emulator.
This is used by G8BPQ Hostmode applications that want to setup outbound
connects using a different callsign than the default (e.g. F6FBB gateway)
Other commands starting with *** are ignored by the NET/ROM command
interpreter. (this seems to be a convention for passing status
information, F6FBB also ignores it)

NET/ROM "INFO" (aka "HELP") command can now send information about
specified topic.  To activate this feature, add a second argument to the
"netrom info" command, to specify a directory where information files
are stored.  It is possible to use the same directory as used by the
"finger" server.  NET looks for files with the extension .txt in this
directory, and displays the first file found which matches the keyword
entered by the user.
Example:
	netrom info c:\net\nr_info.txt c:\net\finger
c:\net\finger directory contains:
	connect.txt
	mheard.txt
	nodes.txt
	routes.txt
	... etc
Now a user at the node enters: H CON
The file "connect.txt" is then sent to this user.  Any substring of
CONNECT (C CO CON CONN CONNE CONNEC CONNECT) will result in this same
file being displayed.
As the NET/ROM user can only ask for helpfiles by name, and cannot get a
listing of available files, it is the responsibility of the sysop to
include proper cross-references between the files, starting from the
file that is displayed by a single HELP or INFO command (in this
example: c:\net\nr_info.txt).  This could take the form of directives
like "Use HELP <commandname> to get more help" or "Use INFO LINKS to get
a description of the available links".  Of course, when the directory is
shared with the "finger" server, a TCP/IP user can get a listing of
files by using "finger @hostname".

Added some of the TheNET extensions to the NET/ROM code.  The TTL values
in TheNET node broadcasts are now supported, and the uplink node is
shown in the "users" command when it is known (connect from a TheNET
node).  The uplink node is not sent by NET, because this conflicts with
another extension (sending of L4 timeout in connect requests as
specified by G8BPQ).

NET/ROM commands (when in the netrom)
-------------------------------------
BYE
        command to NET/ROM to disconnect (not shown in menu).

INFO (replaces IDENT)
        Show information about the NET/ROM
        If activated about a specified topic.

MHEARD [<interface>]
        Show the MHEARD list

NODES
    NET/ROM "NODES" command can now selectively display nodes using a pattern
    match.  The match is only applied to the node callsigns, not the aliases.
    E.g:    nodes pi8*  show only nodes in the Netherlands
        nodes *hwb  show only nodes whose call ends in "hwb"
    The following constructs are valid in this pattern:
        *   matches any sequence of characters
        ?   matches any character
        [abc]   matches a, b or c
        [a-l]   matches any character in range a..l
        [^abc]  matches any character except a, b or c
        [^a-l]  matches any character except those in range a..l
    (this is NOT the same pattern match syntax as used in some other cmds!)

PORTS [<interface>]
        List available NET/ROM ports (interfaces) and optionally selects
        the interface to be used for downlink connects.

QUIT
        command to NET/ROM to disconnect (not shown in menu).

ROUTES *
        Displays AX.25 link quality of neighboring nodes, when available.

USERS
        NET/ROM "users" command now differentiates between established
        connections and connections in setup phase using the symbols
        "<-->" and "<..>".

BBS FORWARDING
==============
Added forwarding from NET to RLI/MBL-style mailboxes and personal maildrops.
This is kind of a hack, as several conversions have to be made on SMTP
mail addresses and headers.
The feature operates as follows:  When mail must be sent to a host, a
check is made if the hostname is of the form <call>.bbs, and if a file
exists in the MQUEUE directory with this name.
If both of these conditions are met, the mail is forwarded using a script
in the MQUEUE\<call>.bbs file.
The script contains lines, of which the first character is an opcode:

 #      this line is a comment
 c      only as the first line: specifies the initial connect to be made.
        this can be a connect to the bbs, or to a NET/ROM node that is
        used to reach the bbs.  syntax is like the net> connect command.
 s      send string to remote BBS or node.  can be used to send strings
        containing connect commands to NET/ROM nodes.
 w      wait for specified string to be received.  lines not containing
        this string are ignored.  useful during connect and disconnect
        phase, to eat banners sent by the BBS.
 r      checks for a specified string to be received.
        when a line not containing this string is received in the message
        transfer phase, it is mailed back to the message sender (it
        probably is an error)
        while in the connect phase, the box is simply disconnected.
 l      marks the point in the script where the connect ends, and the
        messages are transferred.  ("loop")
 m      defines the line to be sent to send a message. line is used as an
        argument to sprintf, with the following string args:
        1. message type ("P")
        2. destination call
        3. destination bbs
        4. source call
        5. message id
 u      send subject of message. line is an argument to sprintf, with
        the message subject as an argument.
 b      send the body of the message. any text after the "b" is sent as
        the end-of-message marker.  the default is ^Z.
 n      defines the end of the message transfer lines and the start of
        the disconnect phase.  control will branch back to "l" when
        more messages are to be sent ("next")

Examples: to directly connect to a BBS (AA4RE-type):

# forward to PA3APN
c 650 pa3apn
w==>
# now we are connected, send each mail
l
mS%s %s@%s < %.6s $%.12s
rBetreft
u%s
rBericht
b
ropgeslagen
w==>
n
# all done, send "bye" command
sB
w73

To connect to a BBS via NET/ROM:

# forward to PI8EAE via PI8RNI-7 NET/ROM
c 430 pi8rni-7
sc pi8eae
rConnected to
w}
# now we are connected, send each mail
l
mS%s %s @ %s < %.6s $%.12s
rSubject
u%s
rmessage
b
r}
n

Another NET/ROM example:

# forward to PI8ABT via PI8RNI-7/PI8ABT-7 NET/ROM
c 430 pi8rni-7
sc zbl70
rConnected to
sc pi8abt
rConnected to
w>
# now we are connected, send each mail
l
mS%s %s@%s < %.6s $%.12s
rOmschrijving
u%s
rBericht
b
ropgeslagen
w>
n

As can be seen, the scripts must be tuned to match the exact responses
sent by the local BBS, such as the "subject" and "message" prompts, and
the final character of the BBS prompt (">" or "}").
It is possible to write scripts that ignore the prompts (just omit the
"r" lines and put only a "w>" or "w}" after the body) but this will kill
the error checking capabilities of the forwarder.
Remember that NET/ROM will cancel a connection when you send something
without waiting.  Always include an "rConnected" line after a NET/ROM
connect command.

Fixed a problem in the AX.25 forwarder: when no "r" or "w" line was present
in the script after "m" "u" or "b", the forwarder did not proceed.
Therefore it was impossible to forward to mailboxes that do not prompt for
the subject and/or the message, or don't send a CR after such prompts.
This is now fixed, and the following script works:

# forward test to personal mailbox
c 430 pe1chl-15
w>
# now we are connected, send each mail
l
mS%.0s %s
u%s
b
rOK
w>
n

This sends the S <call> command, the subject, and the entire message in one
go, and then checks for a response containing "OK".  For more detail about
forwarding scripts see the explanation further down this file.

The forwarder now concatenates multiple lines from the message into a single
packet, whenever the total length of these lines is below paclen, except when
the effective window (maxframe) is less than 2.

When the AX.25 forwarder receives a NO reply when sending a message, it is
returned to the sender and the forwarder skips past the 'b' command.  This
allows
bulletin forwarding to boxes that allow abbreviated forwarding.  The SID string
has to be sent explicitly.
The new command 'f' in the forwarder script allows reverse forwarding. A string
to request reverse forwarding can follow the 'f', the default is "F>".
Example of a script to forward to MBL/RLI boxes using abbreviated forwarding:

c 430 pi8utr                    connect the mailbox
w>                              await the > prompt
s[NET-H$]                       send SID
r>                              next line must be > prompt
l                               loopback point
mS%s %s@%s < %.6s $%.12s        send a mail or bulletin
rOK                             response must be OK
u%s                             send subject
b                               send body
w>                              await the > prompt
n                               send next mail (if any) from loopback point
f                               request reverse forward

When connected by a forwarding/reverse-forwarding BBS, the AX.25 mailbox now
disconnects after a single command error (after sending "Huh?").
This avoids looping when the two systems get out of sync and send error
messages to eachother, something that could happen with an F6FBB BBS.

SCC / ESCC
==========
scc driver included. see sccdoc.arc file on this disk.

buffers [<no. buffers>] command included.
  Specifies the number of receive buffers for the scc interrupt handler.
  Belongs to the scc driver.

SCC driver: When DCD is active during initialization of the driver, the
receiver is enabled immediately.  This used to happen only on inactive-
to-active transitions of DCD.  (Added after request from pa0hzp who
was testing his board)

Added support for the DRSI PC*Packet adapter in the SCC driver.
(hardwaretype = 08)

Added support for external transmit/receive clocks in the SCC driver.
Use "ext" instead of the baudrate to get RTxC=RX clock, TRxC=TX clock.

With the SCC driver in AX.25 mode, a new speed can now be set
using "param <iface> speed <speed>".  This only works when internal clocking
was specified during init, and it cannot switch between internal and
external clocking.
In AX.25 mode, the transmitter can be disabled using "param <iface> tx n".
This is useful for unattended stations (when interference reports have been
received by the control operator he can issue this command via rcmd).

SCC driver now allows complete specification of the clocking mode, so that
all modems requiring- or providing external clocks can now be controlled.
The value to be written to WR11 of the Z8530 can now be specified as a
hexadecimal value after the existing baudrate specification, separated by a
colon (e.g. d1200:66).  This is not necessary for the standard AFSK modems
and the HAPN 4800 baud modem, as these do not require external clocks.
Refer to a Z8530 technical manual for more information about the value to be
written to WR11.

PC: the interrupt number to be used for SCC timer ticks can now be specified
as an optional parameter to the "attach scc init" command.  The default is 
08, i.e. the hardware timer interrupt.  Possible other candidates are 1C and
70.  The driver assumes that the timing hardware has been initialized before 
and a handler is in place that resets the pending interrupt.  It only chains 
it's handler on the specified vector.  The tickrate should be somewhere 
between 18 and 200 ticks
per second.  Example:
        attach scc 2 init 150 4 2 0 1 168 3 p4915200 0 0 1c
Note that the 2 hardware-dependent parameters after the clockfrequency should
be present in this case.  Use zeroes when these parameters are not needed.
Also note that the 1C vector is not suitable when multi-tasking DOS
replacements like Desqview and Doubledos are in use.  Vector 70 can only be 
used in an AT, and needs a TSR routine to setup and handle the RTC timer interrupt.

Added support for the Z85130/Z85230 ESCC chip to the SCC driver.  This is
enabled by using "attach escc" instead of "attach scc" to attach the channels.
The "init" attach line can use either "scc" or "escc", with no difference.
The total set of chips driven by the SCC driver can be a mix of Z8530/Z85C30
(SCC) and Z85130/Z85230 (ESCC).
The ESCC can run fullduplex without the external divide-by-32.  When no divider
is fitted, the "d" option in the baudrate field should be omitted (as always).
The main advantage of the ESCC is the larger TX FIFO (4 bytes instead of 1) and
RX FIFO (8 bytes instead of 3), allowing a longer interrupt latency without
causing overrun/underrun errors.
Therefore, the chip can be used at the high edge of the speed range supportable
using interrupt-driven I/O (19200 and possibly 38400 baud). It also solves some
bugs in the original SCC, and creates a few of its own.
Unfortunately, it is quite expensive, so for now the best choice is likely
to remain the SCC.

Input packets on the SCC driver and the SLIP and KISS protocols on async ports
are checked for a maximal length.  Packets longer than the MTU of an interface
plus the header overhead for AX.25 are discarded.  Sometimes very long packets
were received when noise was present on the input, and this lead to excessive
use of memory by the drivers.  This was probably the explanation for the use
of large amounts of memory by NET, which was later freed to the heap but never
returned to the operating system.

Calculation of tcp MSS option value in SYN packets changed, to reflect
above change.  The MSS value relects the MTU of the interface on which the
outgoing packets are routed.  Using different MTU values on interfaces of
the same kind (e.g. AX.25) could cause problems when the outgoing and incoming
packets are not passing through the same interface.  To avoid trouble, use
only a widely-accepted MTU: 256 for AX.25, 1500 for ethernet.

SCC driver: enhanced handling of DCD.  Before, a when DCD dropped while
a packet is received, the packet was always discarded.  Now, two alternative
modes of operation are possible:

param <iface> dcd n
        DCD-changes are ignored, the receiver is permanently enabled.
        In this mode, a packet is never discarded because of DCD loss.
        However, when noise is present on RxD it will cause a permanent
        interrupt load on the system.
        Normal operation restored by: param <iface> dcd y

param <iface> 11 <n>
        Whenever DCD falls, the receiver remains enabled for <n> ticks.
        (the duration of a tick is displayed at startup, normally 10ms on
        the Atari ST, 55ms on the PC).
        Setting this parameter to a suitable value will eliminate the
        packet loss caused by a flickering DCD, as can sometimes be observed
        with the G3RUH modem.
        Setting parameter 11 to 0 will restore normal operation.

These DCD handling options do not affect the "channel busy" detection that is
performed in half-duplex mode (CSMA).  The P-persistent channel access
algorithm takes the unsmoothed DCD as input.

PC version: SCC driver option added to use one of the SCC channels as an SCC
timer tick generator.  It turns out that multitaskers like Desqview treat the
55ms system timer interrupt in such a way that a running task does not receive
all timer ticks.  This results in random timing errors when a program is
running in another window. (you can observe this as unusually long flag leaders
and trailers when listening to your transmissions)
When a spare SCC channel is available, it can now be set up as a 10ms timer,
to be used instead of the system timer: add the option "t<n>" at the end of
the "attach scc init" command, where <n> is the channel number to be used for
timing.  When no hardware dependent options ar used, two zeroes must be
inserted between the <frequency> parameter and the option.  Example for use
with the PA0HZP OptoPcScc card:
     attach scc 2 init 150 4 2 0 1 168 3 p4915200 0 0 t3
This defines channel number 3 (the last channel on the board) as a timer tick
generator.
The timer tick generator defined this way generates 10ms ticks. When you have
defined your own values for SCC channel parameters 1,3,4,7 or 11: remember to
re-calculate the values of these parameters based on this tickrate.

MSDOS version: when SCC driver hardware type 08 (DRSI PC*PA) is selected, the
Z8536 on the DRSI card is programmed to generate 10ms timer interrupts. This
yields more accurate timing, just as described under "PE1CHL.920311", without
the use of one of the SCC channels on the card.

When "external clocking" is selected in the "attach scc" command, NRZ encoding
instead of NRZI can be selected by specifying "ext/nrz" in the baudrate field.
NRZ encoding is used by the DF9IC 9600 baud modem.

MSDOS version: The SCC driver now requires an alternative timing source when
it is running under DESQview.  A DRSI card has a Z8536 which will automatically
be programmed for this purpose (see below).  Other SCC cards must either
dedicate one channel for timing purposes, or they must use a TSR which will
deliver accurate timing interrupts on some other interrupt number than the
normal 08 or 1C vectors.  DESQview treats those interrupts in a special way,
which results in horrible SCC channel timing when another task is running.

When using ESCC chips, the RTS signal can be made inactive immediately
after the closing flag, to improve turnaround time at higher speeds.
Set "param xx 4 0" to enable this.  Warning: some modems and/or transceivers
will not transmit long enough to send the last packet in a series, when using
this feature.  In that case, use "param xx 4 2" to introduce the smallest
possible time delay at the end of each packet.

In the MSDOS version, the bus timing for the SCC driver has been
modified.  The driver now uses an "IN AL,0E4H" instruction to introduce
the proper amount of delay after a write to the SCC (5 PCLK cycles, or
about 1uS).  Tests have shown that this IN instruction provides a
reasonably constant delay on a wide range of machines.  Earlier versions
used a delay routine that introduced a fixed number of clock cycles of
delay, which varied widely between an old XT and a fast '486 system.

When using SCC card, the transmission time for a single AX.25 connection
is now limited to 4 seconds, by varying the effective MAXFRAME value
depending on the length of the packets being sent. (no more than
4*bitrate bits are sent in a single transmission)

SCC driver parameters (in AX.25 mode) that are expressed in 'ticks'
(params 1,3,4 and 7) can now also be specified in milliseconds by adding
the 'ms' suffix, as in:
    param 144 1 300ms
This allows more convenient specification of the parameters, and makes
them independent from the actual tick rate, which can have several
values in the MSDOS environment.  The actual value of the parameter, as
reported back when using "param <interface>", will be the value in tick
time units as before.  Note that this function is NOT available for
async interfaces (to KISS TNCs), only for the SCC driver.

SCC driver now supports up to 14 chips on the PC.  (28 channels)

SCC driver verifies the SCC chip presence.  A warning message is printed
when some test values cannot be written to and read back from the chip.
When a channel fails the test, it can be attached but a messages shows
up when "sccstat <channel#>" is used.

SCC driver %DCD and %RTS are now kept in 24 separate counters, selected
by the local time (hour).  The existing "scc b" command still prints the
overall percentages, but details are shown when a single channel is
reported using "scc b<num>".  Example: scc b2

AX.25 T1 timer adapts depending on link speed (on SCC card).

X-25 (Eicon-card)
=================
Implementation of IP over X.25, currently only for the EiconCard adapter.
This allows routing of IP packets via an X.25 network, thus allowing the
construction of a bridge between different local area networks using NET.
The implementation follows RFC877, transmission of IP datagrams over Public
Data Networks.
Unfortunately, the cost of a connection to the public X.25 network is way
out of reach for amateur use...
This feature is composed of the following subcommands:
    attach eicon <port> <label> <mtu>
        Attaches an EiconCard, previously installed and configured using the
        configuration tools delivered with it.  Only the X.25 Network-level
        software is required (ACCESS/X25).
        <port> will normally be 255 when a single card is installed.
        Subsequent ports are numbered 254, 253 etc (as defined by Eicon).
        <label> is the name of the interface.
        <mtu> should be set to a value of 576 or less to comply with RFC877.
        When an IP datagram is larger than an X.25 packet, the X.25 MORE bit
        is used to fragment it.  When this is unwanted, the MTU should be set
        to a value equal to the maximal X.25 packet size (128 or so).
    arp add <hostname> x25 DTE-address
        Used to map the IP address corresponding to <hostname> to a DTE address
        valid in the X.25 network.  This situation is similar to the method
        used when routing via NET/ROM.  A DTE address is a string of digits,
        up to 15 in length.
    x25 inactime [<time>]
        Sets the time an X.25 VC is allowed to be idle. after this time the
        circuit is disconnected, and set-up again when a packet has to be
        transmitted.  The default is 120 seconds.
    x25 status
        Shows the status of the X.25 Virtual Circuits.
    x25 disconnect <circ_cb>
        Disconnects an X.25 Virtual Circuit before the inactime has elapsed.

SSID scheme
===========
Many users complain about problems with IP and/or selected AX.25 servers.
Please note, that in this software each AX.25 server (defined using
"ax25 port") *must* have a *different* SSID, and that each interface (defined
using "attach") *must* have an SSID *different* from all SSID's used by AX.25
servers.  Different interfaces may use the same SSID, but cross-band
digipeating will not be possible in that case.
The autoexec.net file provided as an example follows these rules, but many
people have modified the SSID's and subsequently had strange problems...
When you use the -0 SSID for an interface, the TNC server *must* have some
other SSID, or IP will not work.  To avoid problems, everybody is hereby
encouraged to use the following SSID scheme (proposed by PE1LGT):

        SSID  Interf    Function
        -0    All       TNC (normal ax.25 connect)
        -1    All       MBOX
        -2    144       2m interface
        -3    144       mheard/NetDigi 2m
        -4    4k8       2m/4800 baud interface
        -5    4k8       mheard/NetDigi 2m/4800 baud
        -6    All       Conference Bridge
        -7    430       70cm interface
        -8    430       mheard/NetDigi 70cm
        -9    All       NET/ROM
        -10   aaaa      interface
        -11   aaaa      mheard/NetDigi
        -12   23cm      23cm interface
        -13   23cm      mheard/NetDigi 23cm
        -14   bbbb      interface
        -15   bbbb      mheard/NetDigi

        aaaa and bbbb usable for other bands, e.g. 28 or 50 MHz

        avoid using the -14 and -15 SSID's on bands where a local NET/ROM
        is operating.

HOSTS.NET
---------
usage of tab and space characters is allowed now.

ICMP
----
Implemented ICMP "Host Unreachable" and "Source Quench" message generation by
the IP router, when the link protocol detects such problems.  This is currently
true for NET/ROM, when it has no route to the requested destination or it's
output queue is becoming too long.  Handling of these messages has always been
present in the package.
The result of this modification is that you may get the message
"Closed (ICMP: Host unreachable)" when a TCP connection is attempted using
a route via the NET/ROM network.

ONEXIT.NET
----------
Introduced "onexit.net" file, executed during "exit", just after all
connections are closed.  Can be used to send param 255's or copy files.

OTHER INFO
==========
Variables now supported in NET commands. see environ.txt for details

Control characters are echoed to the screen as ^<character>.
  They are however still sent as control characters.

With ^V it is possible to insert ANY control character.
  Type ^V, followed by the control character you want to insert.
  (ref. tnc2)

The control block adresses are now 4 hex digits again

All versions: Included an ip_address-to-hostname translator supplied by pe1jlj
(after some modification).  Incoming telnet sessions are now labeled with the
hostname instead of the IP address.

Added yet more checks for NULL pointers (from malloc).  Now prints "No Space!!"
when no buffer is available for a ping (with length >0).  This can cause
mesages when a repeated ping is set up.

HOME and END (Atari: Ctrl-Home) keys now move the cursor to the beginning
and end of the input line, respectively.

The handling of broadcast packets at 9600 baud (as sent by OSCAR14) imposes a
considerable load on the processor and disk.  As it has been observed that some
slower systems already have trouble with 9600 baud AX.25, it can probably be 
stated that an AT system is needed to successfully receive broadcast at this
speed. Tests on the Atari ST (using the SCC interface, TOS 1.4 and a RAMdisk 
for temporary files) have shown no difficulties.

When a DM is received on an open AX.25 connection, the connection is no longer
automatically re-established.  It goes to "disconnected" state after the
message *** LINK RESET from ....

This version includes support for the NEC PC98xx, written by Kohjin JR1EDE.
To accomodate this (and probably other MSDOS machines that are not PC clones),
the environment variable NETCONF is checked during startup.  When it is
defined,
it is searched for the following strings:
        k0      use MSDOS call 06H & assume PC keyboard codes (default)
        k98     use NEC PC98xx BIOS call for keyboard input
        t0      use PC BIOS 55ms ticks at 40:6C (default)
        t1      use MSDOS get_time call
        t98     use 8253 timer in NEC PC98xx
The NETCONF variable can be defined using a SET command in a .BAT file, or
by passing it as a parameter when starting NET.
Example: NET NETCONF=k98t98
You can put this command in a .BAT file together with the COMBIOS startup
command to make startup of NET more convenient.
On non-PC-clones, you will have to set the "ftl0 trace" to 00ef instead of
00ff, to avoid a hangup during an FTL0 session.

Included new segmenter as present in NOS.  This should end the incompatibility
problems between NOS and NET.PE1CHL when using "mode vc".  Of course, it will
introduce the same incompatibility between old and new versions of NET.  Avoid
the use of "mode vc".
Improved checks on duplicate use of a callsign-ssid combination.
Now, duplicate use causes an error message, instead of subtle problems like
"ARP not working" or "No ACK messages on broadcast request".

PBLIST format from DRAFT spec (Nov 4, 1991) implemented, because OSCAR 22 has
started to use it, and this caused an infinite loop with "broadcast download".

A general "pattern matcher" has been introduced, which is now used in
the following places:
     AX.25 mail forwarder, "r" and "w" script lines in .bbs files.
     FTL0 "Open" packet detection
     smtp hold
     netrom filter
Please note that you may have to modify some of your ".bbs" files, when they
contained "r" or "w" lines with some of the special characters defined below.
The pattern matcher uses the same syntax as UNIX programs like "grep", "sed",
"vi" etc.  Note that this is different from DOS filename wildcards "*" and "?".
The following special characaters are recognized in patterns:
     ^    when it appears at the beginning of a pattern, it indicates
          that the pattern should match only at the beginning of the
          string.    e.g.: "^abc" matches "abcde", but not "xyabc".
     $    when it appears at the end of a pattern, it indicates that the
          pattern should match only at the end of the string.
     .    matches any (single) character
     [abc]     matches (single) characters "a", "b" and "c".
     [a-z]     matches any (single) lowercase character
     [^0-9]    matches any character that is NOT a digit
     *    indicates the character or special that immediately precedes
          it, can be present any number of times (0..infinity)
          e.g.:     a*   matches any number of "a" characters
               .*   matches any number of any characters
               [0-9]*    matches any number of digits
     \    generally indicates that the following character is to be
          treated without special meaning.  e.g.: \. matches a ".".
     \(   opens a "memory", which is closed by "\)".  the contents of
          the memory can be referred to anytime later in the pattern,
          using \num, where num is the sequence number of the memory.
          e.g.: \([0-9]\)\1\1\1 matches "0000", "1111" etc.
     \{   used with "\}" for specification of a limited number of matches
          of the preceding character or special.
          a\{1,5}        matches "a", "aa", "aaa", "aaaa" or "aaaaa".
          b\{3,\}        matches strings of 3 or more "b" characters.

All filenames used in the program are now "cleaned" before they are used
to open a file.  Previously, this was done only in certain cases.  The
actions perfomed by the "cleanup" depend on the operating system, but
generally they include removal of control characters, and conversion of
'/' and '\' to the pathname separator character normally used on the
system.  E.g.: now it is possible to say "record /tmp/file" on the
Atari, where this would not have worked previosly (TOS requires a '\' as
the pathname separator).

AX.25 queue length for "virtual circuit" mode is now limited.  IP Packets
beyond a certain limit are discarded, and a "Source Quench" is sent
back.  This should prevent allocation of too much memory for a bad link.
Please don't use continuous ping requests on virtual circuit links,
because these make matters worse when the link is bad in one direction!
(ping replies pile up at the remote end, and normal traffic is slowed
down even more than it already was...)

Txq reported for AX.25 sessions in the "session" command output now is
in bytes, just like the other session types (was in packets).

PC version - general
====================
Attempted to make slightly more heap space available to those poor PC users,
by putting more common text strings in variables (so that they appear in the 
64K datasegment only once).  Now 31552 bytes of heap, hooray.
There is still more than 16K of fixed text in the data segment...

MSDOS version now recognizes DPMI, Windows 3.x on DOS 5.0 or higher, and OS/2.
(in addition to the existing support for DoubleDos and DESQview)
The proper "end timeslice" call will be made to release the processor when
there is no work to be done.

MSDOS version: support for sending IP datagrams over NetBIOS, as specified in
RFC1088.  Attach a NetBIOS-supported interface using:
     attach netbios <lana_num> <label> <buffers> <mtu>
e.g.:     attach netbios 0 nb0 8 512
<lana_num> is the adapter number as used by NetBIOS. Try 0 when you don't know.
<buffers> limits the number of receive buffers used by the driver, when packets
are coming in and NET is not (yet) handling them. <mtu> is the max packet size.
The IP datagrams will be sent as NetBIOS datagrams, using the destination name
"IP.XX.XX.XX.XX", where XX.XX.XX.XX is the HEX representation of the
destination IP address.   Broadcast packets will be sent to "IP.FF.FF.FF.FF".
Your IP address must be defined before the NetBIOS interface can be attached,
because the name to be entered in the NetBIOS name table depends on this value.
Thefore, put the "ip address" command before the attach command.  This has been
changed in the example configuration files.

MSDOS version: Added support for "block transfer" functions in the
FOSSIL and MBBIOS interface routines for "attach com".  This should be
more efficient when using high speed on async ports.  Because of a bug
in MBBIOS this is currently only used for receive with MBBIOS.

MSDOS version: new command "grep <pattern> <file>..." to scan
for a pattern in one or more files.  See entry for PE1CHL.920701 for
description of pattern syntax.  It is NOT the same as for the NODES command!

MSDOS version: support for "Expert Mouseclock" added.  When the driver
for this clock (a DCF77 receiver connected to a COM port) is detected,
the timezone setting is changed automatically depending on the daylight
savings time information bits in the received signal.  Thus it is no
longer necessary to update the timezone setting twice per year.

MSDOS VERSIONS
--------------
Because of the increased codesize and the resulting memory problems in
the MSDOS environment, the set of available versions has been modified
a bit.  A version for MSDOS with both PACSAT and NET/ROM code is no
longer available, as this was not very useful anyway.
The following versions are now available:

  Vers    Features                   AtariST DOS86 DOS286 DOS386 Linux
 ------+----------------------------+-------+-----+------+------+-----
  AX25 | Only AX.25 protocols, no IP|       | ax  |      |      |
  IP   | Only IP (SLIP/ethernet)    |       | ip  |      |      |
       |                            |       |     |      |      |
  User | All except NET/ROM, PACSAT |       | ut  |  u2  |      |
  Sat  | Includes PACSAT protocols  |  ut   |     |      |  u3  | net
       |                            |       |     |      |      |
  Node | NET/ROM, limited userinterf|  nt   |     |  n2  |  n3  |
  Max  | NET/ROM, full userinterface|  lt   |     |      |  l3  |
       |                            |       |     |      |      |

G8BPQ general
-------------

G8BPQ hostmode emulation improved.  New (930808) emulator has to be used!
- downlinks from the NET/ROM to the G8BPQ emulator are now properly made
  as a Host(# call) link, instead of via a local loopback AX.25 connect.
  so, the Hostmode application can now get the correct paclen value for the
  connection to the remote station.  when an F6FBB BBS is integrated with
  a NET/ROM node, the paclen can be set to 0 in PORT.SYS, and the BBS will
  automatically adapt the paclen.
- finally figured how DEDHOST tells BPQCODE that keep-alive packets have
  to be sent (AUTOTIMER flag).  This is undocumented in the G8BPQ Hostmode
  interface specification...
  now, NET sends keepalives (2 NUL characters) when an incoming connection
  to a DX-cluster is via NET/ROM, and disables the idle-disconnect timer
  when it is an AX.25 connection.

MSDOS version: added the G8BPQ hostmode emulator.  See separate G8BPQ.DOC file
for details.  This emulator uses AX.25 ports 11..18, and is started using
"ax25 start g8bpq [<intno>]".  (<intno> defaults to 127)
G8BPQ emulation now also includes UI frames.  This means MAIL beacons
can now be sent, and the application can monitor UI frames as well.

A new G8BPQ Hostmode emulator is included.  It no longer supports the sending
of *** CONNECTED messages, because it was unclear when these messages had to
be sent.  (apparently I don't understand the G8BPQ Hostmode interface specs...)

G8BPQ active
------------
g8bpq active: like "g8bpq status", but shows only those streams for
              which an application is or has been active.

G8BPQ ports
-----------
g8bpq ports:  setup the mapping between G8BPQ radio port number, and
              the interface names normally used by NET.  this is
              necessary because UI frames are normally sent to
              "radio ports" by G8BPQ applications, where these ports
              are known by number.  The NET interface names supplied
              to the "g8bpq ports" command get the BPQ port numbers
              1,2,3 etc.  E.g.: "g8bpq ports 144 430" will setup
              BPQ radio port #1 = NET interface "144", and
              BPQ radio port #2 = NET interface "430".

G8BPQ status
------------
g8bpq status: like the old "g8bpq" command, shows the status of all
              streams.  A range of streams can be shown by specifying
              first (and optionally last) stream number.

SCREEN swap
-----------
"screen swap [y|n]" enables/disables screen swapping.  When this is enabled,
separate screens are created for "command", "trace" and each "session" in the
range 0-9.  When switching between sessions, the existing screen is restored.
This often makes it easier to run multiple qso's, as the previous text typed
in each session can still be seen after typing many other lines and/or commands.
However, the price to pay for this is *memory*.    Each screen costs about
4Kbyte for the standard 25*80 mode, so that about 48Kbyte is required for all 
screens. Therefore, it is not available in the middle-model MSDOS version.
Also, the screen swapping is done using direct access to the videoram, and may
therefore cause problems in multitasking environments. On MSDOS systems, the
access can be done via BIOS, by setting the environment variable "NETCONF=v0"
before starting NET.  However, access via BIOS is so slow that it isn't really
practical to use this method.
On the Atari ST, setting "screen swap on" automatically switches to direct
videoram access ("screen direct"), so if you are using a nonstandard video
adapter it won't work.

Screensize determination in MSDOS version has been enhanced.  Now the
"screen swap" option will also work on super-VGA modes, e.g. 80*50 or
100*40 mode.  When the screen swapping seems to assume the wrong screen
size, it can be overridden by putting NETCONF=s80*25 on the command line
or in the DOS environment.


ATARI version
=============

ATTACH asy
----------
Atari version now supports up to 5 async channels.  The 2 params after
"attach asy" (<addr> and <vec>) can now have the following values:

        addr    vec
         1       0      ST RS232 port using Bcon* calls (BIOS)
         1       1      ST RS232 port using direct access to fifo buffer
         3       0      MIDI port
         6       0      ST-compatible RS232 port on TT030
         7       0      MODEM2 port on TT030
         8       0      SERIAL1 port on TT030
         9       0      SERIAL2 port on TT030

The old <addr> values 0 and 2 remain valid (for RS232 and MIDI).
Ports 6 and 7 could also be used on an ST with TOS 1.2 or higher, and a user-
written device driver (loaded from the AUTO folder) that supports the Bcon*
routines on BIOS devices 6 and 7.  However, on an ST it is not possible to set
the mode and baudrate for these channels so your driver must set the port to
8bit, no parity, 1 stopbit, no handshake and the correct baudrate.
The driver must also supply a FIFO buffer for transmit and receive.

Atari version: made MIDI port fully interrupt buffered.      To use this
feature
(instead of the standard BIOS routines which only buffer receive, not
transmit), use the following form of attach command:
     attach asy 3 1 ax25 430 2048 256 9600 $CALLSIGN-7
The old method remains available, using "attach asy 3 0 ..."
This change greatly improves the performance of the MIDI port, also when
used as a SLIP connection between two machines.

GREP
----
Command "grep <pattern> <file>..." to scan for a pattern in one or more files.
The description of pattern syntax is NOT the same as for the NODES command!

LOG proc
--------
Atari version only: added "log proc" command, to dump the processor exception
area to the logfile, when it contains a valid exception (bombs) dump.
When this command is inserted after the "log <filename>" command in
autoexec.net,
information about a preceeding crash is put in the logfile.
The format is:
Sun Apr 29 15:54:00 1990 exception dump (BP=0005F126)
 00000000 00000020 000023ED 00000020 00000013 00000000 00000001 00000001
 0004E71B 00020284 00000000 0004B5D8 00FDD1F4 00000000 00001804 000017BC
 04FC0B12 000061A0 23080000 180800FC 9DA20000 000A0000 5F360000 03100000
 00460000 000000FE
The BP value is the current basepage address.  This could be the same as
the basepage address at the time of the exception, but this is uncertain.
The following lines are a dump of the area at 0x384, see an Atari internals
manual for more detail.
This command is only intended for software debugging and/or bug reporting,
when you don't understand it's purpose, you do not need to use it!

MEMSTAT <number>
----------------
Atari version: memstat <number> mallocs and frees the specified number
of bytes, to get these from the OS in one big chunk.  Old versions of the
system have trouble with programs making a lot of allocation requests, and
the Mark Williams C runtime makes requests in small (2K) units.
Putting "memstat 30000" or so at the beginning of autoexec.net will acquire
some memory to start with.  The <number> is a long integer.

MEMSTAT dump
------------
Added "memstat dump <file>" to Atari ST version, to dump the heap to a
diskfile.  This can be used to debug the program, but is otherwise of little
use to the end-user.  When you see the number of "bytes used" in the normal
memstat output steadily increasing, please issue a "memstat dump a:memdump" and
send the resulting floppy to me including your configuration files and a short
description of the situation at the time this happened.

SCREEN
------
Atari version: added "screen" command, to select NET's method of screen output:
        screen bios     use BIOS call Bconout
        screen direct   use direct writes to screen memory (fastest)
        screen tos      use standard output (default)
"screen direct" only works on standard resolutions, not on "big screens".

Atari GEM version: fontsize is now selectable, using "screen font <fontsize>".
Values 8,9 and 10 work best on monochrome screens, but larger values are also
possible.  The default on startup is 10. (8*16 system font)

Atari .TOS version: font can be switched between the existing font at startup,
and an IBM-compatible font.  This is useful when accessing a BBS that uses the
IBM special graphic characters, which display as hebrew characters in the
original Atari ST font.   Switching is done using:
     screen font a       (Atari font)
or:  screen font i       (IBM font)
The EGA font can only be used on monochrome monitors.  Note that the
"screen font" command sets the fontsize in the GEM version of the program.
Fonts can't be switched in that version (although you could load an alternative
font before starting NET)

SHELL
-----
On the Atari ST, the shell program to be run is specified using the special
form:
shell =programname

Server FTP - subcommand TPUT
-----------------------------
Added "x" option to "tput" FTP subcommand to update attributes of a file
after it has been sent.  This ensures the file will have the same date/time
and "read only" status on the destination after a transfer.  This is
implemented using an "XATR" FTP command that is sent after each "STOR", 
containing this information in an MSDOS specific format.  For now, this is 
only implemented in the Atari ST version.


UNIX-XENIX
==========

UNIX general
------------
The program is available in 2 versions, net286 and net386.  The '386 version
can use the select() function internally to improve efficiency.  This can be
enabled by starting the program using: net386 select=kt
The 'k' and 't' enable the use of select() for keyboard(stdin) and tty devices.
It is also possible to set an environment variable SELECT to this value.
Testing using SCO XENIX386 release 2.3.2 has shown that the select() function
somehow clobbers the tty input and output buffers, so the use of this option
is not yet recommended.

The "dos" commands CD, COPY, TYPE, RENAME etc. are not implemented.  Use a
subshell or a different window to perform these functions (except CD).
Incoming mail is stored in the /usr/spool/mail directory (or to the directory
defined by the NETMAILS).  This directory must be writable by the user running
NET to be able to receive mail.  The standard mailer can read the incoming
mail,
but I do not yet know how to prepare outgoing mail.  Mail stored in the
directory /usr/spool/mqueue (NETMAILQ), using the same format as in the DOS
version of NET, is transmitted by SMTP.  This directory *must* exist and be
writable for the user running NET.
All configuration files are located in the "current directory" as effective
when the program is started.  It is recommended to create a user "net", and to
put the configuration files and the program in it's home directory.  NET can 
then be started from the .profile, so that logging in as "net" is sufficient.
The FINGER files are stored in a subdirectory "finger", *without* the .txt
extension used by the DOS version of NET.

UNIX version: ihave.bc and frags.bc now put in broadcast directory properly.
Please delete any file xxxx\*.bc you may have on disk (xxxx = broadcast
directory)

Fixed pty location problem in telunix server.  It should no longer silently
close a connection when an active pty is still available.

ATTACH asy
----------
Unix/XENIX release.  Only supports async I/O for now... (SLIP/KISS/NRS)
To attach a serial line, use an attach command like this:

        attach asy /dev/tty1a 0 ax25 ax0 512 256 9600 pe1chl

- the tty device (/dev/tty1a) must be "disable"d, and have read/write
  permission for the user running NET.
- the "0" value can be replaced by "r", "c" or "rc" to set the RTSFLOW and
  CTSFLOW options for the device.
- the next two fields are the type (ax25) and name (ax0)
- the "512" is the size of the read() buffer used for receive
- the "256" is the MTU (paclen)
- the next fields are the speed (bits per second) and callsign

AX25 start tnc2
---------------
TNC2 emulator added to UNIX/XENIX version.  Use is like DOS version (see
entry for version 890515, amongst others)
Instead of the "comnumber", a full pathname for the UNIX device to be
used to access the TNC2 emulator must be given.  This can be a TTY or
a PTY device.  Examples:
        ax25 start tnc2 /dev/tty10=430/3        (KISS mode on a TTY)
        ax25 start tnc2 /dev/ttyp9=144          (cmd: mode on a PTY)
When a TTY is used, the emulated TNC22 "appears" on the RS232 port controlled
by that device.  It will always run at 9600 baud.  When a PTY is used, the
name of the "slave" side of the PTY must be used in the start command, and a
program running in the machine can access the TNC2 using the "master" side
of the PTY (i.e. /dev/pty9p in the example above)
To test the functioning of the TNC2, use "cu" or another communications program
on the pty, or on another tty using an external loopback cable.

LINUX
=====

LINUX general
-------------
A version of the program for the Linux operating system has been
created.  It is compiled using GNU C.  Features are like the earlier
XENIX versions.  Some details are handled different:
-   The "telunix" server provides remote logins to the system using
    "telnet" to the port where it was started (default 23).  This
    requires superuser capabilities, so the program should be installed
    with mode and owner like this:
     -rwsr-xr-x   1 root     users      293897 Mar 18 20:49 net
    Normally, NET will run with the privilege of the user that started
    it, but during short periods when logging "telunix" servers on and
    off, it switches to "root" privilege.  The "telunix" server starts a
    /etc/getty process on the tty corresponding to the free pty it has
    allocated, so this should not be done in /etc/inittab.
    (as was required in the XENIX version)
    When the file /etc/default/getty.telunix exists, it is used to
    provide the getty settings.  If the file does not exist, the normal
    settings file /etc/default/getty is used.  See "man getty" for
    details.
-   The select() system call is used as much as possible, to wakeup
    the program only when something has to be handled.  This saves CPU
    time.  In XENIX, select() has bugs and is not supported on all
    types of devices.  Linux handles select properly, and therefore it
    is used by default (when variable SELECT is not defined).
-   The "termcap" entry of the controlling terminal is used to get
    keyboard sequences for the "special keys" used in line editing.

Async speeds "57600" and "115200" now supported in Linux version.

HOST.NET
--------
In the Linux version, a "dbm" version of the hosts.net, called hosts.db
by default, is used to lookup the hostnames.
The hosts.db file allows a much quicker lookup of hostnames and IP
addresses, because index information is present in the file.  Thus, NET
does not need to do a sequential read of the entire file for each lookup.
When the hosts.db file has not yet been created, an error message is
displayed each time a hostname has to be looked up.  When this happens,
use the "host import" command to create a hosts.db, and then exit and
restart NET so that it has the file available from the beginning.
The hosts.db file is maintained and accessed using a few subcommands of
the "host" command (which has no subcommands in the DOS and Atari version).

HOST subcommand - CLOSEDB
-------------------------
host closedb
  close the hosts.db file immediately (it is automatically closed
  when no lookups have been done for 30 seconds)

HOST subcommand - COMMENT
-------------------------
    host comment <hostname>|[<IP_address>]
      shows the comment info for the specified hostname or IP address,
      when it is available in hosts.db.  e.g.:
	host comment pe1chl
      pe1chl: rob

HOST subcommand - EXPORT
------------------------
host export <filename>
  convert the data in hosts.db back to hosts.net form, and write it
  in the specified file (unsorted)

HOST subcommand - IMPORT
------------------------
host import <filename> [nocomment]
  loads a file (in the hosts.net format) into hosts.db, creating
  it when necessary.  for each line in the file, a record for
  translation from hostname to IP address and IP address to
  hostname is added.  furthermore, the comments (after a #
  character) are stored unless the "nocomment" option is specified
  (which saves space).

HOST subcommand - LOOKUP
-------------------------
host lookup <hostname>|[<IP_address>]
  lookup a hostname and print its IP address, or lookup an IP address
  and print the corresponding hostname.
  This is the same function as the "host" command (without subcommands)
  performs in the DOS and Atari versions.

HOST subcommand - REORG
-----------------------
host reorg
  performs a reorganization of the hosts.db, e.g. after a lot of
  changes have been made.  this reads the existing hosts.db and
  writes all records one-by-one to a new file.  may take some time.

HOST subcommand - UPDATE
------------------------
host update <filename> [nocomment]
  takes a DIFF file between the hosts.net as it was previously
  loaded using "host import", and the new version.  the lines in
  this DIFF are processed to modify the hosts.db: lines starting
  with > are treated as additions, lines starting with < are
  treated as deletions from the file.
  when the "nocomment" flag is present, comments in the DIFF are
  not loaded in hosts.db.
  this command can be used to process the "host update" bulletins
  that are sent through the network by the address coordinator.