OS/2 Shareware BBS: 35 Internet/35-Internet.zip/os2nosv4.zip/wg7jmods.txt

Text File | 1992-11-19 | 112KB | 2,968 lines

          MINI-MANUAL for the mods to KA9Q's
              Internet Protocol Package
                      NOS.EXE
                  version 911229

                WG7J's JNOS v1.06
                  November 19, 1992


                 Copyright, 1992
                Johan. K. Reinalda,
                    WG7J/PA3DIS

            (email:  [e-mail],
             packet: [e-mail])



INTRODUCTION.

    This mini-manual attempts to explain some of the modifications I
made to the KA9Q NOS.EXE program. It is NOT a 'beginner's intro' for the
NOS.EXE program. I assume users have a basic knowledge of the NOS.EXE
program; ie. users should be familiar with using and setting up the
basics of the program.

    The file INTRONOS.ZIP contains an introduction document written
and copyrighted by John Ackerman, AG9V. It is included in this distribution
with his permission.

    Please ALSO read the 'README.NOW' file. This has a cronological and
much more complete listing of the mods i've made in each of the versions.

    Another usefull document might be 'JNOS40.MAN'. This is the manual
    for the port of NOS to the Kantronics Data Engine. A lot of the
    commands in that version are similar to the JNOS code (same author,
    so that happens :-) )... It has sections on setting up ax.25, netrom,
    etc. that might be useful for jnos users.

    Some of the sections in this document are copied directly from JNOS40.MAN,
    since i considered them important issues (and why re-invent the wheel :)

    Some of the modifications I made have been ported into
the 'mainstream' release of PA0GRI's versions 1.9c and later.
They are documented in PA0GRI's NOS_1229.MAN, that accompanies his
releases. Those mods will not be discussed unless needed.
(this concerns mods from v0.93 and earlier)

     Furthermore this manual gives an example of how to use
this code as a full-service BBS. I run the code as the full-
service BBS for Corvallis, OR and surroundings.
The example files listed are from this setup. I do NOT claim
that this is the best way to setup NOS for such purpose. I
simply provide the setup as ONE possible way to configure things.
    The examples and their explanations are far from
a good tutorial. They are simply meant to show the 'reasoning'
I use with handling mail on my system.
    Users deciding to use NOS as a fullservice bbs could use this
as a starting point and go from there...

     For those interfacing with both tcpip based SMTP mail and
the bbs network, I have included a few hints, too.


WHAT'S NEW

     See the file 'readme.now' for a short description of all the mods
for each version...


QUESTIONS BUGS, COMMENTS, REQUESTS, ETC...

        should go to the addresses listed above
        (in that  order of preference!)


CONTENTS:

    COMMANDS/CHANGES.

        1.      mbox commands
                        1.1  attend
                        1.2  convers
                        1.3  fwdinfo
                        1.4  haddress
                        1.5  hideport
                        1.6  jumpstart
                        1.7  kick
                        1.8  mailfor
                        1.9  maxmsg
                        1.10 motd
                        1.11 mailstats
                        1.12 mport
                        1.13 newmail
                        1.14 nrid
                        1.15 past
                        1.16 password
                        1.17 qth
                        1.18 secure
                        1.19 sendquery
                        1.20 smtptoo
                        1.21 status
                        1.22 timer
                        1.23 tdisc
                        1.24 tmsg
                        1.25 trace
                        1.26 utc
                        1.27 zipcode

        2.      netrom commands
                        2.1  alias
                        2.2  bcnodes
                        2.3  bcpoll
                        2.4  call
                        2.5  hidden
                        2.6  interface
                        2.7  load
                        2.8  neighbour
                        2.9  tdisc
                        2.10 route info

        3.      onexit.nos

        4.      at command

        5.      bulletin command
                        5.1  check
                        5.2  date
                        5.3  loophold
                        5.4  return

        6.      callserver

        7.      user permissions

        8.      mailbox user commands

        9.      oldbid

        10.     expire

        11.     ftptdisc and the ftp client

        12.     TRACING

        13.     F-Key SESSION SWITCHING

        14.     NTS traffic deletion.

        15.     FORWARDING.

        16.     SETTING UP THE CONFERENCE SERVER

        17.     OF PACLEN'S, MTU'S, MSS'S AND MORE

        18.     INTERFACE BUFFERS

        19.     PER INTERFACE PARAMETERS

        20.     IP-heard


    CONFIGURING NOS.EXE AS A FULLSERVICE BBS.
                /autoexec.nos
                /ftpusers
                /alias
                /spool/areas
                /spool/rewrite
                /spool/forward.bbs
                /onexit.nos


    GATEWAYING BETWEEN SMTP AND AX.25 MAIL.
                mail from smtp -> ax.25
                mail from ax25 -> smtp

    POP SERVICES IN NOS


    EPILOGUE.


/***************************************************************/


COMMANDS.
---------

1. 'mbox'
        This is the main command used to set most of the mailbox options.
        There are quite a few subcommands, some of wich are discussed here.


1.1     mbox attend [on|off]
        This displays or sets the attend flag. If set, users can initiate
        chat with the sysop via the O)perator mailbox command.
        (You need to have started the ttylink server for this !)

1.2     mbox convers [on|off]
        This displays or set the convers flag. If set, users are allowed
        access to the conference bridge by giving the mailbox 'C' command.

1.3     mbox fwdinfo [string]
        This displays or sets the string that is used in the BBS R: header
        when forwarding mail to other bbs's.

1.4     mbox haddress [string]
        This displays or sets your systems hierarchical bbs address. You do
        not need the bbs call, nor the '.' between the bbs call and the
        hierachical address. EG. mbox ha or.usa.na

1.5     mbox hideport <iface>
        This command allows you to hide a port from the mailbox 'P'
        display. If you set a port to be hidden, a user can not 'see'
        the port unless the user has sysop permissions.
        AX.25 connections will also be disallowed. This is usefull for
        forward-only ports, etc...


1.6     'mbox jumpstart <on/off>' and
        'mbox jumpstart exclude [call1 call2 ...]' subcommands

        The standard 'vanilla' KA9Q code requires users connecting
        to the system to hit an additional line in order to trigger
        the mailbox. This is a problem inherent to the AX.25 protocol.
        If jumpstart is off, the code behaves like this.

        When jumpstart is on, incoming connections that satisfy the
        criteria described next, will get the prompt IMMEDIATELY !

    Presently, incoming connections can be requested for five
different reasons:
A - user connections,
B - node connections to carry netrom 'circuits',
C - IP in VC mode,
D - RSPF run in VC mode, and
E - others (am I forgetting any ?).

    In many situations most AX.25 connections will be coming from
users wanting to connect to the mailbox. When jumpstart is on,
a 'smart guess' is made. The mailbox is jumpstarted IF:

- the incoming connection is NOT a known neighbour node (case B)
- and the interface that the connection came in on
  is NOT in VC mode (case C)
- and the call of the incoming station is not on the excluded list
  (cases D and E); see later

IF the incoming connection satisfies all these requirements, the
mailbox is jumpstarted and the prompt is send immediately.

Some known situations that can cause the mailbox incorrectly to
be jumpstarted are the following:

-If nodes try to connect before we have heard there nodes-broadcast
 we will not know of them as a netrom system and jumpstart the mailbox.
 (this should be solved with the 'netrom load' command now working;
 see later)

-If RPSF is run in VC mode, route updates will be send over a connection
 instead of with UI frames. This will also incorrectly cause a jumpstart
 to occur

In order to prevent these situations, the exclude command can be used.

'mbox jumpstart exclude call1 call2 call3 ...'

will build a list of calls to exclude from jumpstarting.
You can give several call with one exclude command, or give multiple
exclude commands. A simple 'mbox jumpstart exclude' will show the
list...

eg. if you want to make sure that neighbour node k7uyx-1 does not
trigger the mailbox before we've heard one of his node broadcasts, add
mbox jumpstart exclude k7uyx-1

eg. if w7abc is sending rspf route updates via VC, the following helps:
mbox jumpstart exclude w7abc


1.7     mbox kick
        This is an immediate command. If forces the system to start a new
        bbs forwarding cycle.

1.8  'mbox mailfor [interval]' or 'mbox mailfor exclude [area area]'

    Interval is in seconds, and if set, every so often the system
reads all none-area mailboxes and checks them for unread mail.
Next a beacon is sent on all active interfaces. (see 'mbox mport' command).
This beacon packet is addressed to the AX.25 address 'MAIL'.
The data in this packet contains a list of the mailboxes with unread mail.
This is sent in a 'Mail for: <user> ... ' line. Systems like LAN-LINK can
trigger mail-snatches off this. A simple 'mbox mailfor' will show the status
of the timer and list mailboxes with unread mail.

    In certain cases you might not want a private area to show up
in the mail beacon. Eg. private areas to be forwarded to other bbs's.
You can exclude those from the beacon by adding exclude commands.

'mbox mailfor exclude area1 area2 area3'

will disable these area names from the beacon. You can give multiple
exclude commands to build the list. A simple 'mbox mailfor exclude'
shows the list.


1.9     mbox maxmsg [n]
        This displays or set the maximum number of messages in a mailbox
        file, for both private and public (ie area-) mail. If there are
        more the n messages, the user will only see the first n messages.

1.10    mbox motd [string]
        This displays or set the message of the day. This message is displayed
        when regular users log on to the system.


1.11    mbox mailstats

        This commands shows how many messages have been read and sent by users
        and how many messages have been received from and forwarded to bbs's.


1.12    mbox mport [<iface>]

        Displays or sets the interfaces that 'MAIL' beacons are sent on.
        Only ports that have this flags set send the beacons, so you need
        to have one of these line for all ports you want the mail beacon
        to be sent on.

1.13    mbox newmail [on|off]

        If on, users will be notified during the login stage wich areas
        have new mail in them. This uses a time stamp on a status file
        for each message area, and compares this to the last time the user
        logged out.
        The information shown can later be repeated with the 'AN' mailbox
        command.


1.14    mbox nrid [on|off]
        This displays or sets the netrom-id flag. If set, the first time
        a user log on to the system, the system will add the netrom node
        id in NODE:CALL format to the prompt. Users can then change it with
        the mailbox XN command. The system will acknowledge the new prompt
        format as set by the user the next time the user logs in.

1.15    mbox past
        This is displays the users that have logged on since the system has
        been running.

1.16    mbox password <newpassword>
        This sets a new remote sysop password.

1.17    mbox qth [location]
        This displays or sets the location of your system, and uses it in the
        R: headers when doing bbs forwarding.

1.18    mbox secure on|off
        This displays or sets the mailbox secure flag. If set, only users
        coming on over netrom and ax25 connections can make gateway connects
        if they have the right priveledges. If not set, anyone with the right
        privs can do a telnet connect.

1.19    mbox sendquery [on|off]
        If on, users will be queried if they really want to send the message
        after they have typed the ^Z or /ex when sending a message.
        'N' or 'n' will abort, anything else will send the message.

1.20    mbox smtptoo [on|off]
        This displays or sets the smtp headers flag. If set, the system
        will include most smtp header when forwarding the message via bbs
        forwarding. If not set, they will be stripped (the default)

1.21    mbox status
        This displays the current users of the system.

1.22    mbox timer [<nnnn>]
        This displays the forwarding timer value. This sets the interval
        between forwarding attempts.

