NOS302 Release 3.0f for the PackeTen 
                    April 18, 1993

    The latest version of this software is always available for 
    download from the Gracilis BBS. (708)-844-0183

    ********************************************************************
    This ZIP archive contains Binary image files for NOS302 for the 
                Gracilis PackeTen Network Switch.  

    If you purchased your PackeTen system prior to November of 1990 you 
    probably have a Release 1 CPU, and should use the cpu_rel1.l and 
    cpu_rel1.u files. Otherwise, use the cpu_rel2.l and cpu_rel2.u image 
    files.  Functionally, the software is identical for both systems, 
    with the exception of the size of available EEProm memory storage. 
    A release 1 CPU provides 2k of EEProm, while a release 2 has 8k.
    ********************************************************************

    ********************************************************************
    NOTE:   Releases subsequent to 3.0d1 change the layout of the EEPROM... 
            Therefore, It will be necessary to RE-enter all EEPROM 
            parameters after installation of any release numbered 
            3.0d1 or higher, when upgrading from 3.0d or earlier releases.
    ********************************************************************

Checksums    
            cpu_rel1.l : 0x978B    U2 on a PackeTen Release 1 CPU
            cpu_rel1.u : 0x10FA    U3 on a PackeTen Release 1 CPU

            cpu_rel2.l : 0x4038    U2 on a PackeTen Release 2 CPU
            cpu_rel2.u : 0xAEA5    U3 on a PackeTen Release 2 CPU


New Features/Enhancements:

    ************
    NEW to 3.0f
    ************

    1. STILL More fixes for lingering defunct connections...
	   and other random buglets.

	2. Preserve Password Security Option across reboots of the switch

	3. Fix for random # generator that wasn't. 8-)
       This hopefully fixes long hang times between 
       xmits due to extensive persist failures, etc.

    4. Fix for hanging netrom connections when a user 
       attempted a cross connection, then just gave up
       and disconnected from the switch, but the P10 
       kept trying to complete the NETROM connect. 

	5. Added the ability to configure the Sync302 ports
	   as ARPA style interfaces. (I.E. Ethernet )
	   Just use "ethernet" instead of "ax25" as the mode,
	   during attach commands for the "302" ports.

    ************
    NEW to 3.0e1
    ************

    1. More fixes for lingering defunct connections... 

    2. Fix to allow longer port names to be truncated
       and still work from the ax25 gateway / mbox 

    3. Set the default TxTail for Sync interfaces to some
       resonable value.

    4. Fix for the Domain Client code: 
       If defined, the domain suffix is appended to
       any domain requests which are not already
       fully qualified.

    5. Display current "param"s for synchronous ifaces

    6. Fix NetRom Alias name recognition problem... 
       The code was allowing connections to ID's that were
       shorter than the ALIAS id, but matching subsets. 
       This is now handled properly.

    7. Automatically clear and remove AX.25 control blocks 
       whenever they are disconnected. (Saves memory, and
       fragmentation etc.)
 


    ************
    NEW to 3.0e
    ************

    ********************************************
    New Features / Bug Fixes to PackeTen NOS302
    ********************************************

    1.  Remote sysop users may return to the Net/Rom simulator, from
        the command parser by using the "exit" command.

    2.  The (I)nfo feature of the remote user / Net/Rom Simulator interface
        has been enhanced to allow the user to exit the info dump by
        replying (N)o to a More? (Y/n) prompt.

    3.  The format of the remote configuration request command, (to be
        executed on the PackeTen) has been enahnced as follows:

            rmtcfg <hostid> <filename> [options]

            where:    

                hostid      The IP address or hostname of the host from
                            which to request the file.

                filename    The name of the configuration file to be sent.
                            ( Note: for the Gracilis provided version of the
                                    rmtcfg SERVER code to be run on a PC, this 
                                    filename should NOT include a drive or
                                    directory specification.)

                options     Several new options have been implemented.
                            
                            -p <port>    TCP port number to use for 
                                         initiation of the server connection.
                                         If this option is not specified, then
                                         the default port: 1236 will be used.  
                            
                                         ( Note: If a value other than the 
                                           default is used, the remote server 
                                           must also be using the same value.)

                            -t <timeout> Time to wait ( in seconds) for 
                                         connection establishment to the remote 
                                         configuration server.  If the remote
                                         server fails to respond within this
                                         time period, the configuration attempt
                                         will be abandoned, and a secondary
                                         server, (if specified with the -h 
                                         option) will be queried.

                                         If this option is not specified, a
                                         default timeout of 60 seconds is used.

                                         
                            -h <hostid>  Optional secondary host from which 
                                         to request the configuration file, 
                                         if the primary host fails to respond
                                         within the timeout period.

                           
                            -i           This option indicates that the file
                                         being requested is to be used as the
                                         text for the "Info" message, that is
                                         available from the remote user /
                                         Net/Rom simulator interface.

                                         The option is intended to allow the
                                         switch to automatically request and
                                         update it's local info/help file,
                                         from a remote host.

 
            Examples:

              rmtcfg n4pcr.ampr.org switch.cfg 

                    To request file switch.cfg from host n4pcr.ampr.org
                    using the default port, and 60 second timeout.

              rmtcfg n4pcr.ampr.org switch.cfg -p 3600 

                    Specify that port 3600 should be used rather
                    than the default port.

              rmtcfg n4pcr.ampr.org switch.inf -i

                    Request file switch.inf and use it as the input
                    to the local information message.

              rmtcfg n4pcr.ampr.org switch.cfg -h k9vxw.ampr.org -t 45 -p 3200

                    Request file switch.cfg first from n4pcr, with a timeout of
                    45 seconds, on port 3200.  Then, if n4pcr fails to
                    respond within the timeout period, attempt to obtain the
                    file from k9vxw, using the same parameters.


    4. Fixes to allow quoted strings to be entered into EEPROM cmd lines.
       Previous releases were unable to allow commands which contained
       quoted strings, since the (") sign is considered an argument break
       character, and is interpreted immediately upon entry, and not
       actually entered into the EEPROM. 

       This release supports the use of the single quote (') as a
       pseudonym for the double quote ("), during entry into an EEPROM
       command line.  This allows commands such as the beacon text 
       command to contain a quoted string.

       For Example:

           ee co 1 beacon text 'N9QSO is on the Air!'

    will result in an eeprom line as follows:

           1: beacon text "N9QSO is on the Air!"

    and will be properly interpreted at startup time.


        Another command for which this may be useful is the
        interface description command, as follows:

           ee co 1 iface port0 desc 'Local 1200 bps LAN channel 147.555'

        results in:

           1: iface port0 desc "Local 1200 bps LAN channel 147.555"



    5.  New Improved HBOOT302.EXE

        The new hboot302.exe supports specification of non-standard
        base memory and i/o addresses, for use with the PC-PackeTen.
        For a usage message, use the following:

        hboot302 ?


        ============================================
    6.  ERRATA from PackeTen Manual for IPC attach
        ============================================

    NOTE: The attach commands to be used with the PC version
    of NOS, when communicating with an internal PC-PackeTen,
	AND with the PackeTen itself, have been enhanced since the 
	last manual printing.

    The new attach procedures to be used with PC versions of
    NOS with PackeTen IPC drivers, are as follows:

    ========================================================
    Attaching an Inter-Processor Communication (IPC) link - 
    ========================================================

    There are two IPC attach lines: one for the PackeTen card and
    one for NOS running on the PC.  

    The PackeTen IPC attach line is as follows: 

    attach ipc <processor (dc|mc|pc)> <name> <mode> [txqdepth] [rxbufs] 
               [ip addr]


    The PC IPC attach line is as follows:

    attach ipc <vector> <processor (dc|mc)> <name> <mode> [base addr] 
               [ctl addr] [txqdepth] [rxbufs] [ip addr]


    The differences between the two attach commands are that on the PC the
    the user must specify the interrupt vector number.
    Additional optional parameters for the PC version include the base 
    I/O and Memory addresses to be used by the IPC driver.   The interrupt 
    vector number can only be used by the NOS IPC driver - It cannot be 
    shared with other devices/cards in the PC.


    Where,

        "attach"    is the command itself,

        "ipc"       describes the basic link type,
        
        "vector"    PC vector to be used by the IPC driver -
                    only applies to NOS running on the PC 
                    and not to NOS running on the PackeTen card.
                
        "processor" the processor you want to communicate with.

                    For NOS running on the PC this can be "mc" or "dc",
                    main card (PTS-1) or daughter(PTS-1S), respectively.
                    The daughter card can be attached to the main card 
                    and therefore allow the PackeTen switch to be
                    used to support 10 communication links from 
                    the PC.

                    For NOS running on a PackeTen card this can be
                    mc|dc|pc, main card, daughter card, or the
                    PC.  For example to connect the main card to the
                    PC specify pc.  

        "name"      is a user supplied interface name by which
                    this link will be known, 


        "mode"      is the data encapsulation mode.  Options are: ax25 or ipc.
                    The ax25 encapsulation mode allows users to utilize AX.25 or
                    NET/ROM connections across the IPC link in addition to
                    IP datagrams.  Mode ipc, is used to pass unencapsulated IP 
                    datagrams across the link, and will not allow AX.25 
                    connections to be established through the IPC link.

        "base addr" is the address of the Tri-port ram on the 
                    PC version of the card.  This address is
                    set by a jumper on the card.  The format
                    of this field is - 0xD000:0000  Where all
                    of the zero's are required to correctly
                    specify the address.

                    Possible values are:
                                        0x8000:0000
                                        0x9000:0000
                                        0xA000:0000
                                        0xC000:0000
                                        0xD000:0000     (default)
                                        0xE000:0000

        "ctl addr"  is the base I/O address to be used to communicate with
                    the PackeTen from the PC. This optional command allows
                    the system to be configured for a non-standard base
                    address.  If not specified otherwise, the IPC driver
                    assumes a base address of 238 Hex.  See the PackeTen
                    documentation for I/O base switch settings.


        "txqdepth"  is the maximum number of messages to be 
                    transmitted which the IPC driver will queue.
                    The default value is 32.  The purpose of this 
                    parameter is to ensure that the system does not
                    run out of memory should the other processor 
                    fail to keep-up with the data traffic. 
            
                    To change this value after an attach use
                    "kiss param 1", e.g. if the name used in the
                    attach ipc command is ipc0 then 

                    "param ipc0 1 50" changes the txqdepth to 50.

        "rxbufs"    number of pre-allocated receive buffers.  The
                    default value is 6.  To maximize throughput
                    IPC driver (like all PackeTen drivers) will
                    not allocate memory during an interrupt and
                    therefore must have memory buffers available
                    whenever an IPC receive interrupt occurs.
                    The user can tune his system system by 
                    specifying the number of pre-allocated
                    receive buffers to be used by IPC.

                    Note:   The IPC Statistic RxNoBufs tells
                            how many times the IPC driver did
                            not have a pre-allocated receive
                            buffer available when an IPC receive
                            interrupt occurred.
            
                    To change this value after an attach use
                    "kiss param 0". For example, if the name used 
                    in the attach ipc command is ipc0 then 

                    "param ipc0 0 15" 
                    
                    changes the number of pre-allocated receive 
                    buffers to 15. 

        "ip addr"   optional parameter to be used as the IP address
                    associated with this particular link.





    ************
    NEW to 3.0d7(a)
    ************

    1. This load provides fixes to AX.25 flow control (RNR) 
       and timer handling.

       All versions of NOS - AX.25 to date 11/6/92 contain a bug 
       in the state machine which fails to properly implement flow
       control, if the incoming queue on an AX.25 circuit 
       fills, due to an outgoing cross-connection failure
       or congestion.  This release fixes the flow control
       problem, properly implementing RNR flow control to the
       source of the incoming circuit.

       This is a special release for Brian Kantor, prior to release
       of a completed 3.0e load.  All fixes for this release will be
       officially applied to release 3.0e.


    ************
    NEW to 3.0d7
    ************

    1.  Fix for high speed baud rate calculation for 
        Async 302 ports.  We now properly support
        38.4kb and 57.6kb and higher async rates. 
                                
    2.  Fix for lost TX Events on synchronous 302 ports.
        This bug could cause a 68302 port to be unable to
        transmit untill after a system restart.  Typically, this
        was caused by the reception of a frame during
        boot up time.  This release corrects the problem.


    ************
    NEW to 3.0d6
    ************

    1.  Fix bug which caused the domain client to mark  
        a timeout on a request, as an unknown entry...  
        Thereafter it would not even try to resolve it.
        It would simply return host unknown.                 

    2.  Fix lingering tcp connections from abandoned finger  
        requests.  Similar to fix in 3.0d4 for mbox.

    3.  Added an outcall connection timeout for mailbox 
        users.  If a user connect request fails to         
        complete in time, it is automatically aborted.
        The default timer value is 120 secs. 

        Command format: mbx outcall <seconds>

    4.  Fixed yet another bug in the Uptime reporting    
        It wouldn't properly report the # weeks...        



    ************
    NEW to 3.0d5
    ************

    1. This release fixes a compiler/optimizer bug, which affected
       use of the 8530 ports in synchronous mode with internal clocking,
       and nrzi encoding.  The symptom fixed was that sometimes
       ports 3 or 4 would not properly transmit after initialization.
       The transmitter would begin working properly only after reception 
       of a frame.  The bug was that the compiler optimizer saw that
       the data from some of the reads of the data registers of the 
       8530 port were not used, and it assumed that they were not necessary,
       and therefore removed them, without warning... YUKK!!!  Those
       reads were a necessary part of the DPLL loopback initialization
       routine, and consequently, the DPLL never started up until incoming
       data was received.

       While it is not known exactly how long this problem has existed,
       I have tested versions all the way back to 2.1, with the problem
       still in evidence.  Since this release appears to have fixed the 
       problem cleanly, it is recommended that all switches which are
       directly utilizing 1200 bps modems (i.e. not TNCs), should update 
       to this release.

    ************
    NEW to 3.0d4
    ************

    1. Force all outgoing AX.25 connection initiation attempts to
       flush any previously queued data for the destination node,
       before attempting to make the new connection.  This is 
       intended to fix a problem with data from a previous downlink
       being sent thru a new connection to the destination node, upon
       initial connection exchange.

    2. Close and RESET any outcall/downlink connections associated with
       a user whose mailbox session is timed out.  This eliminates TCP
       connections which had been being left laying around when a remote
       user timed out, leaving a cross link in place.


    ************
    NEW to 3.0d3
    ************

    1. This is a simple one feature release.  A mailbox user may
       now disable the "escape" char while using the PackeTen to
       transport BINARY data through the system.  This will allow
       BBS'es to connect to the PackeTen, disable the escape char,
       and forward BINARY traffic.

       The format is as follows:

       (E)scape disable <CR>     - to turn it off.
       (E)scape <CR>             - to display current settings.
       (E)scape enable <CR>      - to re-enable it.
       (E)scape <char> <CR>      - to change it.


    ************
    NEW to 3.0d2
    ************

    1.  Configuration of a PackeTen from a remote configuration file.
        A new command "rmtcfg" has been added to allow the PackeTen to request
        a configuration file from a remote "rmtcfg server".  

        This command works in conjunction with a "rmtcfg server" which 
        receives the request and sends the contents of the specified file 
        to the PackeTen.  The PackeTen receives the data and interprets it 
        as if it had been entered as operator commands.  
        
        This feature is intended to allow the sysop to generate large 
        configuration control files without the need to worry about the 
        limit on the number of commands which may be entered into the 
        PackeTen's local EEPROM.

        After initial configuration of a PackeTen node through EEPROM
        commands, (including routing information to the host on which
        the "rmtcfg server" will be running) it is expected that the
        "rmtcfg" request command would typically be used as the last
        command to be executed from the EEPROM.  This will allow fully 
        automated configuration in cooperation with a remote system.

        The format of the remote configuration request command, (to be
        executed on the PackeTen) is as follows:

            rmtcfg <hostid> <filename> [port #]

            where:    
                hostid      The IP address or hostname of the host from
                            which to request the file.

                filename    The name of the configuration file to be sent.
                            ( Note: for the Gracilis provided version of the
                                    rmtcfg SERVER code to be run on a PC, this 
                                    filename should NOT include a drive or
                                    directory specification.)

                port #      Optional TCP port to use for initiation of the
                            server connection.  If not specified, then
                            port 1236 will be used.  
                            
                            ( Note: If a value other than the default is used, 
                                    the remote server must also be using the 
                                    same value.)

            Examples:

                rmtcfg n4pcr.ampr.org switch.cfg 

                    To request file switch.cfg from host n4pcr.ampr.org

                    OR

                rmtcfg n4pcr.ampr.org switch.cfg 3600 

                    To specify that TCP port 3600 should be used rather
                    than the default port.


        In order for the PackeTen to be able to request a remote configuration
        file, a "rmtcfg server" must be available which understands the 
        PackeTen's request, and answers appropriately.  A version of such a 
        server is provided for standard KA9Q NOS, running on a PC. 
        NOTE: The source code for this server is contained in the Gracilis
        modified version of KA9Q NOS for the PC, which is also available on 
        the BBS.

        Once NOS is running on the PC, a "rmtcfg server" must be started, 
        BEFORE any interfaces are attached for use by the PC.  
        This must be done so that as soon as the interfaces
        are activated, they will acknowledge remote configuration requests.
        If the server is NOT activated before such a request is received,
        the request will be denied, and the remote station will not receive
        it's configuration file.

        The format of the command necessary to start the Gracilis remote 
        configuration server running on a PC version of NOS is as follows:

        From the NOS command line on the server PC:

            start rmtcfg [port #]

            where the optional port # is the TCP port on which to listen for
            requests from the PackeTen.  If no port is specified, then the
            server will utilize port# 1236 as a default.



    2.  AX.25 Learned routing enhancements.
        This release provides ax.25 "learned" routing which is intended to
        be fully compatible with standard TNC's and netrom software. 

        In the past, if a user connected to the switch 
        using a digipeated path, the switch would return to him using the 
        same path.  Additionally, all future connections from the same
        user would have inherited the "learned" digipeated path, regardless
        of the fact that they might now be attempting to make a "direct"
        connection.  This situation was also true of outgoing user initiated
        "downlinks" from the node to other ax.25 stations.  Once a digipeated 
        path existed to a given destination, it remained the path of choice 
        until a sysop intervened and manually removed the "learned" route.  
        This behaviour is peculiar to NOS and is not typical of TNC's or
        netrom systems.  The bug exists in all previously known versions of 
        KA9Q NOS and it's derivatives.

        This release corrects the behaviour as follows:

        If an ax.25 route is manually entered by an operator
        command, it is considered "permanent".  It will not be
        overridden under any circumstance other than another
        specific operator command to delete it.  Therefore,
        regardless of digipeaters used by the remote station,
        or the downlink route specified by a local node user, the
        "permanent" routing information will be used to make the 
        specified connection.

        If no "permanent" return route exists to a destination, then the route
        used by an incoming packet is "learned" as a temporary route,
        and used in subsequent AX.25 routing.  If future packets are
        received from the same source, with a different digipeater list, 
        (or no digi's), then the previously "learned" route is removed 
        and the new one added.

        This behaviour is also used for outgoing "downlinks".  When
        a user specifies a digipeater path to be used to downlink to
        another ax.25 station, the digi path is "learned" and is used
        for subsequent connections until a different path is specified.

        
    3.  Fix for occasional garbage transmitted from an async 8530 port
        configured for KISS or SLIP use.  
        
        This bug would occasionally cause an extremely long frame to be 
        sent out an 8530 port (ports 3 or 4) when they were configured for 
        KISS or SLIP modes.  The frame would contain apparently random data
        from previously sent/received frames.


    4.  Fix for occasionally truncated receive frames on synchronous
        68302 ports (ports 0,1,2) when configured with an internal
        9600 bps G3RUH modem, under poor rf link conditions.

        If, during the reception of an incoming packet, the DCD signal
        from the modem dropped, even for an instant, the incoming
        frame is aborted and marked as possibly invalid.  The sync302
        driver code was not properly handling this condition, and would
        occasionally allow a truncated frame to be passed up to the
        network layers as it it were complete.  While this behaviour
        would typically not affect TCP connections, since they use their
        own internal checksum mechanisms, NETROM and AX.25 connections
        would not detect the loss, and therefore some data would simply
        be lost.  Note that this condition only appeared when the rf
        path was marginal to the point that DCD was flickering even
        during the presence of valid data.

        This bug has been fixed, and should no longer be an issue.


    ************
    NEW to 3.0d1
    ************

    1.  The TCP backoff timer is now selectable between binary (exponential)
        and linear ( add a fixed constant for each backoff ).  The linear 
        setting should help with busy or poor links to maintain a reasonable 
        retry rate, and not cause sessions to appear to hang, due to very 
        long backoff times.

    2.  The RIP TTL value has been made into a configurable parameter.  This
        should make the use of RIP on radio channels viable as an alternative
        for dynamic routing.  The default setting is 1800 seconds, or 1/2 hour.

    3.  The AX25 BLIMIT parameter meaning has been changed to represent the
        MAXIMUM time between AX.25 level 2 retries.  Effectively capping the
        backoff time on a connection, so as to prevent extremely long retry
        timers due to intermittent or poor links.  The default is set to
        60 secs.

    4.  The REMOTE USER interface has been changed to allow USERS to specify the
        interface/port name (for outgoing downlinks from the switch) without 
        regard to CASE SENSITIVITY.  This is intended to help with users who 
        are not used to dealing with mixed case characters.

    5.  The maximum password length for the system has been extended to 25
        characters.

    6.  A character selection bug has been fixed in the secure mode of
        sysop password operation.  Previous versions would prompt for
        a sequence of letters, but only from the first 7 letters of 
        the password.  This has been fixed now to select from all letters
        of the master password.

    7.  The default condition for the AX.25 T3 timer has been changed from
        0 (disabled) to 180 seconds.  This was done to prevent a default
        configured switch from eventually running out of socket connections,
        because it was maintaining lots of old DEAD connections.  By
        defaulting to 3 minutes, the switch will poll connections which have
        not been active, and eventually close those connections, if they 
        do not answer.

    8.  The default has been changed for the AX.25 version.  AX.25 Version
        2.0 will now be the default.

    9.  A bug which caused the uptime report to ROLL OVER after 3 1/2 weeks
        has been fixed.  The timer should now run for 500 weeks without
        a rollover.

    10. A new command has been added to allow the sysop to enable/disable
        the "Linked to" messages.  mbox linkmsg <on|off>.
        The default is off.

    11. A change has been made to restrict outgoing connections from remote
        IP USERS who have logged into the switch with an id which is not
        a valid callsign. ( Simple letters/number/no punct etc check ).
        If such a user attempts to issue an outgoing connection, he is
        issued a "permission denied" message and directed to log in using
        his/her amateur callsign.