1.23    mbox tdisc [<nnnn>]

        This command sets an inactivity timer, in seconds. If no user input
        has been received while connected to the mailbox, the user will be
        disconnected. Default time is 0 seconds, ie no timeout.


1.24    mbox tmsg <message>
        This displays or sets the 'telnet message'. This is a message
        sent to telnet connections before the login prompt is sent!

1.25    mbox trace [on|off]
        This displays or sets the value of the trace flag. If set, the mailbox
        is verbose about certains aspect of the forwarding cycle...


1.26    mbox utc [n]
        This displays or set the offset from UTC for this system. It is used
        in the forward code to calculate the current time.

1.27    mbox zipcode [<nnnn>]
        This allows you to set (or show) the systems mail zip-code.
        This is used in the R: line when forwarding.


2.  netrom command

        These commands all influence netrom behaviour.  Not all are discussed
        here.


2. 'netrom' subcommands

2.1     netrom alias <alias>
        Set or show the netrom alias.  There is just one alias for the
        system.

2.2     netrom bcnodes <iface>
        This will force a broadcast of the nodes list on the given interface.

2.3     netrom bcpoll <iface>
        This will force a broadcast poll on the given interface. Systems
        running JNOS1.05 or later, or DataEngines running JNOS40, will respond
        to this by broadcasting their nodes list.
        This speeds up route-discovery at boot time !

        Eg. add this to the autoexec file for each activated netrom interface.
        This was primarily written for the DataEngine code, that doesn't have
        the 'netrom load' from disk capability.

2.4     netrom call <nrcall>
        Set or show the netrom interface call. This can be different from
        the ax.25 mycall parameter, but if not set will default to this.
        This is the call used for all netrom connections and broadcasts.
        Setting the netrom call with 'netrom call' is analogous to
        'ifconfig netrom linkaddress <call>'

2.5     netrom hidden [on|off]
        This displays or sets the hidden flag. If set, the mailbox
        nodes listing (the N command) will not show nodes who's alias
        starts with a '#' character.

2.6     netrom interface [<iface> <quality> [v] ]
        Without arguments, it displays the currently active netrom interfaces.
        If iface and quality are given, it will activate, or change,
        that interface for netrom traffic with the given quality.
        The default broadcast method is non-verbose, ie broadcast ourself only.
        If you want verbose broadcasting, add the optional v parameter.

2.7     netrom load
        This now works as advertized. It will load the netrom routing table
        from the file '/netrom.sav' as written by a previous 'netrom save'
        command.

2.8     netrom neigbour
        Shows a detailed listing of known netrom neighbours.


2.9     netrom tdisc
        This is the same as the AX.25 t4 timer. If set, when no data has
        come in for the timeout period (over the Netrom connection), the
        circuit is reset.


2.10    netrom route info [node name]
        This command, without any node name, gives info about all known
        netrom routes off the system.
        If given with a node name, it will give info about that node only.



3. /onexit.nos

        If present, the 'exit' command will execute commands in the
        /onexit.nos file, before the system exits.
        (this code by iw0cnb, inspired by pe1chl's net.exe)



4. 'at' command

        The 'at' command allows timed execution of valid NOS commands.
        (this command is also from iw0cnb's code, with a few mods.)
        The "at" command with no arguments shows the list of events that
        are to be executed. There are a couple of forms of setting up
        timed execution:

        at yymmddhhmm <command>
        Executes <command> at specified date,
        expressed in Year-Month-Day-Hour-Min.
        If specified date is past, the command is not executed.

        at hhmm <command>
        Executes <command> at specified hour and minute of the current day,
        or of the next day if the specified time is past.

        at mm <command>
        Executes <command> at the specific minutes past the hour at the first
        occurence possible.
        This is usefull to start things like forward cycles at certain minutes
        into the hour.

        at now+hhmm <command>
        Executes <command> hh hours and mm minutes from now. hh and mm can
        be up to 99.

        at now+mm <command>
        Executes <command> when it is mm minutes past the hour.
        Eg. if it's 1:32 now, and you give a 'at 14 ', then at 2:14
        the command '?' will be executed.

        Notes and examples:
        <command> may be any valid NOS command, possibly enclosed in quotes,
        as well as a DOS shell command.
        If you want multiple commands to be executed, use the
        "source <filename>" command.
        The third mode of operation requires the exact writing "now+" in
        lower case and without spaces between hhmm.

        Single command execution examples:
        at 9202150900 exit   /* Shuts off on 15 Feb 92 at 9:00am */
        at 2245 "! /c pkzip oldmail \spool\mail\*.*"
        at 25 "mb timer 3600"
        at now+0500 "smtp kick"

        Multiple command execution examples:
        at now+0859 "source cleanup.net"

        When multiple command execution is setup, this command allows
        all sorts of interesting things;
        if for example 'cleanup.net' has the line
        'at now+0859 "source cleanup.net"
        then the commands in the command-file 'cleanup.net' will be executed
        every 9 hours



5. 'bulletin' command
        All of the subcommands have to do with interpreting the R: lines sent
        when a bbs is forwarding to our system.

        5.1  bulletin check [<on|off>]

        If 'on', a list of bbs's that we forward to is automatically read
        from forward.bbs. Next, when a bbs forwards mail to us, all 'B' type
        messages and all mail with a BID is checked. The R: headers trail is
        read and checked for bbs's in our list. If found, X-Forwarded-To
        headers are added to the internal mail headers of the message. These
        headers are read by the forward code and prevent forward attempts for
        messages that are already at the destination forward bbs. This makes
        the forward code more efficient. (All messages with a BID are checked
        to make it work with things like 'sp sysop @ allusw < $bid')
        Plain 'bulletin check' will show status, and if on, the check-list.


        5.2  bulletin date [<on|off>]

        If 'on', when a message is forwarded to us from a bbs, the R: headers
        will be read to obtain the message origination date from the last
        R: header present. This will then be used as the 'Date: ...' line in
        the message, thus better indicating the message's age.

        5.3  bulletin loophold [<#>]

        This sets or shows the number of loops after wich a message will be
        held and not forwarded anymore. Default is 2. If a message if receive
        that already has this number of our header lines (ie. R: lines) in
        the message-headers, it will be marked as held.


        5.4  bulletin return [<on|off>]

        If on, when a message is received via bbs-forwarding
        a 'valid bbs-style return address' will be taken from the
        last R: header, if one is present. This works with any message
        type that starts with R:-headers (so personal mail as well).
        This address will then be used as the 'From: ...' line in the message
        eg. If the message is forwarded as 'SP W7ABC < W6XYZ'
        and the last R:-header is
        R:920312/1200z @:N7PQR.AB.CD.EF [TEST] #:0 Z:1
        then the 'From:' line will read:
        'From: [e-mail]'

        IMPORTANT !!!!
        Since in most of these occasions, the from-hosts will NOT
        be tcp/ip hostnames (eg. wg7j.ampr.org) but rather
        bbs H-addresses (eg. WG7J.OR.USA.NA)
        YOU (ie. the sysop) HAVE TO MAKE SURE your system can handle
        these new addresses by setting up the ALIAS and REWRITE files
        to handle these, and then setup bbs-forwarding (if needed)
        as well with FORWARD.BBS (see later for examples)



6. 'callserver <host> <port>' command

        This configures the <host> (ie. hostname or address) and
tcp <port> to be used in the mailbox 'CALL' command (See later).
This 'CALL' command is an alias or shortcut for an automatic telnet
connect to set host and port.
        This is mainly useful for gateway systems on Internet.
It allows users to use a tcp-reachable callbook-server in an easy way.
(or for that matter, any service reachable via telnet)
Note: User needs to have telnet permissions

eg: 'callserver marvin.cs.buffalo.edu 2000'
then the mailbox 'call' command will try to telnet to this host/port
and users will be connected to the callbook server.



7. MAILBOX USER PERMISSIONS

    The user permission in 'ftpusers' have the following values:
#define FTP_READ        1       /* Read files */
#define    FTP_CREATE    2    /* Create new files */
#define FTP_WRITE       4       /* Overwrite or delete existing files */
#define AX25_CMD        8       /* AX.25 gateway operation allowed */
#define TELNET_CMD    16    /* Telnet gateway operation allowed */
#define NETROM_CMD    32    /* NET/ROM gateway operation allowed */
#define SYSOP_CMD    64    /* Remote sysop access allowed */
#define EXCLUDED_CMD    128    /* This user is banned from the BBS */
/* 256 and 512 are used in PPP*/
#define NO_SENDCMD      1024    /*Disallow send command*/
#define NO_READCMD      2048    /*Disallow read command*/
#define NO_3PARTY       4096    /*Disallow third-party mail*/
#define IS_BBS          8192    /*This user is a bbs*/
#define IS_EXPERT    16384    /*This user is an expert*/
#define NO_CONVERS      32768   /*Disallow convers command */

NOTE: the 'mbox expert' command is gone; each user now has a status bit
for this. The mailbox 'X' command will toggle status, but not upgrade
ftpusers...



8. MAILBOX USER COMMAND CHANGES

    First of all, the present code KEEPS TRACK of the user's 'progress'
in public areas. The message id of the last message listed in remembered
and when the user changes areas or logs off, the id is stored in a
<areaname>.USR file. These files are automatically created as needed
in ~/spool/mail . Next time a user changes to the area, the L command
will only list messages newer than the last one previously listed.
    There is one exception: the area 'HELP' (if it exists) will NEVER
be kept track off. All messages will ALWAYS be new.
My users agreed that this was a good way of easily accesing help-messages.
My 'mbox motd' points out the help area, and not logging this causes all
help messages to be listed each time the 'L' command is given. New users
do not need the LM, LA, and LL subcommands...

    The mailbox supports several new commands; several of them implement
popular user commands from other bbs software.

- A, AF and AN
        A will give a listing of available message areas; AF gives the
        same listing, plus a description of each area if set by the sysop
        AN will list wich areas have new mail since a user last logged out.

- IP    show the ip routes the system maintains.

- RM and VM
    is now supported. It will 'read' or 'verbose' at most 19 new messages
    in the current area. (19 is inherent to the cmdparser and the current
    implementation of RM and V)

- RH
    to Read with Headers, is the same as 'V'

- KM
    to Kill Mine, kills all read messages in current area.

- KU
    to Un-kill a message that was previously marked to be killed.

- LM, LA, 'L> xyz' and 'L< xyz'
    are now supported. LM is the same as 'L', and simply lists new messages.
    LA will list ALL messages in the current area.
    L> and L< will search for the string 'xyz' in the To: and From: field,
    respectively.

- M, ML, and MS
    The 'M' command shows Mailbox-users and their activities. (reading,
    sending, uploading, idle, etc...) Users in sysop mode will show as
    Idle to regular users and as 'Sysop mode' to users with sysop privs

    ML shows all users that have connected since the system was started,
    how many times they logged in, and the time since they last logged in.

    MS shows the status of messages (same as 'mbox mailstatus'),
    and also gives a few system 'health and use' parameters.


- CALL
    If compiled in, tries to establish an automatic connect to a host
    and port as setup with the 'callserver' command. This is mainly
    useful for systems on internet that want to allow users to access
    callbook servers (eg. marvin.cs.buffalo.edu:2000).

- NR
    Nroutes will show a detailed list of all known netrom neigbours
    (same as 'netrom neigbour' subcommand)

- 'N *'
    This gives info on all routes

- Q call
        If compiled in and configured, this will query the HamBase CD-Rom
        callbook for the given call.

- X
        will toggle the prompt between long and short version

-XA     will toggle the area indication on and off.

-XN     will toggle the netrom-id prompt on and off.

- XM    shows the number of line before more? will be prompted.
        Defaults to 0 on anything but telnet connects and 24 on telnets.
  XM n  will set the more? prompt to n lines.

  NOTE: the above X command setting are retained across logins.

- SR and SC
    SR: Send Reply works again.
    SC: Send with Carbon copy. The system will ask the user for a list
        of addresses to also send the message to. It prompts "Cc: "
        User can then type additional addresses, separated by comma's
        to wich the message should go aswell
    eg:
    you type:       "SC johan""
    system replies: "Cc: "
    you type:       "ron@wa7tas,ka7ehk@wg7j, allor"
    system replies: "Subject:"
    etc...


9.   'Oldbid' command

        As of v1.01 all bid's (bulletin id's) stored have a timestamp
added. This facilitates the automatic deletion of old bid's.
The 'oldbid' command will expire bid's older then a certain age.

To setup bid expiry, the format of the command is:
oldbid interval [age]
where interval is the interval time in hours,
age is the age of the bid in days.
If no age is specified, it defaults to 21 days.

When the command is first given, the bid file is scanned for old entries,
and then every 'interval' hours it is scanned again.
The old bid file (/spool/history) will be renamed to /spool/history.bak,
and then all entries still valid are copied over to a new history file.

Giving plain 'oldbid' will show the status of the timer and the age set.


10. 'expire' command.

        As of v1.01, there is a very simple automatic message expiration
capability. Messages older then a given number of days will be deleted
from the mailbox file after a backup copy of the whole file has been made.
        Configuring automatic expiration consists of 2 parts:
a - setting the interval timer.
    This is done with 'expire n', where n is the number of hours between
    expire checks.
    * A simple 'expire' will show the status of the timer.
    * 'expire now' will start expiration immediately and restart
      the timer (if set)

b - Configuring the '/spool/expire.dat' file.
    This file is the control file read by the expiry process.
    It contains entries of mailfiles and ages. The format is
    'areaname age', where areaname is a valid mailbox file in /spool/mail
    and age is the maximum age in days.
    Any format to indicate mailfiles in subdirectories below /spool/mail
    is valid, so either '/', '\' or '.' can be used.
    Lines starting with '#' or blank lines will be ignored.

    NOTE1: the areaname should NOT have the .txt extension added !!
    NOTE2: the 2 fields have to be separated by one space!!
    NOTE3: expiring messages in subdirectories has only been tested with
           smtp mail files, NOT with NNTP originated messages. Thus it
           might not work with those...
    NOTE4: the date used is the entry in the 'Date: ' header,
           NOT the entry in the 'From ' line that starts the message.
           Thus, if the 'bulletin date' command is on, the origination date,
           not the reception date, is what expires a bbs message.


    Some examples:
    in autoexec.nos:

    # expire once a day
    'expire 24'

    in /spool/expire.dat:

    #keep this area very short
    allusa 7
    #this is in a subdirectory below /spool/mail
    rec.radio/amateur\packet 21
    #and so on
    allor 14
    pnw 10



    HINT: if you want the expiration of bulletins to occur at a certain time
    of the day INDEPENDENT from when you start NOS, use the 'at' command
    eg:
    if you want it to happen in the middle of the night
    (assuming your system's clock is in local time ;-) )

    'expire 24'                 #sets the interval
    'at 0200 "expire now" '     #forces expiration, and restarts the timer



11. 'ftptdisc' command

        This commands sets or shows the ftp user inactivity timeout.
    If not zero, when a user connects to the ftpserver, the timer will
    be started. If user doesn't give a command for the timeout period,
    the session will be closed. This is disabled during any transfer;
    ie it only works while the user is in command state...

    Doug Crompton, WA3DSP, has added some online help for the ftp command,
    the iw0cnb resume code, and more. Here is what Doup writes about that:


        I have added some FTP commands and updated some others. This is
        going in my direction of a more user friendly NOS.

        FTP added commands (at the ftp prompt)

        'h' || '?"

          Display FTP help - list ftp available commands

        'lcd'

          List current LOCAL directory. The local directory inherits the
          system current directory at FTP start. Each ftp session started
          by the client has it's OWN copy of the state of current directory.
          This directory prefix based on the rules below is applied to local
          filenames used in put/get/mput/mget commands. Path names entered
          are checked for validity of both drive and directory on the current
          system. This should work for any valid DOS drive/directory on the
          system such as CDROMS.

        'ldir <path>'

          List directory. Current directory is listed if path is omitted. Path
          is appended to current local directory unless it contains a '/' in
          the first position, a ":" in the name, or the '.' or '..' charcters.

          Examples:

            If the working directory (set by lcd) is set to 'c:/temp' and
            the ldir command path is not entered the path becomes 'c:/temp/*.*'
            If the ldir path is '/nos' the path becomes 'c:/nos/*.*' If the
            ldir path is 'a:' the path becomes 'a:*.*' and if the ldir path
            is 'temp2' the path becomes 'c:/temp/temp2/*.*'

            In short it is what you would expect.  '.' and '..' are supported
            in both directory paths and filenames.

        'lmkdir <path>'

            Same rules apply as above.

        'rput <localfile> <remotefile>'

            Resume putting the file at a remote server. This will restart
            a previously interrupted put. Note that you must have overwrite
            priveledge at the server to do this.

        'resume <localfile> <remotefile>'

           Resume getting a file from the remote server. This will restart
           a previously interrupted 'get'

           Both of these commands depend on an unchanged source file and a
           partial file. The partial file is compared to the original and
           only the remaining bytes are sent.

        An example of the use of these commands would be:

            ftp wa3dsp
            login ...
            connected ...

            ftp>cd /pub/docs
        ^P ftp>lcd c:/tcpip   << directory exists
            ftp>mkdir docs
            ftp>lcd docs
            ftp>mget *.*

           This would copy all files at the server in diretory /pub/docs
           to the local directory c:/tcpip/docs   This is just one example,
           often you would set the remote directory 'cd <path>' and the
           local directory 'lcd <path>' and then simply say 'get <fname>'
           or 'put <fname>'. Added to this flexibility is the ability to
           do this in multiple sessions to different or the same server(s).

        Further Directory Examples:

            ftp>lcd
            Current Directory - c:/tcpip
            ftp> lcd spool
            Current Directory - c:/tcpip/spool
            ftp> lcd ..
            Current Directory - c:/tcpip
            ftp> lcd d:
            Current Directory - d:/dosdir    << if 'd' drive exists and this is
            ftp> lcd temp                            the first logon to this drive
            Current Directroy - d:/dosdir/temp       it assumes the DOS current
            ftp> lcd c:                              directory for this drive.
            Current Directory - c:/tcpip
            ftp> d:/
            Current Directory  - d:/


        The Nos main command 'dir' now uses the same rules as 'ldir' above.
        You can now do 'dir a:' - which expands to 'dir a:*.*'

           Example:
                                  EXPANDS TO
            pwd c:/nos
            dir                   >> dir c:/nos/*.*
            dir spool             >> dir c:/nos/spool/*.*
            dir /spool            >> dir c:/spool/*.*
            dir a:                >> dir a:*.*
            dir spool/mail/*.txt  >> dir c:/nos/spool/mail/*.txt

        Try this one...

            get anyfile.xxx
            (wait until half or some portion of the file is received)
            F10
            reset
            Establish the ftp connection again
            resume anyfile.xxx (must be same name as above)
            (and the rest of the file will be sent)

        Added Functions -

        In ftpcli.c

        static int doldir  __ARGS((int argc,char *argv[],void *p));
        static int dolcd  __ARGS((int argc,char *argv[],void *p));
        static int dolmkdir __ARGS((int argc,char *argv[],void *p));

        In dirutil.c

        char * make_dir_path(int count,char *arg,char* curdir);
        char * make_fname(char * curdir, char * fname);
        char * init_dirs(struct cur_dirs * dirs);
        void free_dirs(struct cur_dirs * dirs);
        int dir_ok(char * path,struct cur_dirs * dirs);


        struct cur_dirs {
                   int drv;
                   char * curdir[27];
                   char * dir;
        } ;

        In pathname.c and pathname.h

        Function 'crunch' - remove 'static' definition

        Using these functions - Example:

        #include "dirutil.h"
        and other required headers...

        main()

        {
                char newpath[128],fname[128], *p;

                /*
                 * Create Structure 'dirs' which stores
                 * local status of system drives and directories
                */
                struct cur_dirs dirs;

                printf("Local Directory - %s\n",init_dirs(&dirs);
                gets(newpath);

                /*
                 * Pass Requested path and dirs structure
                 * to 'dir_ok' - returns 1 on success, 0 failure
                */

                if (dir_ok(newpath,&dirs) {
                   p=dirs.dir;
                   printf("Current Directory - %s\n",p);
                } else {
                   printf("Invalid Directory - %s\n",path);
                }
                gets(fname);

                /*
                 * Pass Requested filename and current directory pointer
                 * to 'make_fname' - returns pointer to fully qualified
                 * name
                */

                printf("Fullpath = %s\n",make_fname(p,fname));

                /*
                 * Cleanup allocations done in above functions
                */

                free_dirs(&dirs);
        }


        An example of how this is done in NOS code is in 'ftpcli.c' Here
        a structure pointer to 'dirs' is stored in the 'ftp' structure.
        Pathname is changed in the 'lcd' function and calling parameters
        follow the requirements for passing a structure to a structure.

        In ftpcli.c

        function 'doftp'

                struct  cur_dirs dirs;
                ftp.curdirs = &dirs;

                .....

                tprintf("Local Directory - %s\n",init_dirs(&dirs));

                .....

                free_dirs(&dirs);

        functions to get/put local files - ftp structure passed

                                             vvvvvvvvvvvvvvvvv
                if((filel = fopen(make_fname(ftp->curdirs->dir,&argv[i][1]), "r")) == NU
        LLFILE){
                     tprintf("Can't open listfile: %s\n", &argv[i][1]);
                     continue;
                }

        lcd function - ftp structure passed

                                    vvvvvvvvvvvv
                if (!dir_ok(argv[1],ftp->curdirs)) {
                     tprintf("Invalid Drive/Directory - %s\n",argv[1]);
                     return 1;
                     }
                }                                vvvvvvvvvvvvvvvvv
                tprintf("Local Directory - %s\n",ftp->curdirs->dir);
                return 0;


        *************************************************************************

           In general the current directory/filename handling in NOS needs
        to be looked at. It is not clear what depends on the system working
        directory. I would rather see nothing depend on it since it is a
        global value which effects all file and directory operations. Since
        NOS is a multitasking system it makes sense to keep this value private
        as needed in each session. The dirutil.c file needs some cleanup which
        I did not get to. In particuliar I suspect the wildcardize function
        is obsolete given the new code. Also as the function parameters are
        always put through 'undosify' (\ to /) tests for '\\' are not needed.
        If your function needs '\'s changed to '/'s call undosify(char *) This
        applies to MANY places in NOS where this conversion is done over and
        over. Granted it is just a couple of lines but that adds up!! Has anyone
        ever compiled a list of all of the functions in NOS with a brief description
        of what they do so that others can use existing code?

           There is no reason to change either the drive or directory at the
        DOS level in NOS and in fact with a multi-tasking system this is kinda
        dangerous. Especially if other functions are not aware of it. Better yet
        use FULLY qualified drive/directory names. These functions have been
        applied to the ftp client routines but there is no reason why they could
        not be used in the server also. Maybe with an additional 'permission
        file' drives and directories could be authorized. Something like:

         c:/pub/ * 3          < trailing slash - this and all below
         c:/games * 3         < none below
         d:/ *  3
         m:/ *  1             < maybe a cdrom
         c:/myfiles mypass 7  < password protected

        This would allow a user to specify drive/directory authorization on
        a system and even specify a password for that directory - assuming
        the authentication code was used (future) this would work. The ftpusers
        files would specify the login user/pass and the login directory. This
        file would specify what drive/directories were permitted on the system
        and what level of permission each had.


        Doug WA3DSP


12. TRACING

        Tracing can now be done to a separate session. This is the new
    default. You can toggle to and from this trace session with the
    F9 key.
        Sometimes there are times you want to see the tracing while
    typing some commands. This can be done with the new command
    'strace on/off'. This defaults to ON, but when turned off,
    tracing will go to the command screen. If then turned on again,
    it will go to the trace (F9) screen again...

    For the memory hungry, session tracing can be turned off
    from the command line that starts NOS.EXE. Start it with a '-n'
    option to save about 4 kbyte of memory. This turns of the
    functionality of the 'strace' command...
    eg 'nos -n'


13. F-Key SESSION SWITCHING

        Funtion keys F1-F8, if not defined as macros by the 'fkey'
    commands, will switch FROM ANY SESSION to the session of that
    numbers. eg. F3 will switch to session 3, no matter wether you
    are currently in the command, trace or any other session.

    If any of these F-keys is defined with the 'fkey' command,
    that session switch is disabled. (I use F5-F8 here for some
    quick keys, which leaves the first 4 session one keystroke away !)


14. NTS traffic deletion.

        In order to ease NTS traffic handling, ANY user can now delete
    ANY message in areas who's name starts with "nts" (case is not
    significant). This allows users to delete traffic after delivery,
    without having to give them permission to delete all other mail
    as well (we wouldn't want that now, would we ;-)
        So area names like "nts", "ntslocal", or whatever you want
    to rewrite nts traffic to fall in this category.
    Any "nts*" mailfile (i mean wildcard here) that is NOT an area
    (ie not in /spool/areas) is still 'untouchable'
    (unless offcourse the user has permission to do so)


15.  FORWARDING.

        BBS forwarding now can be 'scripted'. The format of forward.bbs
        file is expanded:

  w0rli                 <- still the bbs to forward to
  ax25 ax0 w0rli        <- still how to forward to
  [ multiples of:
  .send this text
  +continue if this string is received
  @wait_this_long for a reply  ]
  w0rli                 <- the areas to forward...
  pnw
  north
  -----------           <- end of this entry

  Valid connect-script lines are:

  '.' lines are like before. The text following will be sent over the
        connection.  This line doesn't need to contain text. In that case,
        a <cr> only gets send.
        NOTE: This will also reset the '+'  reply search string to null!

  '+' lines set a reply string to search for when a line is being received
        with the @ command.

  '@' lines set a timeout in seconds in wich to receive a line over the
        connection. This is the maximum time the system will
        wait for a reply. At this point, an attempt is made to receive a line
        from the connection in the time specified.
        If nothing is received after the timeout time, forwarding for this
        entry is cancelled.
        If something is received, and a search string was set with the
        + command, forwarding will be continued only if the search string
        appears somewhere in the line received.
        If the search string was not set, forwarding is continued.

        NOTE: if the value after @ can not be converted to a number, the
        default is 90 seconds.
        NOTE: the search string is reset if forwarding continues after the
        @ command.


   You can have as many of these lines to establish a connection. They need
   not be in any particular order.

   CAVEAT:
   Replies from the connection need to be full lines; ie they have to be
   terminated by a proper end-of-line sequence. This means you can not wait
   for the login prompt from a NOS system, since those are NOT terminated
   with a end-of-line sequence. (see the examples)
   You need to know the EXACT reply from systems you connect through.
   Each @ command reads only one line of data from the connection (if
   any, offcourse). This means that if a system replies multiple lines
   after a connection is made, you need multiple @ commands. (see the
   examples below). This makes it hard to connect via systems that can
   have varying replies, like NOS systems that do not have your system
   marked as a BBS, and thus will send welcome messages and varying
   message-of-the-day etc...


Some examples:

1- a connection via a netrom neigbour:
        w0rli
        ax25 ax0 k7uyx-1        <- initial connection to netrom node
        .c rlimb                <- ask for a netrom connect from this node
        +Connected              <- if we don't get this, things went wrong
        @60                     <- maximum one minute wait !
        w0rli                   <- forward these areas...
        pnw
        allor
        ---------

2- a connection via a JNOS system .
   This assumes that you are marked as a BBS at the JNOS system, so that
   you only get a '[JNOS...] and '>' prompt...

        n7dxt
        ax25 iposu              <- initial connection to the JNOS system
        +[JNOS                  <- wait for sign-on message from the JNOS box
        @15                     <- don't wait longer then 15 seconds
        +>                      <- wait for the prompt
        @15                     <- wait 15 seconds at the most
        .c ax0 n7dxt            <- next, request a gateway connect
        +Trying                 <- NOS replies it's trying...
        @15                     <- wait 15 secs max.
        +Connected              <- wait for 'IPOSU:WG7J-3} Connected to N7DXT'
        @60                     <- wait 60 secs max
        n7dxt                   <- send these following areas
        pnw
        allor
        ----------

3- A connection to a JNOS system, and from there a telnet to a remote bbs
   (again, assumes your system is marked as a bbs !)

        wg7j
        ax25 con iposu          <- initial connection to JNOS
        +[JNOS                  <- sign-on from JNOS
        @15                     <- shouldn't take too long
        +>                      <- next is the prompt
        @15                     <- not too long either
        .t wg7j.ampr.org.       <- ask for a telnet connect
        +Trying                 <- JNOS is trying
        @15                     <- should come pretty soon
        +connected              <- wait for '*** connected to xxx'
        @45                     <- might take a while
        @30                     <- wait for another (blank) line
        +NOS                    <- now come the telnet sign-on message
        @30                     <- wait for this
        @30                     <- after this is a blank line, wait for it
        .w0rli                  <- now we get 'login:' and "Password:" prompts,
        .whomever               <- but they have no <cr>'s, so just answer
        sysop                   <- we're there, forward these areas.
        allor
        wg7j
        pnw
        nos
        ------



SETTING UP THE CONFERENCE BRIDGE
--------------------------------

        The conference facilities in JNOS40 can be accessed in three different
ways. Each way can independently be turned on or off.

        Before you enable any of these, you should set the convers hostname
to an appropriate name with the 'convers host' command.  If not, it will
default to the hostname.


        CONFERENCE CALL ACCESS
        First, a user can do an ax25 connect to the conference call.
You can set this call with the 'convers mycall' command.
You can set a separate inactivity timeout for these connections with the
'convers t4' command.
Eg. our local node is CRV:K7UYX-1 in Corvallis, OR. You could set the
conference call to 'convers mycall QSO' and users can connect to
it to get directly to the conference bridge. If you want a long timeout,
use eg. 'convers t4 3600' for a one hour timeout. (default is 2 hours)

Next, you need to tell the system wich interfaces you want the conference call
to be active on. You might not want conference call connections on backbones,
or to avoid confusion with other systems using the same alias for the conference
call, etc.
Note: you can only do this AFTER you have attached the interfaces !
        convers interface 1
        convers interface 2
        convers interface 3


        NODE ACCESS
        Second, a user can connect to the regular node call,
by connection to the netrom alias (if used), the interface call or the
netrom call (if used). Then the user can give the 'C' command to join
the conference bridge. The permission to do so defaults to on, but
can be turned of with 'mbox convers off'.

        CONVERS SERVER ACCESS
        Last, there is the network server. This service listens to telnet
port 3600 and allows both users and remote conference servers to link to
you. It defaults to on, but can be stopped with 'stop convers'.


        LINKING TO REMOTE SERVERS.
        If you want to link to other conference servers, configure them
with as many lines as you need. You can add new links at any time.
Eg: 'convers link 44.26.0.4'


NOTE: is is very important to avoid link loops. They cause messages to
fly around in circles, thus overloading the network.
Eg. if you link to w0xyz, who in turn links to w0abc, there is no need for
either one of those to link back to you !

So to wrap it all up, something like this should work:

convers host Corvallis
convers mycall qso
convers t4 3600
convers interface 1
convers link 44.26.0.4
convers link 44.26.0.3
mbox convers off                #if you don't want nodeshell access



        A litte on CONFERENCE INTERNALS.

        The conference server in JNOS40 is modified from the convers code
in NOS.EXE, but is identical to the stuff in the JNOS releases.
Messages sent by a user get sent to all users on the local system as well
as all users on remote systems. All local users get their own copy of a message.
For users at remote systems, only one copy of the message is send across all
the remote links available. Say there are 3 local users, and 2 remote links
with 5 and 4 users respectively. If a local user sends a message, there will
be 4 copies sent: 2 to the 2 remaining local users, and 1 message each across
the 2 links. The message sent across the links will then be distributed to the
users at each of the linked servers.


OF PACLEN'S, MTU'S, MSS'S AND MORE
----------------------------------

Setting Bufsize, Paclen, Maxframe, MTU, MSS and Window

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

1.  AX25 Parameters

1.1.  Paclen

Paclen limits the size of the data field in an AX.25 I-frame. This value does
not  include  the  AX.25  protocol header (source, destination, digipeater
addresses, control and pid bytes).  The AX.25 V2 protocol specifies a maximum
of 256 bytes for the paclen.
Be aware that some AX.25 implementations can not handle paclen greater then
this, however NOS derived systems can handle this situation.
This may cause interoperability problems. Even Nos may have trouble with cer-
tain KISS TNCs because of fixed-size buffers. The original KISS TNC code  for
the  TNC-2  by  K3MC can handle frames limited in size only by the RAM in the
TNC, but some other KISS TNCs cannot.

Since unconnected-mode (datagram) AX.25 uses UI frames, the paclen value has no
effect in unconnected mode. IE. if you run IP in Datagram mode, you can still
have an MTU > Paclen !  (As long as your receive buffers can handle the mtu
size; see INTERFACE BUFFERS...)

In JNOS40, and JNOS v1.05 (and greater), paclen can be set on a per interface
basis with the 'ifconfig <iface> paclen ###' command.
Thus you can have a paclen of 256 on one interface and a smaller or larger
on other interfaces.
When you first attach an interface, the paclen defaults to the value of the
'ax25 paclen' setting (this defaults to 256.)

If you want to carry netrom data over ax.25 links, the system needs to make
sure the paclen is large enough to handle the netrom MTU sized data.
Net/rom mtu is a maximum of 236; with a 20 byte header for the routing,
this gives a data size of 256 to be send with ax.25 packets.

In most versions of NOS.EXE, you can get problems when you use netrom and set
the paclen < 256. When the ax.25 layer gets to send netrom frames, it cannot
handle the whole data in one packet. It will then split it up in several
smaller frames, using the AX.25 Version 2.1 fragmentation scheme.
However, TheNet, Net/Rom, G8BPQ, MSYS and other nodes CAN NOT handle this
type of  fragmentation, resulting in impossible connections !

However, if you are running JNOS40, or JNOS v1.05 (or greater) for the PC,
you need not worry about this.  These 2 version of NOS have been modified
to never provide more then paclen sized netrom data to the ax.25 layer !
Thus the above problem will never happen...


1.2.  Maxframe

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

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


2.  IP and TCP Parameters

2.1.  MTU

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

There is no default MTU in Nos; it must  be  explicitly  specified  for  each
interface as part of the 'attach' command.
This is not the case for the netrom interface.  Since ip data is carried
inside a 'regular' netrom frame, the ip data should never be larger then the
maximum data size the netrom protocol can handle.  The default mtu here is 236,
wich is the protocol maximum.

If you plan on running IP in Datagram mode (the default), you can have an
MTU that is larger then the paclen for that interface.  However, you should
still be aware of the constraints of the receiver buffer size! (See INTERFACE
BUFFERS)

If you plan on using IP in Virtual Connect, or VC, mode, you should be aware
of the following.  If you set the IP MTU larger then paclen for the interface,
you will hand a packet to the ax.25 layer that is larger then what it can
send in one packet.  Thus you will get AX.25 V2.1 fragmentation.
If you are exchanging ip data with NOS based stations only, you have no
problems (other then the fragmentation).
If you are interfacing with stations other then NOS bases systems, you again
will have troubles, like with netrom.  They will most likely not be able to
handle the packets correctly.
Thus be aware that in this case you should set the mtu to equal the paclen,
to avoid these problems.


2.2.  MSS

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


2.3.  Window

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


2.4.  Discussion

2.4.1.  IP Fragmentation vs AX.25 Segmentation

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

Most subnetworks that carry IP have MTUs of 576 bytes or more,  so  intercon-
necting  them  with subnetworks having smaller values can result in consider-
able fragmentation. For this reason, IP implementors working  with  links  or
subnets having unusually small packet size limits are encouraged to use tran-
sparent fragmentation, that is, to  devise  schemes  to  break  up  large  IP
datagrams  into  a  sequence  of  link  or subnet frames that are immediately
reassembled on the other end of the link or subnet into the  original,  whole
IP  datagram without the use of IP-level fragmentation.

Such a scheme is provided in AX.25 Version 2.1. It can break a large IP or
NET/ROM datagram into a series of paclen-sized AX.25 segments (not to be
confused with TCP segments), one per AX.25 I-frame, for transmission and
reassemble them into a single datagram at the other end of the link before
handing it up to the IP or NET/ROM module.

Unfortunately, the segmentation procedure is a new feature in AX.25 and is not
yet widely implemented; in fact, Nos and derived software, is so far the only
known implementation. For regular NOS systems this can create some
interoperability  problems between Nos and non-Nos nodes. However, JNOS40 and
JNOS 1.05 (or later) have provisions built in to avoid these problems.
This problem is discussed further in the  section on setting the MTU.


2.4.2.  Setting MTU

TCP/IP header overhead considerations similar to those  of  the  AX.25  layer
when  setting paclen apply when choosing an MTU.  However, certain subnetwork
types supported by Nos have well-established MTUs, and these should always be
used  unless  you  know  what  you're doing: 1500 bytes for Ethernet, and 508
bytes for ARCNET.  The MTU for PPP is automatically negotiated, and  defaults
to  1500.   Other  subnet  types,  including  SLIP and AX.25, are not as well
standardized.

SLIP has no official MTU, but the most common implementation (for  BSD  UNIX)
uses  an MTU of 1006 bytes.  Although Nos has no hard wired limit on the size
of a received SLIP frame, this is not true for other systems.  Interoperabil-
ity problems may therefore result if larger MTUs are used in Nos.

Choosing an MTU for an AX.25 interface is more complex.  When  the  interface
operates  in  datagram  (UI-frame) mode, the paclen parameter does not apply.
The MTU effectively becomes the paclen of the link.

However, when using AX.25 CONNECTIONS to send IP packets, data will be
automatically segmented into I-frames no larger than paclen bytes.
Unfortunately, as also  mentioned earlier, Nos is so far the only known
implementation of the new AX.25 segmentation procedure. Thus, if you are
exchanging IP over connections (ie. VC mode) with none-NOS based systems,
it might be needed to avoid AX.25 segmentation. Thus you should make sure
that packets larger than paclen are never handed to AX.25.  In order to
assure this, you should not set the MTU greater then the paclen.

On the other hand, if you do not send IP over connections, but in datagram
mode, you can use a larger MTU. Here, you are limited by the receive buffer
size (and the tolerance of other network users for your large packets and
proportionally greater bandwidth share !).

For connections carrying IP between NOS systems (ie NOS-NOS VC mode), you can
let AX.25 segmentation do it's thing. If you choose an MTU on the order of
1000-1500 bytes, you can largely avoid IP-level fragmentation and reduce
TCP/IP-level header  overhead on  file transfers to a very low level. And you
are still free to pick whatever paclen value is appropriate for the link.


2.4.5.  Setting MSS


The setting of this TCP-level parameter is somewhat less critical than the IP
and  AX.25 level parameters already discussed, mainly because it is automati-
cally lowered according to the MTU of the local interface when  a  connection
is  created.  Although this is, strictly speaking, a protocol layering viola-
tion (TCP is not supposed to have any knowledge  of  the  workings  of  lower
layers)  this  technique  does  work  well  in  practice.  However, it can be
fooled; for example, if a routing change occurs after the connection has been
opened  and  the new local interface has a smaller MTU than the previous one,
IP fragmentation may occur in the local system.

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

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

2.4.6.  Setting Window

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

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

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


INTERFACE BUFFERS.
------------------

        There are two different types of interface buffers associated with
attaching interfaces.  The first type is the ring buffer or fifo that is
used when attaching a serial port.  This buffer is allocated just once, and
is used throughout the life of the interface.  The asynchrounous (or serial
port) receiver interrupt code puts characters in this buffer in a circular
fashion. Ie. when the end of the buffer is reached, the next character will
be stored at the beginning.
        The receiver process for that interface will read the characters
from this fifo-buffer into memory buffers or mbufs,  that are used internally
to handle and pass around data.  Setting the size of this buffer is a bit
quess work.  A good place to start is to set it to twice the size of the
packet length used over the serial port.  Once you have the interface running,
you can monitor the usage of the fifo buffer with the 'asy' command.
This will show you the 'buf hi' (for JNOS40 code) or 'sw hi' for PC based NOS.
This is the high of the maximum number of characters that were waiting in the
fifo buffer to be read by the receiver process. If this number is close to
the fifo buffer size, or if the 'asy' command shows buffer overflows ('buf over'
for JNOS40 code and 'sw over' for NOS.EXE), you should increase the buffer
size.  If however the number is significantly smaller, you could decrease
the buffer size.

        The second type of interface buffers are also receiver buffers.
However, these are buffers that are allocated time and time around, and
(almost always) are allocated during interrupts service routines, ie. with
the interrupts off!  In order to keep the service routine short, the buffer
is allocated from a special 'interrupt buffer queue'. This is because a
regular memory allocation would take far too long.
        In NOS.EXE , things like the SCC, PI and PACKET drivers use these
buffers.  In JNOS40, the two internal modem drivers use them.
Since one interrupt buffer pool services all the drivers that need buffers
during interrupt, the size and number of these buffers are quite critical
to a system's 'well-being'.  A buffer aquired from the interrupt buffer
pool needs to be able to store received data from all interfaces that use it.
In other words, it needs to be large enough to handle the largest packet
from those interfaces.
        A good rule to estimate the size of the interrupt buffers needed
is as follows.

        You should set 'memory ibufsize' to (the largest + extra) of:

1 - the largest ax.25 paclen parameter of the interfaces using ibufs.

2 - the largest ip mtu parameter of the interfaces using ibufs.

The mtu is important because on ax.25 interfaces where the mtu is larger
then the paclen, there is a possibility of receiving larger ip frames,
if IP traffic is carried in Datagram mode. This possibility does not
exist if IP traffic is carried in Virtual Connect mode, since the data will
be split in several paclen sized ax.25 packets (this is the AX.25 V2.1
fragmentation at work for you !)  In the last case, you can ignore
these mtu values in finding the ibuf size.  (However, for NOS.EXE you still
need to use the mtu for ethernet interfaces !)

The 'extra' in the above is another interesting number !
It accounts for the additional protocol info, and internal headers, needed
in the buffer. The maximum of this will be 72 bytes for a maximum ax.25
header (10 calls * 7 bytes, plus pid and control bytes), and space for
the internal phdr structure, currently 8 bytes. Ie. the 'extra' value
can be as large as 80 bytes !

Eg. if you have an ax.25 interface with paclen of 256, mtu of 256,
another with paclen of 256 and mtu of 512,
you should set the 'memory ibufsize' to at least 512 + 80 !

JNOS40 ibufs default to 600 bytes, and thus they should suffice for paclen's
or mtu's up to 512.  NOS.EXE has a default ibufsize of 2k (ie 2048 bytes),
wich suffices for the standard Ethernet MTU of 1500 bytes.

Determining the number of buffers needed is another empirical process.
Start with, say, ten buffers (ie 'memory nibufs 10'), and see if you
get a lot of memory ibuffails in the 'mem stat' display. If this is the
case you should increase the number of buffers.


NOTE: if you are not using any drivers that require interrupt buffers,
there is no need to keep them around. In that case, simple set the
'mem nibuf' to zero.



PER INTERFACE PARAMETERS
------------------------

        As of V1.05, there are quite a few new parameters that are
        on a per-interface basis. This means they can be set for interface
        xyz without effecting the settings for interface abc.

        As of 1.06, these commands now TOGGLE the flags !!! Ie. you can turn
        the options ON by issuing the command, off again by issuing the
        command again !

        These settings are shown in the 'ifconfig' display, in the 'flags'
        value shown here.
        In the code, they are defined as:

#define DATAGRAM_MODE   0   /* Send datagrams in raw link frames */
#define CONNECT_MODE    1       /* Send datagrams in connected mode */
#define IS_NR_IFACE     2   /* Activated for NET/ROM - WG7J */
#define NR_VERBOSE      4   /* NET/ROM broadcast is verbose - WG7J */
#define IS_CONV_IFACE   8   /* Activated for conference call access - WG7J */
#define AX25_BEACON     16  /* Broadcast AX.25 beacons */
#define MAIL_BEACON     32  /* Send MAIL beacons */
#define HIDE_PORT       64  /* Don't show port in mbox P command */
#define AX25_DIGI       128 /* Allow digipeating */

NEW in 1.06:
#define ARP_EAVESDROP   256 /* Listen to ARP replies */
#define ARP_KEEPALIVE   512 /* Keep arp entries alive after timeout */
#define LOG_AXHEARD    1024 /* Do ax.25 heard logging on this interface */
#define LOG_IPHEARD    2048 /* Do IP heard logging on this interface */

        In order to find the options, add the correct set of options to get
        the number shown in the 'flags' field...

        These options can be set with the following commands:

        mode <iface> datagram|vc

        netrom interface <iface> <qual> [n]

        convers interface <iface>

        ax25 bcport <iface>

        mbox mport <iface>

        mbox hideport <iface>

        ax25 digipeat <iface>


        As of 1.06, there are a few new one:

        arp eaves <ifave>  - toggle arp eaves dropping; this will build the
                arp table will all arps heard on the interface given.

        arp poll <iface>   - toggle arp keep-alive polling when an arp entry
                expires.

        AX25 heard is now settable per interface !!!
        ax hport <iface>

        You can set the maximum size of the ax heard table with
        ax hsize n
        It defaults to 0, wich means no limit.



        ip hport <iface>   - do ip-heard logging on the interface named.
                             this shows with 'ip heard', or the mailbox IH
                             command.

        The size of the ip-heard list can be set with
        ip hsize n . 0 means no limit. Default is 16





CONFIGURING NOS.EXE AS A FULLSERVICE BBS.
-----------------------------------------

        Given in the appendices are all the configuration files
as I use them for the Corvallis area bbs wg7j.or.usa.na. I simply
provide them as an example of a possible configuration. I leave it
up to the individual user 'to find there own little comfort zone'
These files are undergoing continuous evolution as new bbs's, new
bulletin types etc. show up...
In our area we do not use rspf, nntp, pop or any of the 'exotic'
stuff like that, so all that is not configured.

/AUTOEXEC.NOS
------------
        My autoexec.nos is pretty straight forward,
and I leave it up to you figure most of it out. I'll elaborate on
a few things.

I use a SCC card, and the SCC driver. We have a 256 byte mtu/paclen,
so buffers of 400 bytes is enough (see elsewhere for more)
        me ibufsize 400
        me nibufs 20

I run with Watchdog on, just in case the system locks up. Sometime i like
to watch memory status for debugging purposes...
        watchdog yes
        mem debug on

Next, i setup some some global things: call, tcp hostname and ip address
        ax25 mycall wg7j
        hostname wg7j
        ip address 44.26.1.20

The ax.25 setup is pretty straigt forward.
        ax25 version 2
        ax25 maxframe 1
        ax25 retry 5
        ax25 window 1024
        ax25 irtt 4500
        ax25 timer linear
        ax25 t3 0
Give the a 10 minute timeout
        ax25 t4 600
AX.25 beaconing; read FCC part 97,
and do as you think is according to the rules...
        ax25 bci 600
        ax25 bct "CRVBBS in Corvallis, run by Johan, WG7J. (TCP/IP -> 44.26.0.80)"

I have 2 interfaces, one scc card with one radio port (2m)
and a remote pc that talks over a serial port (sysop).
        #com3 = kiss to home.wg7j
        attach asy 0x3f8 4 ax25 sysop 1536 1024 9600
        ifconfig sysop linkaddress bbs
        ifconfig sysop descr "to remote sysop PC"

        #attach an SCC card at IRQ 4
        #init it first
        attach scc 2 init 150 4 2 0 1 168 7 p4915200
        attach scc 0 ax25 2m 256 d1200 350

I configure the 2m interface for a few small things, like our tcpip subnet
        ifc 2m netm 0xffffff00
        ifc 2m broad 44.26.1.0
        ifc 2m descr "SCC port 1 on 144.92 MHz"

Now i have to activate beacons and mail beacons, and digipeat
        ax25 bcport 2m
        mbox mport 2m
        ax25 digipeat 2m

If you had a tnc in kiss mode, you could set the txtail, etc... parameters
        #KISS setup to TNC
        #tx-delay (300 ms)
        #param 2m 1 30
        #persistence
        #param 2m 2 63
        #slot-time (10ms)
        #param 2m 3 16
        #tx-tail (50 ms)
        #param 2m 4 5
        #half duplex channel !
        #param 2m 5 0

I forward to some bbs's via an AXIP Internet Wormhole.
I have some exotic digipeater routes to them:
        #some routes for wormhole fowarding
        ax25 route add k9iu-13 2m wg7j-13
        ax25 route add ke7kd 2m wg7j-14 n8khn-2

Time to attach the NET/ROM stuff
        #NET/ROM SETUP
        #attach pseudo netrom interface
        attach netrom
        netrom alias crvbbs
Activate the interfaces for netrom, both are in 'verbose' mode
        netrom interface 2m 192
        netrom interface sysop 224

Setup some timing and retry maximums
        netrom retries 5
        netrom timer linear

Load the routes files saved at last exit
        netrom load

Don't show users '#' nodes !
        netrom hidden no

Time for a few IP and TCP related things, see the discussion elsewhere
for more information
        ip ttl 25
        tcp mss 432
        tcp window 864
        tcp timer linear

Now the IP routes. The local subnet is on the 2m port.
        route add 44.26.1/24 2m

My remote sysop PC sits on the serial connection
        route add 44.26.1.19 sysop

Default everything to the Internet gateway
        #add the ip routes
        route add default 2m 44.26.1.16


IP over netrom is fun to play with. Currently all Portland area
goes to Hank's system in Portland.
add a route to a gateway for all 44.116 traffic
        #add w0lri as gateway over netrom
        route add 44.116/16 netrom 44.116.0.70
Next adds the appropriate arp entry for that gateway.
        arp add 44.116.0.70 netrom w0rli-3

A few things about domain
        domain suffix ampr.org.
        domain translate off

SMTP needs to be quite, and I use the internet gateway as my default route,
if my rewrite/alias files don't catch the message
        smtp quiet yes
        smtp mode route
        smtp batch on
        smtp gateway 44.26.1.16

Start the log
        log \spool\net.log


Now start all servers
        ##ready to start all servers now start smtp
        ##turn on the bbs for ax25, netrom and telnet connects
        start ax25
        start netrom
        start telnet
        start ftp
        start smtp
        remote -s your-password-here
        start remote
        start finger
        attend off


Setup the mailbox stuff
        #we're not home !
        mbox attend off
        #forward every hour
        mb timer 3600
        #start forwarding at 10 minutes past the hour
        at 10 "start forward"

        #'mail for' beacon every half hour
        mb mailfor 1800

        #don't beacon for these private mailboxes.
        mb mailfor exclude indy nevada w0rli n7dxt wa7shp sysop check north south nts

        #notify users when new area mail is in
        mb new on

        #also ask for the 'okay to send'
        mb sendquery on

        #max 150 messages per group
        mb max 150
        #the message-of-the-day
        mb motd "'?' or 'h command` for help; 'd commands.txt' for command cheat sheet...\nSend local messages to 'users' .Questions to sysop or wg7j...\nEnjoy."
        #no jumpstart for these guys
        mb jumpstart exclude k7uyx-1 wg7j-3 wg7j-1
        mb jumpstart on
        mb haddress or.usa.na
        mb qth "Corvallis, OR"
        mb zip 97330
        #don't forward smtp headers over the bbs circuit
        mb smtp no
        #optimize forwarding by checking the R: lines
        bulletin check yes
        #use the bulletins origination date
        bulletin date yes
        #grab return address from R: lines
        bulletin return yes
        #hold forward loop messages after 2 loops
        bulletin loophold 2

        #set some timeout values
        ftptdisc 600
        mbox tdisc 600
        netrom tdisc 600

        #start some cycles at a certain time
        # expire messages each night at 1pm (i'm using utc time)
        at 0900 "expire 24"
        #delete old bid's every night at 2pm, limit is 21 days
        at 1000 "oldbid 24 21"


Finally tell the network we;re there, and poll other jnos1.05 or jnos40
nodes for their netrom routes
        ##finally tell the netrom network we're there !!
        netrom bcnodes 2m
        netrom bcpoll 2m



/FTPUSERS
--------
        Appendix B, ftpusers, contains entries for the bbs's that
forward to me, as well as those users that have sysop priviledges.
All other regular users are taken care off with the univperm entry;
thus no long list of users is needed. Offcourse you can setup entries
for specific users that have special needs...
(one note: it is imperative that you have one space, and nothing else,
between fields on a line!!!)
The numbers in the file are those found in the MAILBOX USER PERMISSION
section.



/ALIAS
-----
        Appendix C, alias, is a simple list of alias names the system
recognized. I like to be known as 'johan' as well as 'wg7j' but always
read mail as wg7j (line 1). Ron, wa7tas, receives his mail via smtp
on his 24hrs setup (line 2). Same for k7mkg.



/SPOOL/AREAS
------------
        Appendix D, /spool/areas, simply list all the public
mail areas I let my users access. You should recognize such things
as 'allusa', 'amsat' etc...



/SPOOL/REWRITE
--------------
        Appendix E, /spool/rewrite, is where the fun starts !
Before i get into my 'philosophy'; if you don't feel comfortable
with the rewrite mechanism, please refer to or read the 'mailbox.txt'
destributed with this document. That document, written by NQ0I and
SM0RGV, explains the bbs well. Credit goes to those gentlemen.

        Again, the following is by no means the best or only way to configure
your system's rewrite mechanism. It is simply the way I run it, and is shown
as an example only. My systems tends to not take a lot of bulletins, to
keep the load down (most are old anyway), but you might decide to do things
different.

        Now to the way I 'run mail'. First thing I want to do is catch
all Internet style (ie. SMTP targeted) mail, and make sure that those
messages go as is. Lines 1-4 take care of this by catching most of the
top-level Internet domain names.
        *@*.edu $1@$2.edu
        *@*.com $1@$2.com
        *@*.gov $1@$2.gov
        *@*.org $1@$2.org

        Next is an example of catching some things you don't want; here
in Oregon some-one pumps in daily astronomical stuff. By the time it gets
to my system it's way old :-( By rewriting it to 'refuse', the bbs will
send a 'NO' as if it already has receive it. Same for some other things
the wormhole bbs's are trying to forward to me.
        astro@* refuse
        *@dist9 refuse
        *@allin refuse
        *@okipn refuse
        *@allil* refuse
        msys@* refuse
        fbb@* refuse
        mods@* refuse
        *@ww refuse


        I want users to be able to send mail to sysop on my system without
it being forwarded elsewhere. I take care of this by rewriting
it to the 'wg7j' area (ie. my private mail area)
        sysop wg7j
        sysop@wg7j* wg7j

Next I send everything else that comes in for sysops to the 'sysop'
area. That way I can participate in receiving and forwarding stuff like
'sb sysop@allor' etc...
        sysop@* sysop

Next I place anything addresses to specific mail areas as setup
with the '/spool/areas' files into those mailboxes
        tcpip@* tcpip
        wanted@* wanted
        want@* wanted
        need@* wanted
        sale@* sale
        4sale@* sale
        trade@* sale
        dx@* dx
        humor@* humor
        jokes@* humor
        happy@* humor
        races@* races
        fcc@* fcc
        amsat@* amsat
        arrl@* arrl
        ares@* ares
        swap@* sale
        nasa@* nasa

Then the same thing for the @-distribution names:
        *@nasa nasa
        *@amsat amsat
        *@ares* ares
        *@arrl arrl
        *@arl arrl
        *@pnw pnw
        *@allor* allor
        *@allusw allusw
        *@allus* allusa

NOTE: if you follow this style, it is important that the lines above
are kept in that order (Ie TO sorting FIRST, then AT sorting !!)
Otherwize something like 'amsat@allusa' will end up in the 'allusa' area
instead of the 'amsat' area where I prefer it.


Next I will catch anything destined for my bbs that hasn't been
already caught by a previous rule. At this point, this <should>
only be private mail.
        *@wg7j* $1


Then I will catch any mail destined for the bbs's i forward to
and place it in their mailbox to be forwarded.
        *@wa7tas* wa7tas
        *@wa7shp* wa7shp
        *@w0rli* w0rli
        *@n7dxt* n7dxt

I place anything destined for a few in-state (ie OR) bbs's that are
north of me into the 'north' mailbox. They get forwarded north-ward
(see forward.bbs)
        *@n7hae* north
        *@n7vyn* north
        *@n7koj* north
        *@n7pwf* north
        *@wa6gfp* north
        *@n7jqk* north
        *@ka7agh* north
        *@kb7dbd* north


Then I take all local NTS traffic and places it in it's own area.
        *@97321* ntslocal
        *@9733* ntslocal
        *@97370* ntslocal
        *@97389* ntslocal

Other in-state NTS goes into the right direction.
        *@98* north
        *@970* north
        *@971* north
        *@972* north
        *@9730* wa7shp

All out-of-state NTS traffic gets placed into the 'nts' area
for forwarding
        *@ntswa* north
        *@nts* nts


    They idea is, that by rewriting every in-state bbs north of me into
the north area, everything in-state left has to go south !
(Luckily, N7DXT, who gets my south traffic, is forgiving and
will send my mistakes north anyway !)
        *@*.or* south

A few other states that go south:
        *@*.ca* south
        *@*.az* south
        *@*.tx* south

These states go to K9IU in Indiana via the wormhole:
        *@*.in* indy
        *@*.oh* indy
        *@*.mi* indy
        *@*.ky* indy
        *@*.tn* indy

And lonesome KE7KD in Reno get the Nevada traffic:
        *@*.nv* nevada

Send all remaining North American mail north (to w0rli, who
has an HF port...)
        *@*.eu north


Catch 2 more continents:
        *@*.oc south
        *@*.as north


And finally, I will catch anything that is left at this point.
It puts it in the 'check' area. The idea here is that I can
manually check the 'check' area and adjust '/spool/rewrite' accordingly !
(and append that mail to the right mailbox file so it goes out!)
'check' is actually an alias, that sends copy of the message to both the
'check' area and my private mailbox, so that i will know right away when some
thing unknown has shown up...
        *@* check


/SPOOL/FORWARD.BBS
------------------
        As of v1.05, forwarding can now hand 'connect scripts' in the
forward.bbs file. The format of forward.bbs file is expanded:

  w0rli                 <- still the bbs to forward to
  ax25 ax0 w0rli        <- still how to forward to
  [ multiples of:
  .send this text
  +continue if this string is received
  @wait_this_long for a reply  ]
  w0rli                 <- the areas to forward...
  pnw
  north
  -----------           <- end of this entry

  Valid connect-script lines are:

  '.' lines are like before. The text following will be sent over the
        connection.  This line doesn't need to contain text. In that case,
        a <cr> only gets send.
        NOTE: This will also reset the '+'  reply search string to null!

  '+' lines set a reply string to search for when a line is being received
        with the @ command.

  '@' lines set a timeout in seconds in wich to receive a line over the
        connection. This is the maximum time the system will
        wait for a reply. At this point, an attempt is made to receive a line
        from the connection in the time specified.
        If nothing is received after the timeout time, forwarding for this
        entry is cancelled.
        If something is received, and a search string set with the + command,
        forwarding will be continued only if the search string appears
        somewhere in the line received.
        If the search string was not set, forwarding is continued.

        NOTE: if the value after @ can not be converted to a number, the
        default is 90 seconds.
        NOTE: the search string is reset if forwarding continues after the
        @ command.


   You can have as many of these lines to establish a connection. They need
   not be in any particular order.

   CAVEAT:
   Replies from the connection need to be full lines; ie they have to be
   terminated by a proper end-of-line sequence. This means you can not wait
   for the login prompt from a NOS system, since those are NOT terminated
   with a end-of-line sequence. (see the examples)
   You need to know the EXACT reply from systems you connect through.
   Each @ command reads only one line of data from the connection (if
   any, offcourse). This means that if a system replies multiple lines
   after a connection is made, you need multiple @ commands. (see the
   examples below). This makes it hard to connect via systems that can
   have varying replies, like NOS systems that do not have your system
   marked as a BBS, and thus will send welcome messages and varying
   message-of-the-day etc...


Some examples:

1- a connection via a netrom neigbour:
        w0rli
        ax25 ax0 k7uyx-1        <- initial connection to netrom node
        .c rlimb                <- ask for a netrom connect from this node
        +Connected              <- if we don't get this, things went wrong
        @60                     <- maximum one minute wait !
        w0rli                   <- forward these areas...
        pnw
        allor
        ---------

2- a connection via a JNOS system .
   This assumes that you are marked as a BBS at the JNOS system, so that
   you only get a '[JNOS...] and '>' prompt...

        n7dxt
        ax25 iposu              <- initial connection to the JNOS system
        +[JNOS                  <- wait for sign-on message from the JNOS box
        @15                     <- don't wait longer then 15 seconds
        +>                      <- wait for the prompt
        @15                     <- wait 15 seconds at the most
        .c ax0 n7dxt            <- next, request a gateway connect
        +Trying                 <- NOS replies it's trying...
        @15                     <- wait 15 secs max.
        +Connected              <- wait for 'IPOSU:WG7J-3} Connected to N7DXT'
        @60                     <- wait 60 secs max
        n7dxt                   <- send these following areas
        pnw
        allor
        ----------

3- A connection to a JNOS system, and from there a telnet to a remote bbs
   (again, assumes your system is marked as a bbs !)

        wg7j
        ax25 con iposu          <- initial connection to JNOS
        +[JNOS                  <- sign-on from JNOS
        @15                     <- shouldn't take too long
        +>                      <- next is the prompt
        @15                     <- not too long either
        .t wg7j.ampr.org.       <- ask for a telnet connect
        +Trying                 <- JNOS is trying
        @15                     <- should come pretty soon
        +connected              <- wait for '*** connected to xxx'
        @45                     <- might take a while
        @30                     <- wait for another (blank) line
        +NOS                    <- now come the telnet sign-on message
        @30                     <- wait for this
        @30                     <- after this is a blank line, wait for it
        .w0rli                  <- now we get 'login:' and "Password:" prompts,
        .whomever               <- but they have <cr>'s, so just send them
        sysop                   <- we're there, forward these areas.
        allor
        wg7j
        pnw
        nos
        ------



        Appendix F, /spool/forward.bbs, details the forwarding my system
will attempt. I don't care when forwarding occurs, so none of the first
line entries have time fields (lines 1,10 and 19). Lines 2,11 and 20
show how I attempt to connect to the remote bbs. All go over netrom
(my only way out :-( ), but for WA7SHP I need to downlink from a distant
node (salem) to his bbs (lines 21,22 and 23)
The areas I forward are mostly regional bulletins, nts traffic,
and personal mail (as shown earlier, the north and south entries)
I don't forward any of amsat,allusa,allusw because I don't want to
clutter an already loaded system; the surrounding area bbs's get these
things to each other just fine without my 'interference :-)'


/ONEXIT.NOS
-----------
        Appendix G, /onexit.nos, simply is a set of valid NOS.EXE
commands to be executed before returning to DOS. In line 1,
I tell the netrom system one last time I am there (to try to keep
my route alive while I am gone). Next I save the netrom routes
to disk for later retrieval at startup via the netrom load command.




GATEWAYING BETWEEN SMTP AND AX.25 BBS STYLE MAIL
------------------------------------------------
        If your system is serving both the 'regular' packet
community (ie. people with just tnc's) as well as the tcp/ip-ers
with mail forwarding, here are a few hints on how one could set things
up.
        The following assumes that the host 'ka7ehk.ampr.org'
sends mail to '[e-mail]', and uses 'wg7j.ampr.org' as the
mail gateway that talks to the bbs-network. wg7j's bbs style H-Address
is WG7J.OR.USA.NA . The rewrite file in appendix E is also used as an
example of how the gateway system handles mail.

        NOS.EXE is fully capable of exchanging mail from SMTP world to
BBS world and vice versa. Thus it can act as the gateway between the two
different systems. The key to understanding how this works is to realize
that the smtp-server ALSO READS REWRITE when mail comes in that way !
(as a matter of fact, even mailbox mail goes through the smtp-server !)
You should also (again) check the diagram in mailbox.txt...

MAIL FROM SMTP  -->  AX.25.
--------------------------

When sending mail via smtp that eventually should end up in the bbs
network, the meaning of the previous is as follows:
        When ka7ehk.ampr.org connects to wg7j.ampr.org and sends the
address of the mail, the smtp-server will deposit this in the 'w0rli.txt'
mailbox (rewrite line 24). Next time the forward timer ticks, forwarding
will be attempted, and you're in business !

How does one set this up on the user side ?
        The easiest way to set this up for the user is to tell the user
to use your system as the mail gateway ! The 'smtp gateway' commands
sets a hostname that ALL UNKNOWN MAIL will be sent to. Unknown mail is
mail to addresses that cannot be found in /domain.txt (or from the domain
name server if configured). Since most bbs style addresses will not be in
there, this means that those mails will go to the gateway !
(remember: tcpip hostnames most often end in ampr.org, whereas bbs style
H-Address are something like WG7J.OR.USA.NA. The latter thus will not be found
in /domain.txt!)
Thus a simple
        'smtp gateway yourhost'
where yourhost is the gateway's name (as in domain.txt) or ip-address,
suffices !

There is another way a user can send the above mail. However this a bit more
involved and is not as easy for users. It involves a little more of an
understanding of the ways smtp addressing works. It also requires an
additional line in rewrite ! It simply given for completeness.
        User's can manually address mail to a gateway, with the to-address
format 'user%hostname@gateway'.
Eg. the above mail could be addressed as '[e-mail]'

In order to handle these sorts of mail address,es you should add a line similar
to '*%*@wg7j* $1@$2 r'  to your rewrite file. Just replace wg7j with the
your system's name. This line will rewrite all %-addresses into a regular
address (ie. the above becomes '[e-mail]'), and then rescan
with the new address to find more rewrite rules. Thus the mail ends up in
the 'w0rli.txt' mailbox again.

Then ka7ehk.ampr.org would again deliver the mail to wg7j.ampr.org,
and the process would be identical to described above.


MAIL FROM AX.25  -->  SMTP
--------------------------

        Let's use as an example a reply from w0rli to ka7ehk.
Since bbs's use the last R: header as the return system, a reply mail
will be sent to my system as 'S [e-mail] < W0RLI' ,
or as 'S KA7EHK < W0RLI' depending on the pbbs software.
In order to deal with the first case, rewrite line 22 is needed.
This rewrites the address into simply 'ka7ehk'

Next, you as sysop have 3 options for delivery of the message:

1 - ka7ehk has to login to your system in order to read his mail.
    Simply do nothing !

2 - you want to forward mail to ka7ehk on his home system using smtp
    You need to add an alias to handle this. The line
    'ka7ehk [e-mail]' will do the job.

    This might cause lots of attempts for smtp if ka7ehk's system isn't
    on the air a lots (ie. like most users!)
    Better then is:

3 - Let ka7ehk automatically get his mail with POP each time he turns
    his system on. The gateway sysop and the user both need to configure
    this appropriately. See nos_1229.man for more details.


POP SERVICES IN NOS
-------------------
        The following is also contributed by Doug Cromptom, WA3DSP:

                      How to use POP in NOS
                      ---------------------

The HOST should establish a 'POPUSERS.'  file in root with the following
format:

username:password:
username:password:
etc.

There should be an entry for each user of your POP system. We generally
use call letters for both entries.  I.E.   wa3dsp:wa3dsp:


The following applies to the old NOS POP2 server/client prior to WG7J
1.02
                             -------------

The HOST must also start the pop server  'start pop' which should go in
your NOS autoexec.


Each USER must add the following lines to there autoexec:

'pop mailbox CALL'

                      Where CALL is the name of the mailbox on the host
                      to retrieve mail from. The /spool/mail/CALL.txt file.
                      Usually the users call.

'pop mailhost hostname'

                      This specifies what host to pop from.
                      I.E. 'pop mailhost wa3dsp.ampr.org'

'pop userdata user password'

                      This data should match the data in the
                      hosts /popuser file.
                      I.E. 'pop userdata wa3dsp wa3dsp'

'pop timer 3600'

                      For stations that are on for extended periods
                      and receive there mail via pop from a mailhost
                      this timer must be set to interrogate the host
                      on a regular basis. Alternatively they could
                      do a 'pop kick' to check for mail. Time should
                      be set to probably no less than 1/2 hour on a
                      radio circuit.

'pop kick'

                      This should be entered at the end of your
                      autoexec to check for mail from your mailhost
                      at startup.

So the autoexec entries would look like this for USER w3iwi...

pop mailbox w3iwi
pop mailhost wa3dsp.ampr.org
pop userdata w3iwi w3iwi
pop timer 3600
pop kick

and HOST wa3dsp's autoexec...

start pop

HOST wa3dsp's popusers. in root....

w3iwi:w3iwi:


           For NOS POP2/3 server client WG7J 1.02 and later.
                            ------------

The method of entering client pop server information has been changed!!
All information is added on one line with the 'pop addserver' command.

It has the following syntax:

pop add <mailserver> <seconds|time> <protocol> <mailbox> <username> <password>

Using the above old version example it would be entered like this:

pop add wa3dsp.ampr.org 3600 pop2 w3iwi w3iwi w3iwi

This is assuming POP2 protocol. It is advisable to use POP3 and if your
server supported it the POP2 would be replaced with POP3. NOS can be
compiled to include any combination of POP2/3 server client. If one
protocol was not supported in your compile it would not be allowed in
the command. Refer to the old version above for a definition of the
fields.

Since multiple servers can be defined using the 'pop add' command the
'pop kick' command now takes the form 'pop kick <server>' or in the
above example:

pop kick wa3dsp

The 'pop add' and 'pop kick commands are the only ones needed in the
autoexec file to initialize pop. 'pop list' will show the current
defined servers.

The server must start pop. Since both pop2 and pop3 servers can now be
present the appropriate command are:

start pop2
start pop3

                        --------------------

A few other points...

If a pop users wants mail to be delivered to the host for them to pick
up via POP they should enter a 'reply to' field in BM.RC to direct
mail to the host and not back to them.

POP is a very good service for Amateur Radio. It is especially good
when a flood of messages are sent out to all users. This is a condition
that often causes crashes on memory marginal systems using SMTP. Also
alot of unnecessary traffic is sent out to stations that are not on the
air. With POP the user asks for and gets mail. This is naturally a random
operation. Lowering channel congestion and NOS memory usage.

Mail that is POP'ed from the host is deleted from the /spool/mail
directory upon successful transfer. The USER is notified that new
mail has arrived at the completion of the entire transfer.

One drawback that I notice with POP is that the messages (many could
build up) for a user are sent as a group. If the circuit fails with
a hard error halfway thru a POP xfer of a message group, no messages
are saved at the user end, even though some got thru. It is an all
or none with POP. This reminds me of the stupidity of BBS's in this
regard. Hopefully users will not let messages build up. I have some
users who let the mail build up to 30 or 40K over a few weeks.




EPILOGUE.
--------

    I hope all this proves helpful for those interested in setting up
JNOS in a mixed environment...

        73 and happy packeteering,

        Johan



/*************************************************************************/

APPENDIX A: /autoexec.nos

me ibufsize 400
me nibufs 20
watchdog yes
mem debug on

ax25 mycall wg7j
hostname wg7j
ip address 44.26.1.20

#AX.25 SETUP
#use (UI) frames for ip over ax.25 !!!!!
ax25 version 2
ax25 maxframe 1
ax25 retry 5
ax25 window 1024
ax25 irtt 4500
ax25 timer linear
ax25 t3 0
ax25 t4 600
ax25 bci 600
ax25 bct "CRVBBS in Corvallis, run by Johan, WG7J. (TCP/IP -> 44.26.0.80)"

#com3 = kiss to home.wg7j
attach asy 0x3f8 4 ax25 sysop 1536 1024 9600
ifconfig sysop linkaddress bbs
ifconfig sysop descr "to remote sysop PC"

#attach an SCC card at IRQ 4
#init it first
attach scc 2 init 150 4 2 0 1 168 7 p4915200
attach scc 0 ax25 2m 256 d1200 350

ifc 2m netm 0xffffff00
ifc 2m broad 44.26.1.0
ifc 2m descr "SCC port 1 on 144.92 MHz"

#active beacons and mail beacons
ax25 bcport 2m
mbox mport 2m
ax25 digipeat 2m

#KISS setup to TNC
#tx-delay (300 ms)
#param 2m 1 30
#persistence
#param 2m 2 63
#slot-time (10ms)
#param 2m 3 16
#tx-tail (50 ms)
#param 2m 4 5
#half duplex channel !
#param 2m 5 0

#some routes for wormhole fowarding
ax25 route add k9iu-13 2m wg7j-13
ax25 route add ke7kd 2m wg7j-14 n8khn-2

#NET/ROM SETUP
#attach pseudo netrom interface
attach netrom
netrom alias crvbbs
netrom interface 2m 192
netrom interface sysop 224
netrom retries 5
netrom timer linear
netrom load
netrom hidden no

ip ttl 25
tcp mss 432
tcp window 864
tcp timer linear

#add the ip routes
route add default 2m 44.26.1.16
#remote sysop pc
route add 44.26.1.19 sysop
#add w0lri over netrom
route add 44.116/16 netrom w0rli.ampr.org
arp add 44.116.0.70 netrom w0rli-3

domain suffix ampr.org.
domain translate off

smtp quiet yes
smtp mode route
smtp batch on
smtp gateway 44.26.1.16

log \spool\net.log

##ready to start all servers now start smtp
##turn on the bbs for ax25, netrom and telnet connects
start ax25
start netrom
start telnet
start ftp
start smtp
remote -s wg7jjj
start remote
start finger
attend off

mbox attend off
#forward every hour
mb timer 3600
at 10 "start forward"
#'mail for' beacon every half hour
mb mailfor exclude indy nevada w0rli n7dxt wa7shp sysop check north south nts
mb mailfor 1800
mb new on
mb sendquery on

#max 150 messages per group
mb max 150
mb motd "'?' or 'h command` for help; 'd commands.txt' for command cheat sheet...\nSend local messages to 'users' .Questions to sysop or wg7j...\nEnjoy."
mb jumpstart exclude kf7dq-1 wg7j-3 wg7j-1
mb jumpstart on
mb haddress or.usa.na
mb qth "Corvallis, OR"
mb zip 97330
mb smtp no
bulletin check yes
bulletin date yes
bulletin return yes
bulletin loophold 2

#set some timeout values
ftptdisc 600
mbox tdisc 600
netrom tdisc 600

#start some cycles at a certain time
# expire messages each night at 1pm (i'm using utc time)
at 0900 "expire 24"
#delete old bid's every night at 2pm, limit is 21 days
at 1000 "oldbid 24 21"

##finally tell the netrom network we're there !!
netrom bcnodes 2m
netrom bcnodes 2m

#trace 2m 111

#arp for my home.wg7j system
arp publish 44.26.1.19 ax25 wg7j 2m


APPENDIX B: /ftpusers

1:  wg7j password / 16511
2:  johan password / 16511
3:  ka7ehk password / 16511
4:  n7dxt password /public 8195
5:  w0rli password /public 8195
6:  wa7shp password /public 8195
7:  w7vtw password /public 8195
8:  univperm * /public 16403
9:  #sysops: 16511
10: #regular users: 16403
11: #bbs's: 8195


APPENDIX C: /alias

1:  johan wg7j
2:  wa7tas [e-mail]
3:  k7mkg [e-mail]


APPENDIX D: /spool/areas

1:  allor     -        All of Oregon stuff
2:  allusa    -        ALLUSA bulletins
3:  amsat     -        AMSAT bulletins
4:  anonymous -        info for new/anonymous users
5:  arrl      -        ARRL bulletins
6:  help      -        help about this system
7:  ntslocal  -        Corvallis area NTS traffic
8:  osuarc    -        Oregon State University ARC stuff
9:  pnw       -        Pacific North West stuff
10: sale      -        'for sale' bulletins
11: tcpip     -        TCP/IP related stuff


APPENDIX E: /spool/rewrite

*@*.edu $1@$2.edu
*@*.com $1@$2.com
*@*.gov $1@$2.gov
*@*.org $1@$2.org
*%*@wg7j* $1@$2 r
astro@* refuse
*@dist9 refuse
*@allin refuse
*@okipn refuse
*@allil* refuse
msys@* refuse
fbb@* refuse
mods@* refuse
*@ww refuse
n8hkn@* nevada
ke7kd@* nevada
sysop wg7j
sysop@wg7j* wg7j
sysop@* sysop
tcpip@* tcpip
wanted@* wanted
want@* wanted
need@* wanted
sale@* sale
4sale@* sale
trade@* sale
dx@* dx
humor@* humor
jokes@* humor
happy@* humor
races@* races
fcc@* fcc
amsat@* amsat
arrl@* arrl
ares@* ares
swap@* sale
nasa@* nasa
*@nasa nasa
*@amsat amsat
*@ares* ares
*@arrl arrl
*@arl arrl
*@pnw pnw
*@allor* allor
*@allusw allusw
*@allus* allusa
*@wg7j* $1
*@wa7tas* wa7tas
*@wa7shp* wa7shp
*@w0rli* w0rli
*@n7dxt* n7dxt
*@n7hae* north
*@n7vyn* north
*@n7koj* north
*@n7pwf* north
*@wa6gfp* north
*@n7jqk* north
*@ka7agh* north
*@kb7dbd* north
*@wa7ari* wa7shp
*@k7myu* wa7shp
*@97321* ntslocal
*@9733* ntslocal
*@97370* ntslocal
*@97389* ntslocal
*@98* north
*@970* north
*@971* north
*@972* north
*@9730* wa7shp
*@ntswa* north
*@nts* nts
*@*.or* south
*@*.ca* south
*@*.az* south
*@*.tx* south
*@*.nv* nevada
*@*.in* indy
*@*.oh* indy
*@*.mi* indy
*@*.ky* indy
*@*.tn* indy
*@*.eu north
*@*.oc south
*@*.as north
*@* check
*@*.usa north
*@*.noam north
*@*.na north


APPENDIX F: /spool/forward.bbs

w0rli
netrom w0rli-2
w0rli
north
south
allor
pnw
tcpip
arrl
amsat
sysop
allusa
--------
n7dxt
netrom n7dxt
n7dxt
south
nts
allor
pnw
tcpip
arrl
amsat
sysop
allusa
--------
wa7shp
netrom af7s-1
.c 1 wa7shp
wa7shp
north
south
allor
pnw
arrl
amsat
sysop
--------
k9iu 0517
ax25 2m k9iu-13
indy
--------
ke7kd 0517
ax25 2m ke7kd
nevada
allor
allusw
pnw
----------
wg7j
ax25 sysop wg7j-2
test
----------

APPENDIX G: /onexit.nos

net bcn 2m
netrom save