Online Amateur Radio Community Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======Section 1 - General Commands======
==== ACL ====
<code>ACL(1)                  XROUTER REFERENCE MANUAL            23/10/2023
</code> **COMMAND** <code>
        ACL -- IP Access Control List commands

</code> **SYNOPSIS** <code>
        AC[l] D[eny] <source> <destination> [protocol]
        AC[l] L[og] [0-3]
        AC[l] M[ove] <rule number> <U[p] | D[own]>
        AC[l] P[ermit] <source> <destination> [protocol]
        AC[l] R[emove] <rule number>
        AC[l] V[iew]
        
</code> **DESCRIPTION** <code>
        The ACL command allows XRouter's IP Access Control List to
        be viewed and edited on the fly without having to edit and
        reload IPROUTE.SYS.

        The Access Control List specifies which IP addresses are
        allowed to send datagrams to, receive datagrams from, and
        route datagrams through XRouter's TCP/IP stack. It is a
        "packet filter", which operates on "rules".

        A DENY rule denies access to a specified destination from a
        specified source, whilst a PERMIT rule allows access. Both
        types of rule can work on single addresses or whole subnets.

        Rules can be added using the ACL commands, either at the
        command line or in IPROUTE.SYS.

        If the Access Control List contains no rules, the default
        action is "permit", i.e. no filtering is performed. This is
        unsatisfatory, but was necessary to maintain backward
        compatability.

        If one or more rules are present, the default action is
        "deny", i.e. datagrams are ignored unless they match a
        "permit" rule.

        Rules are applied in the order in which they appear in the
        table.

        There is currently no mechanism to save a modified ACL back
        to the IPROUTE.SYS file, as the ACL command is intended only
        for on-the-fly changes.

        The syntax for each sub-command can be revealed by
        typing that sub-command without any arguments.

</code> **OPTIONS** <code>
        Typing ACL without any arguments reveals the subcommands as
        follows:

            D[eny]      Add a "deny" rule to the TCP/IP filter list 
            P[ermit]    Add a "permit" rule to the TCP/IP filter list
            M[ove]      Moves a rule up or down in the list
            R[emove]    Remove a TCP/IP filter rule
            V[iew]      View TCP/IP filter rules
            L[og]       Display/change ACL logging state

        The PERMIT and DENY sub-commands APPEND filter rules to the
        IP Access Control List.  The <source> and <destination>
        arguments each have the form:

                     <ip_address>[/mask][:port]

        <ip_address> is the source or destination IP address.

        [mask]       is an optional subnet mask, espressed EITHER as
                     the number of bits (0-32) of the IP address to
                     match from left to right, OR as a dotted quad.

        [port]       is an optional TCP or UDP port number. Omitting
                     this or setting it to 0 implies "any port".

        [protocol]   if present, restricts the rule to a single
                     protocol. This is the number of the higher level
                     protocol carried in the IP datagram, for example
                     TCP is 6 and UDP is 17. Omitting this field, or
                     setting it to 0 implies "any protocol".

        The combination 0.0.0.0/32 is a special case matching any of
        XRouter's IP addresses.

        The VIEW subcommand displays all the rules. Each rule has a
        number, which can be used by the REMOVE subcommand.

        The REMOVE subcommand removes a rule. After removal, the
        remaining rules are renumbered.

        The LOG subcommand displays or sets the ACL logging level.
        The only levels so far defined are:

            Level   Actions
            -------------------------------------------
            0       No ACL logging
            1       Log denial events
            2       Display denial events on IDS window
            3       Log and display denial events

        Typing ACL LOG without any arguments displays the current log
        level.

        If ACL logging is enabled, ACL events go into the main daily
        log. Be aware that in some cases this might generate a lot of
        logging, and in other cases virtually nothing. It depends on
        how strict your rules are, what your IP routing table is
        like, how open your system is to the outside world, and how
        much it is attacked.

        Logging defaults off, but the ACL LOG command may be used in
        IPROUTE.SYS to set it on at bootup if desired.

</code> **EXAMPLES** <code>
        Allow LAN sources to access any destination:

            acl permit  192.168.0.0/16  0.0.0.0/0

        Allow XRouter to access any destination:

            acl permit  0.0.0.0/32  0.0.0.0/0

        Prevent non-LAN sources from accessing our TCP port 513:

            acl deny  0.0.0.0/0  192.168.0.245:513   6

</code> **AVAILABILITY** <code>
        The ACL command is only available to sysops.

</code> **SEE ALSO** <code>
        IPROUTE.SYS(8) -- IP Routing File.
        IDS(9)         -- Intrusion Detection System.
        ACCESS.SYS(8)  -- Telnet Access Control File.
        AXSCTRL(9)     -- TCP/IP Access Control.

</code>
----
==== AMSG ====
<code>AMSG(1)                 XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        AMSG -- Enter APRS Messaging mode.

</code> **SYNOPSIS** <code>
        AM[sg] <portnum>

</code> **DESCRIPTION** <code>
        The AMSG command switches the user's session into APRS 
        messaging mode, enabling him to exchange messages and 
        bulletins with APRS and UI-View users.

        The <portnum> argument specifies the radio port upon which 
        traffic will be sent and received. e.g. "AM 13" will use port 
        13.

        Within messaging mode, all commands begin with a forward
        slash (/), and anything else is treated as message text for 
        transmission.  The commands are as follows:

            /A[nnouncements]    Show announcements
            /B[ulletins]        Show bulletins
            /C[ancel] [#]       List / cancel unacked message(s)
            /D[irects]          Show directly heard stations
            /H[elp] [cmd]       Display command help
            /Monitor [on|off]   Query / set traffic Monitor mode
            /Q[uit]             Quit (exit)
            /T[arget] [call]    Query / set target for msg
            /U[iview] [on|off]  Query / set UI-View mode
            /V[ia] [digis]      Query / set digipeater path
            /X                  Exit

        Only the first letter of each command needs to be supplied.
        A few are worthy of further explanation....

        The /D command shows a list of all the stations heard 
        directly, i.e. not via digipeaters or 3rd party networks.

        Before any type of message or query can be sent, the user
        must specify a "target" address, using "/T [call]".  For
        messages, the target is a callsign.  For bulletins the target 
        should be BLN#*, where "#" represents a single digit, and "*" 
        represents the bulletin category of up to 5 characters.  
        Announcements use the same format as bulletins, except that 
        "#" represents a non-digit.  Attempting to send a message 
        without first defining a target will result in an error 
        response.  The target remains in force until a new target is 
        specified.  The current target can be displayed by entering 
        "/T" alone, or cleared by entering an invalid target, e.g.
        "/T .".

        Outgoing messages and bulletins are re-transmitted at 
        intervals until either an acknowledgement is received, or too 
        many retries have taken place.  Bulletins are re-transmitted 
        every 20 minutes for 4 hours, whilst announcements are re-
        transmitted every hour for 4 days. Messages are initially re-
        transmitted after 10 seconds, then the interval doubles with 
        each re-send.  When the interval exceeds approximately 1.5 
        hours, the message is expired and re-transmission ceases.
        The "cancel" command allows the re-transmission of outgoing 
        messages and bulletins to be cancelled at any time before 
        expiry.

        The /M (Monitor) command allows other APRS and UI-View
        message traffic on the channel to be watched.  The default
        is "off".  Entering /M by itself shows the current state.

        The /U (Ui-View mode) command sets the type of outgoing 
        message to be used.  The default is "off", which means that 
        all outgoing messages will be in APRS format. If turned "on", 
        outgoing messages will be in "UI-View" format.  In either 
        mode, both types of message can be received. UI-View messages 
        will display with a tilde (~) between the message and its ID, 
        whereas APRS-format messages will display with a curly
        opening bracket ({) if a message ID was supplied.  In UI-View
        mode, "\<decimal>" will send a UIVIEW message whose text
        portion  contains a single byte of value <decimal>, e.g.
        "\254" sends a PING request.

        /Q (quit) and /X (exit) are identical in function, exiting 
        message mode and returning the user to XRouter's main command
        prompt.

        The /V (via) command sets the digipeater path for outgoing 
        messages, or if used by itself displays the currently set 
        path.  The path defaults to the port APRSPATH specified in 
        XROUTER.CFG.  In APRS mode, the destination call is fixed at 
        APZ###, where ### is the 3 digit Xrouter version number, 
        whereas in UI-View mode the destination call is set by the 
        /Target command.

        The /H (help) command is used to display help for the 
        messaging commands.  If no argument is supplied, a very brief 
        (low bandwidth) command resume is displayed.  If the help 
        files are installed, "/H *" will list the help available, and 
        "/H <cmd>" can be used to obtain more detailed help for
        <cmd>, e.g. "/H /V". Note that the leading slash of the
        argument is ignored, so "/H V" is equally valid.

</code> **NOTES** <code>
        If Xrouter receives an APRS message whose target address is a 
        user currently logged into the APRS messaging shell, the 
        message is delivered to the user and, if there was a message 
        ID, an acknowledgement is sent.  Each re-send of the message 
        is acknowledged, because a re-send probably indicates that
        the sender didn't receive the previous ack.

        If the same message is received twice within 30 seconds, the 
        second copy is ignored.  This helps to eliminate duplicates 
        received via different digipeater routes.

        Expired messages are retained for 1 day before being deleted.  
        During this interval they will be reactivated if a "?APRSM" 
        query is received from the target station.  Outgoing
        bulletins and announcements are not retained after expiry.
        Incoming  bulletins are retained for 4 hours after last
        received, and incoming announcements are retained for 4 days
        after last received.

        The APRS spec limits the maximum message length to 67 
        characters. Because a message ID of up to 6 characters is 
        appended to the message, XRouter splits messages longer than 
        61 characters into separate messages no longer than 61 
        characters (excluding ID) each.

        All APRS facilities are an ongoing experiment and may be 
        liable to change as development continues.  The so-called 
        "APRS Protocol Reference" is rather fuzzy in places!

</code> **AVAILABILITY** <code>
        All users, but guests can't send messages.

</code>
----
==== ANSI ====
<code>ANSI(1)                 XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        ANSI -- Enquire/set ANSI colour mode

</code> **SYNOPSIS** <code>
        AN[si] [on | off]

</code> **DESCRIPTION** <code>
        The ANSI command switches ANSI colour mode on/off, and
        reports the current mode. 

        To use ANSI colour, you need an ANSI-capable terminal, such
        as XRouter, PuTTY, Windows Telnet or Linux Telnet.

        By default, sessions on the XRouter console are in colour,
        i.e. ANSI is ON. You can type ANSI OFF to view in glorious
        monochrome.

        If your session is in colour, and you perform a NetRom
        connect to another XRouter (version 502 or later), that
        connection will also be in colour.

</code> **EXAMPLES** <code>
        ANSI       Reports current on / off state.
        ANSI ON    Turn colour on.

</code> **AVAILABILITY** <code>
        The ANSI command is available to all users.

</code>
----
==== APPLMASK ====
<code>APPLMASK(1)             XROUTER REFERENCE MANUAL               4/9/2023
</code> **COMMAND** <code>
        APPLMASK -- Display / Set Application Connectivity Mask.

</code> **SYNOPSIS** <code>
        APP[lmask] <port> [0-255]

</code> **DESCRIPTION** <code>
        The APPLMASK command displays and controls which applications
        are connectable at AX25 L2 on the specified port. It has a
        similar function to the APPLMASK directive, used in
        XROUTER.CFG, but facilitiates runtime changes.

        In this context, "applications" refers to programs which use
        XRouter to provide their connectivity with the outside world. 

        In order to be directly connectable on a particular port,
        the application must have an APPLCALL, an APPLALIAS or both,
        and the corresponding bit in that port's APPLMASK must be set.

        APPLMASK specifies which applications are directly
        connectable on a given port.  The default is 255, which allows
        all applications.  The value is made up by adding together the
        desired selection from the following numbers:

                      1       - Enable Application 1
                      2       - Enable Application 2
                      4       - Enable Application 3
                      8       - Enable Application 4
                      16      - Enable Application 5
                      32      - Enable Application 6
                      64      - Enable Application 7
                      128     - Enable Application 8

        For example, if a port's definition contains "APPLMASK=9", it
        will only allow direct connections to applications 1 and 4 on
        that port, providing those applications have either an
        APPLCALL or an APPLALIAS.

</code> **AVAILABILITY** <code>
        The APPLMASK command is only available to sysops.

</code> **SEE ALSO** <code>
        APPLMASK(7)    -- APPLMASK Directive
        APPLS(9)       -- Application Support.
        XROUTER.CFG(8) -- Main Configuration File.
        
</code>
----
==== ARP ====
<code>ARP(1)                  XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        ARP -- Display / Edit the ARP table.

</code> **SYNOPSIS** <code>
        ARP A[dd] <host> <hwtype> <addr>
        ARP C[md] [0-255]
        ARP D[rop] <host> <hwtype>
        ARP F[lush]
        ARP L[ist]
        ARP M[axq] [0-32767]
        ARP LE[arn] <port | default> [ON | OFF]
        ARP P[ublish] <host> <hwtype> <addr>
        ARP T[imeout] [secs]
        ARP W[ait] [secs] 

</code> **DESCRIPTION** <code>
        The ARP command is used to display and edit the Address 
        Resolution Table, which maps IP addresses to hardware ones.

        <host>   is an IP address in dotted quad form.
        <hwtype> is hardware type, i.e. "ax25" "netrom" or "ether".
        <addr>   is the hardware address (callsign / ethernet addr).

        ARP by itself, lists the table.
        ARP ADD is used to add an entry to the table.
        ARP CMD specifies the functionality of the ARP command.
        ARP DROP is used to delete an entry from the table.
        ARP FLUSH flushes temporary entries from the table.
        ARP LEARN controls arp learning.
        ARP LIST lists the table.
        ARP MAXQ limits no. of datagrams queued pending resolution.
        ARP PUBLISH adds an ARP proxy entry for a hidden system.
        ARP TIMEOUT specifies max life of a dynamic entry (secs).
        ARP WAIT specifies how many secs to wait for an ARP reply.

</code> **EXAMPLES** <code>
        ARP ADD 44.131.91.2 ax25 gb7pzt-5    Add ax25 entry
        ARP DROP 44.131.91.7 ax25            Delete ax25 entry
        ARP PUB 44.131.91.127 ax25 g8pzt     Publish 91.127
        ARP TIMEOUT 30                       Set 30 sec lifetime
        ARP LEARN 2 ON                       Enable learn on port 2
        ARP LIST                             List the table
        ARP                                  List the table

</code> **MORE INFO** <code>
        ARP PUBLISH is used when a host is "hidden" on a network
        which is only accessible via XRouter, and allows XRouter to
        respond to ARP requests for the hidden system, by returning
        its own hardware address.

        The argument for "ARP CMD" is the sum of the desired options
        from the following list::

             1 = Command is available to secure sysops
             2 = Command is available to non-secure sysops
             4 = Command is available to users
             8 = Private addresses visible to secure sysops
            16 = Private addresses visible to non-secure sysops
            32 = Private addresses visible to all users

        The default is 9 (secure sysops only).
        A "secure sysop" is at the console, or on a private LAN.
        A "non-secure sysop" is one using a public RF network.

        ARP LEARN controls whether or not XRouter "learns" ARP info
        from passing ARP traffic. The default is for learning to be
        ON, but it may be enabled/disabled using
        ARP LEARN DEFAULT [on | off].

        Regardless of the default setting, learning can be enabled or
        disabled for any port, using ARP LEARN <portnum> [on | off].
        if not refreshed, learned entries persist for the interval
        specified by TIMEOUT, usually 15 minutes.

        ARP FLUSH removes temporary entries, i.e. those pending
        resolution. The default lifetime for these entries is
        specified by ARP WAIT (default 30 secs).

        ARP MAXQ [0-32767] is used to limit the nunber of datagrams
        which may be queued pending resolution. The default is 100.
        If the address fails to resolve, the queued datagrams are
        dropped.
        
</code> **AVAILABILITY** <code>
        The availability of the command is controlled by "ARP CMD",
        which is detailed above.

</code> **FILES** <code>
        ARP commands to be executed at boot-up are usually placed in
        IPROUTE.SYS, but they may also be used in BOOTCMDS.SYS.

</code> **NOTES** <code>
        In order for this command to have any meaning, XRouter must 
        have an IP address and be connected to an IP-capable network.

        You cannot add hardware address types for which there is no
        compatible interface, e.g. an attempt to add an Ethernet
        address on a system with no Ethernet interfaces will fail.

        The defaults are as follows:
        TIMEOUT=900 secs. WAIT=30 secs, MAXQ-100, CMD=9

</code> **SEE ALSO** <code>
        ARP(9) -- Address Resolution Protocol

</code>
----
==== AXROUTES ====
<code>AXROUTES(1)             XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        AXROUTES -- Display AX25 level 2 circuits

</code> **SYNOPSIS** <code>
        AX[routes] [ <portnum> | <callsign> | X ]

</code> **DESCRIPTION** <code>
        The AX[routes] command displays information about current 
        and recently active ax25 level 2 connections.

        It allows the sysop to monitor the performance of the links 
        between XRouter and its users or peers.

        Entries are purged 24 hours after they were last active,
        unless they are "locked" (indicated by "!" after the
        callsign), i.e. in use by level 3.

        The display shows the the port number and the remote
        callsign, with a chevron ">" in the leftmost column if the
        link is currently active.

        "M", "Pac" and  "F" are the Maxframe, Paclen and Frack last
        used on that link.  They may be the same as the port or
        global defaults, or they may have been dynamically modified
        by XRouter to suit the link conditions

        "RTT" is the Round Trip Time in seconds, i.e. the average
        time from sending a packet to receiving an acknowledgement
        for that packet.  This is dependent on many variables, such
        as the packet size, how good the radio link is, the data
        rate, the amount of queued data, the TXdelay and Resptime
        intervals at each end etc...

        "Sent" is the total no. of L2 frames sent to that station.
 
        "Resent" is the number of frames which had to be retried.
 
        "RTY%" is the ratio of these expressed as a percentage.

        "Rcvd" is the total no. of L2 frames received from that
               station.

        "Lost" is the number which were lost and had to be re-sent
               from the other end.

        "Rol" is "Rate Of Loss", which is effectively the retry rate
              which would be seen by the other station.

        Finally, Date/Time shows when the station was last heard.

</code> **OPTIONS** <code>
        AX[routes] by itself    lists all the L2 routes.
        AX[routes] <callsign>   lists only the routes to <callsign>.
        AX[routes] <portnum>    lists only the routes on that port.
        AX[routes] X            shows sent/rcvd bytes and throughput.

</code> **AVAILABILITY** <code>
        Sysop-only

</code> **NOTE** <code>
        This facility was intended for the author's benefit only. 
        It is likely to change or disappear altogether in future 
        versions.  If you find it useful, let the author know.

</code> **SEE ALSO** <code>
        LINKS(1)  -- Display currently active level 2 links
        ROUTES(1) -- Display links with adjacent nodes

</code>
----
==== BCAST ====
<code>BCAST(1)                XROUTER REFERENCE MANUAL              4/9/2023
</code> **COMMAND** <code>
        BCAST -- Trigger a "nodes" broadcast.

</code> **SYNOPSIS** <code>
        BC[ast] <portnum>

</code> **DESCRIPTION** <code>
        The BC[ast] command triggers an immediate NetRom "nodes"
        broadcast on the specified port, speeding up the process
        of neighbour discovery after a system restart.

        If a broadcast is triggered with this command, the next
        "scheduled" broadcast is re-scheduled, to take place after
        another NODESINTERVAL.

        Although this command was intended for test purposes only,
        it can also be used in CRONTAB.SYS for scheduling nodes
        broadcasts at specific times, overriding the automatic
        scheduler. This could for example be used to stagger the
        broadcasts to reduce loading on a radio PSU for example.


</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **NOTE** <code>
        This COMMAND should not be confused with the DIRECTIVE of
        the same name, used in XROUTER.CFG, which has a different
        purpose altogether.

</code> **SEE ALSO** <code>
        BCPOLL(1)      -- Request a nodes broadcast.
        BCAST(9)       -- UI Broadcasting
        NODESINT(1)    -- NODESINTERVAL command
        CRONTAB.SYS(8) -- Events control file
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BCPOLL ====
<code>BCPOLL(1)                XROUTER REFERENCE MANUAL           19/10/2023
</code> **COMMAND** <code>
        BCPOLL -- Request "nodes" broadcasts from neighbours.

</code> **SYNOPSIS** <code>
        BCP[oll] <portnum>

</code> **DESCRIPTION** <code>
        The BCP[oll] command requests a NetRom "nodes" broadcast from
        all neighbours on the specified port. This can speed up the
        process of neighbour discovery after a system restart.

        Upon receipt of this command, XRouter sends out a short
        packet addressed to "NODES". Most types of neighbour node
        should recognise this packet, and begin broadcasting their
        nodes list.

        The responses may not be immediate. Nodes wait a random
        interval up to 30 seconds before broadcasting, to avoid RF
        collisons. 

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        BCAST(1) -- Trigger a nodes broadcast.

</code>
----
==== BELL ====
<code>BELL(1)                 XROUTER REFERENCE MANUAL              4/9/2023
</code> **COMMAND** <code>
        BELL -- Display / Set bell times.

</code> **SYNOPSIS** <code>
        BE[ll] [h,h h-h] 

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The BELL command is used to display and set the hours during
        which the console bells will sound.  These are the two tone
        connection (low->high) and disconnection (high->low) bells,
        the 4 tone (Star Trek doorbell) sysop paging sound, and the
        various bells associated with sysop chat.

        Console sounds normally use the PC speaker, but Raspberry
        Pi's and modern laptops don't have speakers. In such cases,
        a sound device can be used instead (see AUDIO(9)).

</code> **OPTIONS** <code>
        When used without arguments, the current times are displayed.

        To set the bell times, the times may be supplied either as a
        series of single hours, or in one or more ranges of times
        e.g. "8-22", or as combinations of the two.

</code> **EXAMPLES** <code>
        BELL 12         - Bells only between 12:00 and 12:59
        BELL 0-4, 12-23 - Allow bells between midday and 4am next day.

</code> **CAVEATS** <code>
        Whatever the BELL setting, the console may still bleep if the
        sysop tries to exceed a line length or delete back beyond
        the start of a line.

</code> **NOTES** <code>
        The default bell times are 08:00 to 22:59 inclusive. The BELL
        command may be used in BOOTCMDS.SYS to override this
        Alternatively the BELL= directive can be used in XROUTER.CFG,
        like so...

             # Acceptable bell hours, format n,n,n-n n etc
             BELL=0-5,11-23

</code> **SEE ALSO** <code>
        AUDIODEVICE(7) -- Specify audio device name
        AUDIO(9)       -- About audio in XRouter

</code>
----
==== BLEVEL ====
<code>BLEVEL(1)             XROUTER REFERENCE MANUAL                4/9/2023
</code> **COMMAND** <code>
        BLEVEL -- Netrom Budlist de-rate level.

</code> **SYNOPSIS** <code>
         BL[evel] [0-255]

</code> **DESCRIPTION** <code>
        The BLEVEL command displays or sets the L3 "budlist level".
        This is the leakage level 0-255 for L3EXCLUDE. The default
        is 0 (allow no packets).

        This allows trafic from "troublesome" users to be "choked"
        to a greater or lesser degree. This has been found to be more
        effective than an outright ban, which usually results in more
        aggressive attacking. The miscreant simply assumes that the
        network is slow, and he doesn't get to do much.

        A BLEVEL of 0 blocks all NetRom L3 packets from the stations
        budlisted by L3EXCLUDE. At the other extreme, 255 allows all
        packets. The allow-rate is BLEVEL/256, so for example a
        BLEVEL of 64 would allow roughly 1 in 4 packets through.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **NOTE** <code>
        A directive of the same name can be used in XROUTER.CFG.

</code> **SEE ALSO** <code>
        BLEVEL(7)      -- L3 Budlist de-rate level directive.
        L3EXCLUDE(7)   -- Level 3 Exclusion List.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BLOG ====
<code>BLOG(1)               XROUTER REFERENCE MANUAL                7/9/2023
</code> **COMMAND** <code>
        BLOG -- Access Sysop's Blog(s)

</code> **SYNOPSIS** <code>
        BL[og] [nodecall | nodealias] 

</code> **DESCRIPTION** <code>
        The BLOG command connects the user either to the sysop's blog
        either at this node, or on another XRouter. 

        The blog is a text-only, packet radio version of an Internet
        "web log". It is a space for sysops to post "articles", which
        other people can "like" or reply to.

        Unlike the "wall", only SYSOPS can create original articles.
        These have no size restrictions, and may contain paragraphs
        and markup. Anyone may add comments to an existing article.
        Comments are not restricted in size.

        Blog articles are not forwarded to other packet systems, but
        may optionally be published to an MQTT broker.

        The blog may also be operated via the sysop's web interface,
        via MQTT, and via REST.

        The BLOGFLAGS directive enables or disables the blog, and
        controls whether the sysop is notified (via the PMS) of new
        likes and replies. It also controls whether articles and
        replies are published to the MQTT broker.
 
</code> **OPTIONS** <code>
        If no argument is supplied to the BLOG command, the user is
        connected to the local blog.

        If the argument is the nodecall or alias of another XRouter,
        which is in the nodes table, the user is connected to the
        blog of that node instead.

        After connecting to the blog, the available commands are as
        follows:

        B[ye]       Returns you to the node (same as Q[uit]).

        C[reate]    Begins creation of a blog article (sysop-only).
                    Text is entered in the same manner as for a PMS,
                    and is terminated by "/EX" on a new line.

        D[elete]    Deletes an article or reply.

        H[elp]      Displays a help summary.

        LIK[e] [n]  (shortcut "K") is used to "like" either the
                    article you've just read, or article number "n".

        L[ist]      Displays or re-displays the header information of
                    up to 5 articles at a time. Headers are displayed
                    in reverse chronological order, i.e. the most
                    recent at the top.

        N[ewer]     Displays up to 5 newer (more recent) articles.

        O[lder]     Displays up to 5 older (less recent) articles.

        Q[uit]      Returns you to the node (same as B[ye].

        R[ead] n    Reads article number "n". Or you can omit the 'R'
                    and use the number alone.

        REP[ly] [n] (shortcut "Y") begins a reply to the article
                    you've just read, or to article number "n".

        V[iew] [n]  View replies to current article, or article "n".

</code> **EXAMPLES** <code>
        BLOG       -- Connect to the PMS on this node.
        BLOG G8PZT -- Connect to the PMS on G8PZT node.

</code> **AVAILABILITY** <code>
        All users.

</code> **PHILOSOPHY** <code>
        A blog on Packet Radio might sound like a crazy idea, but is
        it any crazier than a packet bulletin board? Even though there
        are many Internet forums, people still run packet bulletin 
        boards!

        There are millions of blogs on the Internet, but can you
        remember all the URL's? Will they still be there tomorrow? Are
        they riddled with cookies, trojans and clickbait? Are they
        easy to use? Shouldn't packet blogs be hosted on PACKET?

        In order to survive, Packet Radio needs CONTENT. There's no
        point having a network if that network has nothing to do. The
        purpose of a network is to move DATA. A blog is just another
        form of data. It gives people a reason to use the network.

        The Sysop's blog is just another tool in the communications
        toolbox. Hopefully some sysops may contribute their thoughts,
        and others will find them interesting and thought provoking, 
        but you don't have to use it.

</code> **SEE ALSO** <code>
        BLOGFLAGS(7)   -- Options For Sysop's Blog.
        MQTT-BLOG(9)   -- MQTT Interface to Blog.
        MQTT-SRV(9)    -- MQTT Server / Broker
        PMS(1)         -- Personal Message System.
        REST-BLOG(9)   -- REST Interface to Blog.
        WALL(1)        -- Message Wall / Guestbook.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BYE ====
<code>BYE(1)                  XROUTER REFERENCE MANUAL            16/10/2023

</code> **COMMAND** <code>
        BYE -- Disconnect from the router.

</code> **SYNOPSIS** <code>
        B[ye]

</code> **DESCRIPTION** <code>
        The BYE command causes XRouter to terminate the uplink.

        It is particularly useful when a user cannot terminate the
        connection locally, e.g. if there's no easy access to their
        TNC's "command mode", or when the uplink is from another node
        with the "stay" option enabled.

        The disconnection occurs only after all outstanding data has
        been sent to the user.

        Disconnectiing the uplink terminates all dependent sessions.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        QUIT(1) -- Disconnect from the router

</code>
----
==== CAPTURE ====
<code>CAPTURE(1)              XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        CAPTURE -- Enable / disable tracing to disk file.

</code> **SYNOPSIS** <code>
        CAP[TURE] [on | off]

</code> **DESCRIPTION** <code>
        The CAPTURE command is used to enable or disable the capture 
        to disk file of incoming and outgoing traffic. 

        When capture is enabled, anything which is displayed in the 
        central window of an XRouter console is also written to disk.
        This includes session activity and TRACE'd data.  Whereas the
        screen display is filtered to prevent it being garbled by
        binary data, the capture is pure binary, so it is useful for
        diagnostics.

        The optional argument may be "ON" or "OFF".  If no argument is 
        supplied, the current setting is reported.

        This command overrides the <F5> (toggle capture) key.

        There is a seperate capture file for each XRouter "console",
        named CAPTURnn.TXT where nn represents the console number (01
        to 05).

        Capture is fully independent on each console, and consoles may
        be captured concurrently. Switching between consoles, or
        scrolling consoles back, does not affect the capture.

</code> **EXAMPLE** <code>
        CAP ON  -  Enables capture.

</code> **AVAILABILITY** <code>
        Cconsole and remote sysops only.

</code> **FILES** <code>
        The CAPTUREnn.TXT files are created in the XRouter working
        directory. Although they have the extension ".TXT" to enable
        them to be easily opened with Notepad, they may sometimes
        contain characters which Notepad can't display.

</code> **SEE ALSO** <code>
        MONITOR(1) -- Controls protocol tracing

</code>
----
==== CFLAGS ====
<code>CFLAGS(1)               XROUTER REFERENCE MANUAL              4/9/2023
</code> **COMMAND** <code>
        CFLAGS -- Display / Change Connection Control Flags.

</code> **SYNOPSIS** <code>
        CF[lags] <port> [0-31]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        CFLAGS is a port configuration command, whose primary
        function is to control whether or not AX25 level 2
        uplinking and/or downlinking is allowed on the port.

        A typical use may be to prevent users from uplinking and
        downlinking on APRS-only ports.

        It also allows the sysop to control whether or not L3RTT
        frames are generated on inter-node links, and whether or not
        AX25 level 2 fragmentation is allowed on the port.

        A directive of the same name can be used in PORT config
        blocks within XROUTER.CFG.

</code> **OPTIONS** <code>
        Add together the decimal values of the desired options from
        this list:

           Bit Dec   Function
           ---------------------------------------------------------
            0   1  - Allow incoming connections (uplinks).
            1   2  - Allow outgoing connections (downlinks).
            2   4  - Applications may downlink unconditionally.
            3   8  - Suppress L3RTT generation.
            4  16  - Allow L2 fragmentation.

        The default value is 3, i.e. unconditional use of the port.

        Irrespective of the setting of CFLAGS, the Sysop can always
        downlink.

        Bit 2 allows applications to downlink unconditionally, i.e.
        even if users are prevented from downlinking. 

        Bit 3 was provided to keep the Luddites happy, but its use is
        strongly deprecated.  Setting this flag prevents L3RTT frames
        from being originated by the port if it is carrying an
        inter-node link.  It will not prevent XRouter from trying to
        hold inter-node links open, as that is too much of a
        retrograde step!  This bit is not set by default.  Note that
        L3RTT may also be suppressed if a route's MAXTT is 65535.

        Bit 4 allows AX25 layer 2 fragmentation if it is set.  This is
        required if Forward Error Correction (FEC) is in use, to allow
        big L3 frames to be sent.

</code> **EXAMPLES** <code>
        CFLAGS 4  - Display current value for port 4
        CF 4 5    - Only sysops and apps can downlink on port 4.
  
</code> **SEE ALSO** <code>
        CFLAGS(7)      -- Set connection control flags.
        L2FRAG(9)      -- AX25 Layer 2 Fragmentation.
        L3RTT(9)       -- Layer 3 Round Trip Time.
        FEC(1)         -- Forward Error Correction.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CHATCMD2 ====
<code>CHATCMD2(1)          XROUTER REFERENCE MANUAL                23/1/2013
</code> **CHAT SERVER COMMANDS (M-Z)** <code>
==========================

</code> **The following commands are available within the chat server only.** <code>

/?        /ALERT    /ANSI     /BELL     /BYE      /CHANNEL  /ECHO
/EXIT     /HEADERLN /HELP     /JOIN     /KEEPALIV /KM       /KNOWN
/LEAVE    /LINKS    /MSG      /NAME     /NODES    /PERSONAL /PORTS
/QTH      /QUIT     /RECENT   /RM       /STAMP    /TOPIC    /USER
/VERBOSE  /VERSION  /WHO


</code> **CHAT SERVER COMMANDS IN DETAIL - continued** <code>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/MSG --- Send a short message to a channel or a single user.

         Syntax: /M[sg] <channel | callsign | callsign@server> <text>

         The /Msg command is used to send a short message (70 chars 
         max.) to any specified channel or single user.  You may for 
         example use this command to direct a message to a channel you 
         are monitoring, but not actually logged to.

         If you direct a message to a specific user, he may be on this 
         or any other chat server.  The private nature of the message 
         will be indicated to the recipient by asterisks around the 
         sender's call, e.g. <*g8pzt@kdchat*> (Paula): Meet me on 
         channel 69.

         If the target user's server is specified in the command, and
         the user isn't currently logged on, the message will be
         stored until he logs on. e.g. "/M g6yak@kdrcht Give me a
         shout on 'KD when you read this.."

         Examples: /M 32 Hello People
                   /M g6yak Meet me on channel 69
                   /M g6yak@kdrcht See u on KD later

         The first form sends "Hello People" to all the users of 
         channel 32, and the second form sends a private msg to g6yak 
         only. Providing G6YAK is logged on to any chat server, the 
         message will find him. The third form sends a private message
         to G6YAK on the KDRCHT server. If G6YAK is not currently
         logged on, the message will be stored for him.

         Note: As with all things Packet, the term "private" is 
         relative, as nothing is truly private when it is broadcast!


/NAME -- Set name.

         Syntax:  /N[ame] <your name> [channel]

         The /NAME command sets the user's name, which will be 
         displayed on the user list and prefixed to everything he 
         sends to others.

         Users are not allowed to join any channels until they have 
         supplied a name (12 chars max), so it acts as a "log on" 
         command.  The name need be supplied only at the initial 
         logon, and may be changed as the user wishes.

         On the first use of this command, the user may optionally 
         specify a channel to join instead of the default (channel 0).

         TCP/IP users must first use the /USER command (see below) to 
         enter their callsign.

         Examples: /N Paula       Set name to "Paula"
                   /N Paula 23    Set name and join channel 23


/NODES - Display RoundTable nodes

         Syntax: /NO[des]

         The /NODES command displays a detailed list of the known
         RoundTable / BPQchat nodes. This command currently duplicates
         the function of the /K command.

         The display includes the node call and alias, plus the
         software version used at that node.


/PERSONAL - Display / change personal description.

         Syntax: /P[ersonal] [text | @]

         The /PERSONAL command is used to display or change the user's 
         personal description.  This is a short text of up to 32 
         characters, which is displayed on the user list.  It may 
         typically contain the user's home town and "brag" 
         information.  If the user logs onto any "public" channels 
         (i.e. those above channel 255), this information will appear 
         on the user lists of all other chat servers.

         If used without arguments, the /PERSONAL command displays the 
         user's current text.  

         If the argument is "@", the existing text is removed.

         Examples: /P                        - Displays current text
                   /P Kidderminster, sysop   - Set new text.
                   /P @                      - Clear previous text.


/QTH --- Display / set QTH.

         Syntax: /Q[th] [your-qth]

         The /QTH command is used to set your QTH. QTH is not
         currently required by the XRchat system, but is mandatory
         if you log in to room 101 (RoundTable/BPQ chat).

         Examples: /Q                    - Displays current QTH.
                   /Q Weston Super Mare  - Sets new QTH.

         Note: QTH may include spaces, and can be up to 64 characters.


/QUIT -- Exit the chat server.

         Syntax: /QU[it]

         The /QUIT command, which may be shortened to /Q, disconnects 
         the user from the chat server, and informs everyone that he's 
         left.  There is no need for the user to /leave any logged 
         channels before issuing this command.

         If the user accessed the server via the router's CHAT
         command, he will be returned to the router's main command 
         prompt, otherwise he will be completely disconnected.

         The /BYE and /EXIT commands also perform this function.


/RECENT - Display Recent Messages

         Syntax:  /R[ecent] [channel]

         The /RECENT command displays the last 10 messages received
         in the last 24 hours.

         Examples:  /RECENT  - Show recent messages from all channels
                    /RE 1234 - Recent messages from channel 1234

         The purpose of this command is to display messages that you
         might have missed while you weren't connected, allowing you
         to conduct non-real-time conversations.

         Messages currently expire after 24 hours.


/RM ---- ReadMail

         Syntax: /RM

         The /RM (ReadMail) command is used to read any personal
         messages that were left for the user while he was offline.

         If someone sends a certain type of personal chat message to
         a user while he isn't logged in, that message is stored
         on the chat server, and he is notified when he next logs
         in.  He may then use the /RM command to read the messages.

         Messages are not deleted after they are read. The /KM
         (KillMail) is used to delete unwanted messages.


/STAMP - Controls timestamping of message texts.

         Syntax:  /S[TAMP] [on | off]

         With stamp ON (default) each mesage is timestamped in the 
         following style, designed to be readable both by humans and 
         by client software:

         [1234] 09:35 {21:33} <ZL2BAU@BAUCHT> (Peter): Hello folks

         The first field is the channel number.  This may seem
         pointless, but you will soon appreciate it if you are logged 
         to more than one channel!

         The second field is the chatserver's timestamp, i.e. the 
         local time the message was received at, and redistributed by, 
         the server.  This is useful if you are away from the screen 
         for a while, or are logging the activity to disk.

         The third field is the originating server's timestamp, i.e. 
         the local time at which the message was entered into the 
         system.  With servers linked across different timezones, the 
         two timestamps may differ by up to 12 hours.  Personally I 
         find it useful to know what the other user's local time is, 
         because it helps put their comments into perspective.  The 
         timestamps can also highlight propagation delays.

         The fourth field consists of the sender's callsign and the
         "alias" of the originating server.  Users may (and often do) 
         log onto more than one server, often at the same time.

         The fifth field is the user's name.

         Those who are used to chatting on the Ping-Pong system seem 
         to be unable to cope with anything which is different, so 
         with STAMP OFF the header information is abbreviated in the 
         Ping-Pong style as follows:

         <g8pzt:Paula>: Test


/TOPIC - Display / Change channel topic.

         Syntax: /T[opic] [channel] [text | @]

         Every channel has an optional topic, and the /TOPIC command 
         can be used to display the existing topic or change it.  The 
         topic can be up to 12 characters, and is displayed on the 
         /Who list.

         Examples: /T                        - Show current ch. topic
                   /T 32                     - Show channel 32 topic
                   /T 32 TCP/IP discussion   - Set topic for ch. 32
                   /T @                      - Clear topic.


/USER -- TCP/IP logon.

         Syntax:  /U[ser] <callsign> [name]

         The /USER command is available only to TCP/IP users.  It sets 
         the user's callsign (and optionally his name), which will be
         displayed on the user list and prefixed to everything he 
         sends to others.

         The user will not be able to join the conference without 
         supplying both callsign (9 chars max) and name (12 chars 
         max), but if the name is omitted from this command he may 
         enter it in the normal way with the /Name command.

         Examples: /U g8pzt          - Set callsign to "g8pzt".
                   /U g8pzt Paula    - Set callsign and name.


/USERS - Display RoundTable/BPQChat users.

         Syntax:  /U[sers]

         The /USERS command is available only when logged to the
         RoundTable/BPQChat channel (room 101). It displays all the
         users currently logged into the RoundTable/BPQ chat network.

         For each user, the callsign, name and QTH are displayed,
         together with the alias of the server where they are logged
         in.


/VERBOSE - Enable / disable Verbose alerts

         Syntax: /VERB[ose] [on | off]

         Controls whether or not the user gets advised of things
         happening on other channels.  e.g. if sysop is monitoring
         channel 1234 with verbose on, she would be advised whenever
         anyone logs on or off any channel.

         This is primarily of use to GUI clients, allowing them to
         build and maintain their own lists of who's on what channel.


/VERSION - Display chat server version.

         Syntax: /V[ersion]

         The /VERSION command displays the chat server version, author
         and compilation date.  Please quote it if reporting bugs.


/WHO --- List channels and users.

         Syntax: /W[ho] [*]

         The /WHO command lists who is logged onto the chat server,
         and what channels they are on.

         If no arguments are supplied, the active channels are listed,
         along with the callsigns of their users.

         If an asterisk is supplied as the argument, each user is
         displayed in more detail.  The display would typically show
         the user's callsign, name, personal text and logon date/time.

         Examples:  /W     Lists channels & users in brief format
                    /W *   Lists users in detail


</code> **SEE ALSO** <code>
        CHAT(1)     -- Start a chat session
        CHATCMDS(1) -- Chat server commands A-M

</code>
----
==== CHATCMDS ====
<code>CHATCMDS(1)           XROUTER REFERENCE MANUAL               23/1/2013
</code> **CHAT SERVER COMMANDS (A-L)** <code>
==========================

</code> **The following commands are available within the chat server only.** <code>

/?        /ALERT    /ANSI     /BELL     /BYE      /CHANNEL  /ECHO
/EXIT     /HEADERLN /HELP     /JOIN     /KEEPALIV /KM       /KNOWN
/LEAVE    /LINKS    /MSG      /NAME     /NODES    /PERSONAL /PORTS
/QTH      /QUIT     /RECENT   /RM       /STAMP    /TOPIC    /USER
/VERBOSE  /VERSION  /WHO


</code> **CHAT SERVER COMMANDS IN DETAIL** <code>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/? ----- Display commands / syntax help.

         Syntax: /? [cmd]

         When used without arguments, the /? command lists the 
         available commands.  The syntax for any of the commands thus 
         listed may be shown by specifying the command as an argument 
         to the /? command.

         Examples:  /?          List available commands.
                    /? /who     Display syntax for the /WHO command.


/ALERT - Enable / Disable channel join/leave alerts

         Syntax: /A[lert] [ON | OFF]

         Examples: /A             Reports current on / off state.
                   /ALERT ON      Turns alerts on.

         If ALERT is ON, the server sends you a notification every
         time someone joins or leaves the channel (room) you are in.
         This is the default setting.


/ANSI -- Enable / Disable ANSI colour

         Syntax:  /A[nsi] [on | off]

         The /ANSI command is used to enable or disable the use of
         ANSI colour.  In order to make use of this feature, callers 
         must be using an ansi-compatible terminal.  When enabled, 
         each user's messages are shown in a different colour making 
         it easier to follow threads of conversation. 

         Typing /ANSI by itself displays the current setting.


/BELL -- Display / Set activity bell

         Syntax: /BE[ll] [0-3]

         The /BELL command controls which events are signalled by an 
         audible warning.  The warning consists of a bell character 
         (ascii 7) within the text.  In order to use this feature, 
         your terminal software must respond to bell characters.

         Arguments to the /BELL command are as follows:

               0     No bells (default setting)
               1     Informative messages from chat server only
               2     Text entered by other chatters only
               3     All events.


/BYE --- Exit the chat server.

         Syntax: /B[ye]

         The /BYE command, which may be shortened to /B, disconnects 
         the user from the chat server, and informs everyone that he's 
         left.  There is no need for the user to /leave any logged 
         channels before issuing this command.

         If the user accessed the server via the router's CHAT 
         command, he will be returned to the router's main command 
         prompt, otherwise he will be completely disconnected.

         The /EXIT and /QUIT commands also perform this function.


/CHANNEL - Display / Change logged channel(s).

         Syntax: /C[hannel] [number] | DEFAULT [number]

         The /CHANNEL command displays / changes the channel(s) the 
         user is logged to.  When no argument is supplied, the logged 
         channel(s) is / are displayed.  If a valid numeric argument 
         is supplied, the user is logged to the specified channel.

         Examples: /C               Displays your current channel(s)
                   /C 22            Change to channel 22
                   /C default 1234  Default to channel 1234.

         When a new channel is selected, the user remains logged to 
         any previous channels, (so he can "monitor" several channels 
         at once) but any subsequent text he sends will go to the new 
         channel (unless targeted otherwise).

         Channels 1 to 255 (except 101) are "local" to this server.
         Channel 101 links with RoundTable/BPQchat, if enabled.
         Channels 256 to 32767 may be linked to other Xrouter chat
         servers.
         If a connection with the "Tampa Ping-Pong converse"
         system has been enabled, channels 0 to -32767 correspond to
         channels 0 to 32767 on Ping-Pong, otherwise they can be used
         as local channels.

         The default channel at log-on is 1000. You may check or
         change this using the "/channel default" form of this command. 

         The /JOIN command has a similar function, and /LEAVE is used 
         to de-select unwanted channels.


/ECHO -- Control host echo

         Syntax: /EC[ho]

         The /ECHO command toggles host echo on and off.  The default 
         setting is ON, i.e. the user receives a copy of any text he 
         sends to the channel.

         Although host echo slightly increases bandwidth usage, it 
         helps to put the user's text into temporal context amongst 
         the other channel texts, especially when there is latency on 
         the links.  The user can more easily spot mistakes such as an 
         incorrectly entered name or callsign.


/EXIT -- Exit the chat server.

         Syntax: /E[xit]

         The /EXIT command, which may be shortened to /E, disconnects 
         the user from the chat server, and informs everyone that he's 
         left.  There is no need for the user to /leave any logged 
         channels before issuing this command.

         If the user accessed the server via the router's CHAT 
         command, he will be returned to the router's main command 
         prompt, otherwise he will be completely disconnected.

         The /BYE and /QUIT commands also perform this function.


/HEADERLN Controls display format

         Syntax: /HEA[derln] [on | off]

         The /HEADERLN command controls whether or not the "header"
         and text of messages are displayed on the same line.

         If the setting is OFF (default), the header and text are 
         displayed on the same line.  This leads to a more compact 
         display, especially when the texts are short.

         If the setting is ON, headers and text are displayed on 
         separate lines. 


/HELP -- Obtain help.

         Syntax: /HELP [topic]

         When used without arguments, the /HELP command gives brief 
         instruction on how to access various levels of help.

         If a topic is specified, detailed help for that topic (if 
         available) is displayed.  The topic may be a command name, or 
         any other chat server related topic.  A list of the available 
         help topics can be obtained by specifying "*" as a topic.

         Examples:  /H          Display general instructions.
                    /H *        List available help topics.
                    /H /who     Display help for /WHO command.

         Note:  When using /H to display help for a command, the         
         leading slash for that command may be omitted.  Thus         
         "/H /who" and "/H who" are equally permissible.


/JOIN -- Join (log onto) a channel.

         Syntax: /J[oin] <channel>

         The /JOIN command logs the user to a channel, and performs a 
         similar function to the /CHANNEL command.

         When a new channel is selected, the user remains logged to 
         any previous channels, (so he can "monitor" several channels 
         at once) but any subsequent text he sends will go to the new 
         channel (unless targeted otherwise).  (Unwanted channels may 
         be de-selected using the complementary /LEAVE command.)

         Example:  /J 22   Join channel 22

         See /CHANNELS for a description of the channels.

/KEEPALIVE - Enables / disables link "keep alive" messages.

         Syntax: /KE[epalive] [ON | OFF]

         Examples: /K             Reports current on / off state.
                   /KE ON         Turns keepalives on.

         There is no time-out on connections with XRchat, BUT if you
         are connected for long periods with no activity, some part
         of the link you are using may time out.  For example, a NAT
         entry may time out, or an inter-node link may disconnect.
         Keep alive messages are intended to keep such links open,
         by sending a short text every 10 minutes.

         If you are monitoring for long periods, the keepalives may
         become irritating, so don't enable them unless you need them.

/KM ---- Kill Mail

         Syntax: /KM

         The /KM (KillMail) command is used to delete personal
         messages after you have finished with them.

         If someone sends you a certain type of personal chat message
         while you are not logged in, that message is stored at your
         server, and you will be notified when you next log in. You
         may then use the /RM command to read the messages, and the
         /KM command to delete them afterwards.


/KNOWN - Known Nodes

         Syntax: /K[nown]

         The /KNOWN command, which may be shortened to /K, is used
         to display a detailed list of the known RoundTable nodes.
         The display includes the node call and alias, plus the
         software version used at that node.


/LEAVE - Leave (log off) a channel.

         Syntax: /L[eave] <channel>

         The /LEAVE command logs the user off the specified channel.  
         When a user joins a channel, he remains logged to any 
         previous channels, so this command allows him to de-select 
         unwanted channels.

         Example:  /L 22   - Leave channel 22


/LINKS - Display / Change peer links

         Syntax: /LI[nks] [*]
                 /LI[nks] ADD <peercall>
                 /LI[nks] ADD <peername> <ip_addr>:<tcp_port>
                 /LI[nks] DROP <callsign | peername>

         The /LINKS command shows the status of the links with other 
         chat servers, and allows sysops to add and drop links without 
         rebooting Xrouter.

         "/LI[nks]" by itself displays a list of the links with users
         and other severs. The fields are as follows:

         Callsign   - Callsign of user or peer server.
         Type       - Connection type (L2, L4, TCP etc).
         Connected  - Date / time when connection started.
         Last-heard - Date / time when last data rcvd.
         Sent       - No. of messages sent to this peer.
         Unsent     - No. of messages dropped due to congested link.
         Rcvd       - No. of messages received from this peer.
         Lost       - No. of messages not rcvd due to link congestion.
         Sta        - Connection state (1=opening, 2=open, 3=closing)
         TXE        - Indicates TX empty, i.e. nothing queued.

         "/LI[nks] *" additionally displays a list of the defined
         chat links, whether they are currently connected or not.

         "/LI ADD" adds a peer server to the list, and has two forms,
         one for NetRom links and one for TCP/IP links.

         In the Netrom case, <peercall> is the netrom callsign (not 
         alias) of the peer server, and it must exist in Xrouter's 
         nodes table otherwise the link will not be opened.  If you 
         have trouble with peers dropping in and out of the nodes 
         table, create a "locked" node entry.

         In order to define a link with a RoundTable/BPQ chat server
         the callsign must be prefixed with a '+' e.g. "+XE1FH-11".
         The link will not be allowed unless both callsign and alias
         are in the nodes table.

         In the TCP/IP case, <peername> is the server ID of a Tampa 
         Ping-Pong server, <ip_addr> is its IP address, and <tcp_port> 
         is the TCP port number of the server.

         Examples:  /LI ADD +G1SSL-11
                    /LI DROP G8NTU-8
                    /LI ADD brmcht 80.195.22.37:3601


</code> **SEE ALSO** <code>
        CHAT(1) -- Start a chat session
        CHATCMD2(1) -- Chat Commands in detail (M-Z)

</code>
----
==== CHAT ====
<code>CHAT(1)                 XROUTER REFERENCE MANUAL             24/9/2023
</code> **COMMAND** <code>
        CHAT -- Connect to Chat Server.

</code> **SYNOPSIS** <code>
        CH[at] [nodecall]

</code> **AVAILABILITY** <code>
        Available to all users except guests.

</code> **DESCRIPTION** <code>
        CHAT used by itself connects you to the integral chat server,
        allowing you to conduct conferences with one or more other
        users.

        The "CHAT nodecall" form of the command connects you instead
        to the chat server on another XRouter, providing that
        [nodecall] is in our nodes table.

        The chat server has its own set of commands, which are
        detailed separately in the CHATCMDS manual entry.

        There are 65536 separate channels (or "rooms") of which the
        first 256 (*except room 101) are local to this system, and
        the remainder may be linked to other systems, allowing
        widely separated users to chat.

        (*Room 101 links to RoundTable/BPQ chat, if any RoundTable
        links have been defined)

         In addition to the "positive" channel numbers, there are
        another 32768 channels numbered 0 to -32767.  These
        correspond to channels 0 to 32767 on the "Tampa Ping Pong"
        system.

</code> **NOTES** <code>
        The chat server may also be reached by connecting to its
        own callsign, either directly or through the Netrom network,
        or by telnetting to TCP port 3600 (or whatever it has been
        relocated to), or by connecting to NetRomX service number 2.

        Sysops have a "always-on" chat window for chatting amongst
        themselves, and there is a "chat monitor" window for keeping
        an eye on chat activity.

</code> **SEE ALSO** <code>
        CHATCMDS(1) -- Chat server commands.
        CHAT-SRV(9) -- About the chat server.
        CHAT-SVC(9) -- NetRomX Chat Service.
 
</code>
----
==== CMD ====
<code>CMD(1)                  XROUTER REFERENCE MANUAL              5/9/2023
</code> **COMMAND** <code>
        COMMAND -- CMD.

</code> **SYNOPSIS** <code>
        CM[d] <ADD | DROP> <alias> [args]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The CMD command is used to add or delete "command aliases",
        i.e. sysop-defined commands that translate to a simple
        command sequence.

        This would typically be used to add a "BBS" command which
        maps to "C 1 VK1BTR-13".

        There is no limit to the number of command aliases which may
        be defined.

</code> **OPTIONS** <code>
        "CMD ADD <alias> [args]" adds a new command specified by
        <alias>. The

        "CMD DROP <alias>" removes <alias> from the command list.

</code> **EXAMPLES** <code>
        cmd add kidder c 1 kdrnod-1   - Adds new command KIDDER
        cmd drop kidder               - Removes command KIDDER

</code>
----
==== CONNECT ====
<code>CONNECT(1)              XROUTER REFERENCE MANUAL              4/9/2023
</code> **COMMAND** <code>
        CONNECT -- Make an outgoing AX25 connection

</code> **SYNOPSIS** <code>
        C[onnect] [port] <call> [V(ia) digi[,digi...]] [svcnum] [S]

</code> **DESCRIPTION** <code>
        The CONNECT command, which may be abbreviated to "C", 
        instructs XRouter to make an outgoing (downlink) AX25 level 
        2 or 4 connection with another system.

        If the target is a known node (i.e. one which is in the nodes 
        table) a port number is not required, and will be ignored if 
        supplied.  The router will attempt to make a NetRom level 4 
        connection with the target, using information from the
        routing tables.

        To override the above mechanism and "force" a level 2
        connection with an immediately adjacent node, either of the
        following methods can be used:
        
        (a) by appending an arbitrary SSID to the target's ALIAS and
            specifying a port number if required, e.g. "C 4 MLVN-1".

        (b) by prefixing the target call with an exclamation mark,
            and specifying a port if required, e.g. "C 4 !G4FPV".

        If the target is NOT a known node, XRouter will attempt to 
        make a level 2 connection.  On multi-port systems, a port 
        number must be specified.

        The "V" (via) parameter allows up to 7 digipeaters to be 
        specified, e.g.:  "C 3 G6YAK V G8NTU G8EPR"

        The "S" (stay) parameter, e.g. "C <nodecall> S" causes the 
        uplink session to stay connected when the downlink session to 
        the target node is terminated.

        The [svcnum] parameter specifies the "service number" on the
        target system. This is only understood by XRouter nodes at
        present. It causes a "NetRomX" (XRouter extended netrom)
        connection to one of 65535 possible "services" hosted by the
        target system. The service numbers are "standard", like the
        "well known" port numbers in TCP and UDP. For example,
        service 0 is always the node's command line, service 1 is
        always an "information server", service 2 is always a PMS,
        service 8 is always a chat server, and so on. See the
        SERVICES manual page for a full list.

</code> **EXAMPLES** <code>
        C GLOS      - Level 4 connect to GLOS:GB7GH node
        C 4 MLVN-1  - Forced level 2 connect to MLVN:G4FPV node 
        C 3 G6YAK   - Level 2 connect to non-node G6YAK on port 3
        C KIDDER 8  - L4 connect to service 8 (chat) on KIDDER node
        C G8PZT 1 S - L4 connect to service 1, then stay connected

</code> **LIMITATIONS** <code>
        If more than 7 digipeaters are specified, only the first 7 
        will be used.

</code> **AVAILABILITY** <code>
        This command is available to everyone, with the exception of
        "guest" users, i.e. those who have accessed XRouter via the
        public internet without supplying a password.

</code> **SEE ALSO** <code>
        CX(1)       -- Connect using Extended Ax25
        SERVICES(9) -- Standard Service Numbers
        TELNET(1)   -- Initiate a TELNET downlink
        TTYLINK(1)  -- Initiate a TTYLINK downlink

</code>
----
==== CQ ====
<code>CQ(1)                   XROUTER REFERENCE MANUAL              8/5/2024

</code> **NAME** <code>
        CQ -- Send a CQ Message.

</code> **SYNOPSIS** <code>
        CQ [v[ia] digi,digi...] [text]

</code> **DESCRIPTION** <code>
        The CQ command can only be used in LISTEN mode. It sends a
        "CQ" message (Unnumbered Information frame) onto the channel
        being LISTENed to. Optional text and digipeater path may be
        supplied.

        The message is sent only once, but the command may be repated
        at suitable intervals.

</code> **OPTIONS** <code>
        The digipeater list, if included, must not include spaces,
        but there should be space between the V[ia] and the list.

</code> **EXAMPLES** <code>
        CQ
        CQ Parks on the air
        CQ v g8pzt,m0wof Gloucester Docks

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        LISTEN - Invoke Listen mode.

</code>
----
==== CTEXT ====
<code>CTEXT(1)              XROUTER REFERENCE MANUAL               4/9/2023
</code> **COMMAND** <code>
        CTEXT -- Display or Set Port "Connect Text".

</code> **SYNOPSIS** <code>
        CT[ext] <port> [cmd [text]]

</code> **OPTIONS** <code>
        CTEXT <port>            - Displays current text

        CTEXT <port> ADD <text> - Appends a line of text

        CTEXT <port> CLEAR      - Clears the whole ctext

        CTEXT <port> LOAD       - Loads ctext from CTTEXTn.SYS

        CTEXT <port> NEW <text> - Replaces existing Ctext

        CTEXT <port> SAVE       - Saves ctext to CTEXTn.SYS

</code> **DESCRIPTION** <code>
        The CTEXT command displays or sets the "connect text" for
        the specified PORT. This is a single or multi-line text that
        can be sent to a caller when they connect to the port. The
        companion command CTFLAGS controls which callers receive the
        text.

        If a port-specific CTEXT exists, it overrides the global
        CTEXT, on that port only.

        Connect texts are usually configured using CTEXT directives
        in XROUTER.CFG. The CTEXT *command* allows the texts to be
        changed "on the fly".

        Upon bootup, if a port CTEXT is not specified in XROUTER.CFG,
        XRouter looks for the file CTEXTn.SYS, whcre n is the port
        number. If the file is found, the contents are loaded.
        Otherwise the global ctext (if any) is inherited by the port.

        If the contents of CTEXTn.SYS is changed during runtime,
        they can be reloaded into memory using the LOAD sub-command.
        Or if the text is changed using the CTEXT command, it can be
        stored for the future, using the SAVE sub-command.

        The CLEAR subcommand erases any text stored in memory.

        Single line ctexts can be added with either NEW or ADD. The
        former clears any existing text. The latter is OK if there
        is no existing text.

        If <text> specifies a filename, the contents of that file
        are read "live" every time someone connects, so this is
        ideal for "dynamic" ctexts. This may be of use in EMCOMM
        scenarios. That file could for instance be updated by another
        program, such as an extreme weather detector.

        If the filename starts with the 5 characters "CTEXT", e.g.
        "ctext-news", that file will be read from the current
        directory. If it is a fully qualified path starting with "."
        or "/", there are no restrictions on where the file resides,
        so long as XRouter is allowed to access it. For example,
        using the CTEXT command:

            CTEXT 5 new /etc/weather/latest.txt

            CTEXT 6 new ctext-news.txt

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **NOTE** <code>
        There is also a DIRECTIVE of the same name, used in
        XROUTER.CFG, which has a diffferent syntax.

</code> **SEE ALSO** <code>
        CTEXT(7)       -- Set "Connect Text".
        CTFLAGS(1)     -- Display / Set Connection Text Control Flags.
        CTFLAGS(7)     -- Connection Text Control Flags.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CTFLAGS ====
<code>CTFLAGS(1)              XROUTER REFERENCE MANUAL              4/9/2023
</code> **COMMAND** <code>
        CTFLAGS -- Display / Set Connection Text Control Flags.

</code> **SYNOPSIS** <code>
        CTF[lags] <port> [value]

</code> **DESCRIPTION** <code>
        The CTFLAGS command controls which callers are sent a
        "connect text" (CTEXT) when they connect to XRouter.

        <port> specifies the number of the PORT to which the setting
        applies. Port 0 displays/sets the GLOBAL value, i.e. the one
        which is used for all ports without a specific override.

        [value] is the sum of the desired options from the following
        list (options 4 and 8 apply to global ctflags only):

           1 - Send CTEXT upon connection to NODEALIAS / PORTALIAS.
           2 - Send CTEXT upon connection to NODECALL / PORTCALL.
           4 - Send CTEXT to NetRom L4 callers.
           8 - Sent CTEXT to TELNET caller.

        The default value is 9 (Alias and Telnet only).
 
        Setting a value of 0 disables CTEXT entirely.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **NOTE** <code>
        There is a DIRECTIVE of the same name, used in XROUTER.CFG.

</code> **SEE ALSO** <code>
        CTEXT(1)       -- Display / Set "Connect Text"
        CTEXT(7)       -- Connect Text configuration directive
        CTFLAGS(7)     -- Ctext control flags directive
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CTRL ====
<code>CTRL(1)                 XROUTER REFERENCE MANUAL              5/9/2023
</code> **COMMAND** <code>
        CTRL -- Read / Write remote hardware control port.

</code> **SYNOPSIS** <code>
        Syntax: CTRL [0-255]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The CTRL command reads from and writes to the CTRL port 
        defined in the CFG file (e.g. CTRL=0378 to use LPT1).  This is 
        used for controlling external hardware devices via logic, and 
        reading status from them, for example transmitter bank 
        switching or temperature alarm monitoring.

</code> **OPTIONS** <code>
        "CTRL" by itself reads the port, and "CTRL <value>" writes it.  

        The read value is the bitwise OR of last written value and 
        external levels, so a bit must be written to 0 in order to use 
        it as an input.  If written to 1, a bit will always return 1.

</code> **EXAMPLE** <code>
        CTRL 127 - Write a 1 to bit 7 of ctrl port.

</code> **WARNING** <code>
        This page applies only to the DOS version! LPT ports are a
        thing of the past, so this will be repurposed to use other
        hardware, such as GPIO pins.

</code>
----
==== CX ====
<code>CX(1)                   XROUTER REFERENCE MANUAL              2/1/2024
</code> **COMMAND** <code>
        CX -- Make Outgoing AX25L2 Connection Using Modulo-128

</code> **SYNOPSIS** <code>
        CX [port] <call> [V(ia) digi[,digi...]] [S]

</code> **DESCRIPTION** <code>
        The CX (Connect eXtended) command instructs XRouter to make
        an outgoing (downlink) AX25 level 2 connection with another
        system.

        It is very similar to the normal "CONNECT" command, except
        that it ignores NetRom, and attempts layer 2 connections
        using "Extended AX25" (EAX25).

        If the target system is not capable of, or does not wish to
        use EAX25, it will answer with <DM> and XRouter will revert
        to regular AX25.       

</code> **OPTIONS** <code>
        On multi-port systems, a port number must be specified
        before the target callsign.

        The "V" (via) parameter allows up to 7 digipeaters to be 
        specified, e.g.:  "C 3 G6YAK V G8NTU G8EPR"

        The "S" (stay) parameter, e.g. "CX <callsign> S" causes the 
        uplink session to stay connected when the downlink session
        to the target station is terminated.

</code> **EXAMPLES** <code>
        CX 4 MLVN-1  - Forced level 2 connect to MLVN:G4FPV node 
        CX 3 G6YAK   - Level 2 connect to G6YAK on port 3
 
</code> **LIMITATIONS** <code>
        If more than 7 digipeaters are specified, only the first 7 
        will be used.

</code> **AVAILABILITY** <code>
        This command is available to everyone, with the exception of
        "guest" users, i.e. those who have accessed XRouter via the
        public internet without supplying a password.

</code> **SEE ALSO** <code>
        CONNECT(1)  -- Connect to Another System.
        MOD128(9)   -- AX25 Modulo-128 (Extended AX25)

</code>
----
==== DATE ====
<code>DATE(1)                 XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        DATE -- Enquire / set system date

</code> **SYNOPSIS** <code>
        DATE [dd/mm/yy[yy]]

</code> **DESCRIPTION** <code>
        If no argument is supplied, the existing system date is shown.

        If the argument is a valid date of form dd/mm/yy or dd/mm/yyyy
        the system date is set to the new value.

</code> **EXAMPLE** <code>
        DATE 24/2/99

</code> **AVAILABILITY** <code>
        The DATE command is available only to sysops. 

</code> **SEE ALSO** <code>
        TIME(1) -- Show time at any XRouter /  Set time here.

</code>
----
==== DHCP ====
<code>DHCP(1)                 XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        DHCP -- Display DHCP-obtained IP configuration parameters.

</code> **SYNOPSIS** <code>
        DHCP <port> [bind | release | trace n]

</code> **AVAILABILITY** <code>
        Sysop-only

</code> **DESCRIPTION** <code>
        For ports on which the DHCP Dynamic Host Configuration 
        Protocol) client is enabled, the DHCP command displays the
        IP configuration parameters which have been obtained via DHCP.

        Parameters displayed include: IP address, DHCP server 
        address, gateway IP address, primary DNS address, lease 
        expiry time, and DHCP state.

        States are as follows:

            INIT        - Initial state, no IP address yet.
            SELECTING   - Awaiting offers from sever(s)
            REQUESTING  - Client requests chosen address
            BOUND       - Lease obtained, OK to use.
            RENEWING    - Requesting lease renewal.
            REBINDING   - No response, locating new server

</code> **OPTIONS** <code>
        When the only argument is a port number, the DHCP settings
        for that port are displayed.

        The BIND option isn't curently implemented, as the client
        automatically binds.

        The RELEASE option forces the client to release the current
        configuration.

        The TRACE option displays or sets the DHCP trace flags. Use
        a non-zero value to enable tracing, or zero to disable it.
        Tracing is enabled by default.

</code> **EXAMPLES** <code>
        DHCP 3          - Display DHCP settings for port 3
        DHCP 3 RELEASE  - Relinquish port 3 lease.
        DHCP 3 TRACE 0  - Disable DHCP tracing on port 3

</code> **FILES** <code>
        DHCP is enabled by including the "DHCP=1" directive in the
        relevant PORT block within XROUTER.CFG.

</code> **CAVEATS** <code>
        The use of dynamic IP addressing for XRouter is strongly
        deprecated, as so many of its servers and protocols require
        "port forwarding", which is difficult when the IP address
        keeps changing!
      
</code>
----
==== DIAL ====
<code>DIAL(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        DIAL -- Dial a PSTN connection.

</code> **SYNOPSIS** <code>
        DIA[l] <port> <script>

</code> **DESCRIPTION** <code>
        The DIAL command invokes the named Dial Up Networking (DUN) 
        script on the specified port, to establish a land-line 
        connection with another system.

        This command has no effect unless the port is connected to a
        PSTN modem, the interface protocol is defined as MODEM, and
        the script file exists.

</code> **EXAMPLE** <code>
        DIAL 1 AOL.SCR

</code> **FILES** <code>
        The dialer uses script files which contain commands such as
        SEND, WAIT, MODE, SLEEP and CONTROL. The script files must
        reside in the same directory as XRouter, and the script name
        is limited to 11 chars.

</code> **AVAILABILITY** <code>
        Sysop-only

</code> **NOTES** <code>
        This command has litle relevance nowadays, as it is doubtful
        whether anyone still uses Dial-up networking, and Windows
        already has DUN tools.
        
</code> **SEE ALSO** <code>
        DUN(1) -- Dial Up Networking
        SCRIPT(9) -- Dialer script commands

</code>
----
==== DIGIFLAG ====
<code>DIGIFLAG(1)           XROUTER REFERENCE MANUAL               24/9/2023
</code> **COMMAND** <code>
        DIGIFLAG -- Display / Set digipeat options.

</code> **SYNOPSIS** <code>
        DIGIFLAG <port> [0-1023]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The DIGIFLAG command is used to display and/or set the 
        digipeat options for a specified port.

        New settings override those read from the XROUTER.CFG file,
        and remain in force until changed, or the system is restarted.

        The minimum abbreviation of this command is DIGIF.

</code> **OPTIONS** <code>
        Options are enabled by adding together the following numbers:

        Bit Value Option
        ---------------------------------------------------
         0    1   Digipeat UI frames
         1    2   Digipeat non-UI frames
         2    4   Enable RELAY generic digipeating (deprecated).
         3    8   Enable TRACE generic digipeating (deprecated).
         4   16   Enable WIDE generic digipeating (deprecated).
         5   32   Allow APRS 3rd party digi via L4.
         6   64   Allow digipeating to Internet (IGate).
         7  128   Allow digipeating from Internet (IGate).
         8  256   Enable UITRACE digipeating (e.g. WIDEn-n)
         9  512   Enable UIFLOOD digipeating (e.g. GBRn-n)

</code> **EXAMPLES** <code>
        DIGIF 3         Enquire current setting for port 3
        DIGIF 3 259     Enable UITRACE and normal digipeat on port 3
        DIGIF 2 0       Disable all digipeating on port 2

</code> **ADDITIONAL INFO** <code>
        UITRACE and UIFLOOD are two special addresses that are
        suffixed with pseudo-SSID's, e.g. "TRACE4-4" and "WIDE2-2".
        These addresses can digipeat several times. The first digit
        specifies the maximum number of hops, and the second is the
        hop counter, which is decremented each time the frame is
        digipeated.

        These two addresses behave slightly differently however. When
        a frame is digipeated on the address specified by UITRACE,
        each digipeater inserts its own callsign in the digipeater
        list and decrements the "SSID". Frames digipeated on the
        UIFLOOD address have their SSIDs decremented, but the digi
        doesn't insert its own callsign. 

        For the sake of consistency with UI-View, UITRACE defaults
        to "TRACE", giving TRACEn-n digipeating, and UIFLOOD
        defaults to WIDE, giving WIDEn-n digipeating.

        However, according to the APRS "New Paradigm", RELAY, TRACE
        and WIDE are deprecated, UITRACE should be set to "WIDE",
        and UIFLOOD should be set to a "state" code (e.g. "GBR" for
        the UK). These addressses may be specified in XROUTER.CFG.

        One of the main justifications for the new paradigm was the
        fact that some of the older digipeaters would repeat the same
        packets over and over. This does not happen with XRouter, due
        to its dupe prevention measures.

        Not everyone agrees with the "New Paradigm, so the choice of
        which features to enable is left you you.

</code> **SEE ALSO** <code>
        DIGIPORT(1)    -- Set port to digipeat on
        DIGIFLAG(7)    -- Digipeating Options.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DIGIPORT ====
<code>DIGIPORT(1)            XROUTER REFERENCE MANUAL               6/9/2023
</code> **COMMAND** <code>
        DIGIPORT -- Display / Set port to digipeat on.

</code> **SYNOPSIS** <code>
        DIGIPORT <port> [destport]

</code> **AVAILABILITY** <code>
        Sysop only.

</code> **DESCRIPTION** <code>
        Displays or specifies the port upon which digipeated frames 
        should be transmitted.

        If "destport" is not specified, the current setting is 
        displayed.

        If "destport" is zero (the default setting), frames are
        transmitted on the port upon which they are received,
        otherwise they are transmitted on the port specified.

        The minimum abbreviation of this command is DIGIP.

</code> **EXAMPLE** <code>
        DIGIP 3 5   - Digipeat frames received on port 3 to port 5

</code> **LIMITATIONS** <code>
        Frames may currently be digipeated only to one port, therefore 
        it is not possible for a BBS on one port to broadcast unproto 
        headers to several ports at once using DIGIPORT. However, it
        is possible using BCAST.

</code> **SEE ALSO** <code>
        BCAST(9)    -- One to many digipeating
        DIGIPORT(7) -- Destination Port for Digipeated Frames.
        DIGIFLAG(7) -- Control type of frames digipeated

</code>
----
==== DISCARD ====
<code>DISCARD(1)              XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        DISCARD -- Start a "data sink" session.

</code> **SYNOPSIS** <code>
        Syntax: DIS[card] [nodecall | nodealias]

</code> **AVAILABILITY** <code>
        Sysop-only

</code> **DESCRIPTION** <code>
        The DISCARD command starts a "sink" session, whereby the 
        router ignores (discards) everything subsequently sent to
        it.  This is useful for testing TNC's, link throughputs etc.

        Entering DISCARD without any arguments starts a sink session
        on this XRouter.

        If the optional argument is a nodecall or alias, and that
        node is in the nodes table, XRouter connects to the discard
        service on the specifed node. This only works if the target
        node is also an XRouter at present.

        A DISCARD session can only be ended by disconnection, or by
        typing "/x".

</code> **NOTE** <code>
        The DISCARD server is also available on NetRomX service 9,
        and by telnetting to TCP port 9 (This port may be altered
        or disabled using the DISCARDPORT=n directive.

</code> **SEE ALSO** <code>
        ECHO(1)        -- Start an Echo session.
        DISC-SRV(9)    -- DISCARD Server.
        DISC-SVC(9)    -- NetRomX Discard Service.
        DISCARDPORT(7) -- Specify TCP port for DISCARD server
        TCP-PORTS(6)   -- TCP Service Ports

</code> **DISCARD(1)                  END OF DOCUMENT** <code>
</code>
----
==== DNS ====
<code>DNS(1)                  XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        DNS -- Domain Name Server commands.

</code> **SYNOPSIS** <code>
        DNS {<A[dd] | D[rop]> <ipaddr>} | <C[ache]> | <L[ist>

</code> **DESCRIPTION** <code>
        The DNS commands are used to add and delete Domain Name 
        Servers from the DNS list, and to display the list or cache.

        Domain Name Servers are external TCP/IP hosts which are used 
        to resolve host names, for example "bbc.co.uk", into IP 
        addresses, when the information is not found locally in 
        DOMAIN.SYS.

        In order for XRouter to use this process, it needs to know
        the IP addresses of suitable DNS's.  These are usually
        specified in XROUTER.CFG.

        If no servers are specified, XRouter will use the domain
        resolution services provided by the operating system. 

        The "Split DNS" system used by XRouter allows private
        domains to be resolved using their own servers.

</code> **OPTIONS** <code>
        a) "DNS ADD <ipaddr> [domain]" adds the name server whose IP
           address is specified by <ipaddr> to the server list.

           The [domain] argument may be specified with or without a
           trailing dot.  e.g. ".ampr.org" or ".ampr.org.".

           If [domain] is specified, the name server will only be
           used to resolve hostnames in that domain, and the host
           names in that domain will only be resolved using that
           server and no others.

           For example: "DNS=44.131.91.245 .ampr.org." tells XRouter
           to exclusively use the server 44.131.91.245 to resolve all
           ampr.org hostnames.  That server will not be used to
           resolve hosts outside the ampr.org domain, and ampr.org
           will not be resolved using any other server.


        b) "DNS DROP <ipaddr>" deletes the nameserver specified by
           <ipaddr> from the server list.
 
        c) "DNS LIST" displays the list of domain name servers.

        d) "DNS CACHE" displays the contents of XRouter's domain
            cache.

</code> **EXAMPLES** <code>
        DNS ADD 44.131.91.245 .ampr.org.
        DNS ADD 62.31.117.22
        DNS DROP 44.131.88.73

</code> **FILES** <code>
        Domain servers are usually specified in XROUTER.CFG using
        one or more "DNS=<ipaddr> [domain]" directives.  Omit the
        directives to force the use of the operating system's DNS.

        Alternatively, the DNS ADD command may be used in
        BOOTCMDS.SYS. 

</code> **HISTORY** <code>
        This command, and the DNS server / client were necessary in
        DOS XRouter, but have less relevance in XRouter because the
        Operating System provides Domain Resolution services.

        However, the facilities were not deleted when the code was
        ported to XRouter, because it is conceivable that (a) someone
        might wish to use an external DNS via SLIP or PPP or RF
        because the OS has no Internet connection (Imagine a node
        on a remote site, with no internet connection), or (b) they
        may wish to act as a DNS for TCP/IP over radio.

</code> **NOTE** <code>
        If XRouter obtains its IP address via DHCP or PPP, it will 
        automatically obtain primary and secondary DNS addresses, and 
        remove them from the list when the lease terminates.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code>
----
==== DOS ====
<code>DOS(1)                  XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        DOS -- Enter PZTDOS command mode.

</code> **SYNOPSIS** <code>
        DOS

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The DOS command switches the command interpreter into "DOS 
        mode", allowing local and remote sysops to use familiar DOS 
        commands to maintain the system without taking it off line.

        In this mode, the normal command prompt is replaced by a DOS-
        style $P$G prompt showing the current drive and directory, and 
        only the PZTDOS commands are understood.

        The operator must use the EXIT command to return to normal 
        command mode.

        Sessions automatically return to command mode upon 
        disconnection. 

</code> **PORTABILITY** <code>
        PZTDOS accepts both the MSDOS backslash (\) and the UNIX 
        forward slash (/) pathname seperator characters, and they may 
        be freely mixed.  For the sake of clarity however, the prompt 
        always displays the path using the UNIX convention on Linux
        platforms, and the DOS convention on DOS/Windows platforms.

        As in MSDOS and UNIX, when specifying pathnames, a single dot 
        (.) represents the current directory, and a double dot 
        represents the parent directory.  Thus a command such as "CD 
        ../FRED" would change to directory FRED, which is located off 
        the current directory's parent.

        Unlike MSDOS, PZTDOS does not maintain a seperate "current 
        directory" on each drive, and you will be logged to the root 
        when changing drives.

        On DOS/Windows, the normal A: B: etc. commands can be used to
        change drive, and the CD (change directory) command can also
        accept a drive letter.

</code> **NOTES** <code>
        PZTDOS is fully multitasking, i.e. normal router operation 
        continues while PZTDOS mode is operating.

        PZTDOS commands are detailed in section 3 of the manual.

        PZTDOS is a vestige of a bygone age, where the OS would only
        support a single foreground application. Without PZTDOS, it
        would have been necessary either to "shell to DOS", or to
        stop XROUTER altogether, in order to perform file-system
        tasks. Nowadays, such tasks are easily performed on a multi-
        tasking OS, and PZTDOS has little relevance. It is included
        simply because it never got removed when XRouter was
        ported to Windows, thence to Linux. 

</code>
----
==== DUN ====
<code>DUN(1)                  XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        DUN -- Dial Up Networking configuration commands.

</code> **SYNOPSIS** <code>
        DUN A[dd] <callsign | ip_address> <script>
        DUN D[rop] <callsign | ip_address>
        DUN L[ist]
        DUN LO[g] [0-255]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        Dial-Up Networking (DUN) is a subsystem which allows Xrouter 
        to connect to other TCP/IP systems via a dial-up Public 
        Switched Telephone Network (PSTN) link.  The DUN commands 
        are used to configure this subsystem.

</code> **OPTIONS** <code>
        DUN ADD creates an association between a callsign (for KISS 
        links) or gateway IP address (for PPP or SLIP links) and a DUN 
        script.

        DUN DROP removes a previously created association between a 
        callsign or gateway IP address and a DUN script.

        DUN LIST lists the peers to whom a dial-up connection may be 
        established, and the names of the scripts used to make the 
        connections.

        DUN LOG sets the level of logging, for diagnostic purposes.  
        The argument is a flag field, comprising the sum of the 
        following values:

            1        Log starts, stops and errors.
            2        Log all script lines.
            4        Log responses from modem or host.

        A value of 0 disables all logging.  If no arguments are 
        supplied, the current logging level is reported.

</code> **EXAMPLES** <code>
        DUN ADD gb7tyr  gb7tyr.scr
        DUN ADD 62.31.176.22  pipex.scr
        DUN DROP 62.31.176.22
        DUN LOG 3

</code> **FILES** <code>
        The DUN ADD and DUN LOG commands may also be used in 
        IPROUTE.SYS and / or BOOTCMDS.SYS to set up the system at boot 
        time.

</code> **SEE ALSO** <code>
        DIAL(1)   -- Dial a PSTN connection.
        SCRIPT(9) -- Dialler script commands.
        DUN(9)    -- Dial-Up Networking.

</code>
----
==== DX ====
<code>DX(1)                   XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        DX -- Displays distant APRS stations.

</code> **SYNOPSIS** <code>
        DX [ port | node [port] ]

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The DX command displays a list of the most distant APRS
        stations heard by XRouter, along with their positions,
        distances and headings.

        Providing XRouter's position is defined (see below), APRS
        position reports heard by XRouter will be recorded in the
        DX list, in order of distance.

        The sysop may set this up (using the DXFLAGS keyword in 
        XROUTER.CFG) to show only the directly heard stations, or
        may choose to include those heard via digipeaters. He may
        also specify a minimum distance for table inclusion.

        If included, digipeated stations are clearly identifiable
        by an entry in the "Via" field, which is blank for directly
        heard stations.

</code> **OPTIONS** <code>
        When no argument is used, stations received on all ports are
        displayed.

        If an optional port number is supplied, only the stations
        received on that port will be shown

        if the first argument is the callsign or alias of a known
        node, the DX list of that node is requested, provided the
        target node is XRouter v502s or later. If the second argument
        is a port number, only the records for that port on the
        target node are requested

</code> **EXAMPLES** <code>
        DX           - Display all DX stations on this node
        DX 13        - Display DX from port 13 only.
        DX KIDDER    - Display all DX records on KIDDER node
        DX KIDDER 16 - Display DX records on KIDDER node's port 16

        G8PZT:KIDDER} Dx list:
        Prt Callsn Dist Dir  Date  Time Frm Position           Via
        9   GB7GH  62Km 170  22/08 10:59 72 5151.20N 00205.80W
        4   G6GUH  21Km 325  22/08 05:41  1 5233.38N 00225.80W
        1   G3KFD  13Km  36  21/08 17:38  5 5229.65N 00208.28W
        (End of list)

            Prt      - Port number
            Dist     - Distance in Kilometers
            Dir      - Heading in degrees
            Date     - Date & time of last reception
            Frm      - No. of frames seen
            Position - Latitude & longitude of station in APRS format
            Via      - Digipeater callsign (blank if heard direct)

</code> **FILES** <code>
        The DXFLAGS=n directive is used in XROUTER.CFG to control
        the DX list. The flags are made up as follows:

           1 - Record digipeated stations (defaults off).
           2 - Enable logging of DX exceeding specified distance.
           4 - Log frame contents of qualifying DX

        If logging is enabled Bits 3 - 14 specify the minimum
        distance which will be logged, from 4Km to 32764Km in 8Km
        steps, e.g. DXFLAGS=502 enables DX logging, with a threshold
        of 500Km. If logging is not enabled, bits 3-14 are ignored.

        If DX logging is enabled, any received APRS positions which
        exceed the threshold distance are logged to LOG/DXLOG.TXT.

        XRouter's position is defined in XROUTER.CFG, either by using
        LOCATOR (which gives a coarse position), or by including an
        APRS position string in the IDTEXT, for example:

        IDTEXT
        !5224.00N/00215.00W Kidderminster Router (KIDDER)
        ***

</code> **CAVEATS** <code>
        If XRouter's position has not been defined, no DX information
        will be available

</code> **SEE ALSO** <code>
        AMSG(1)    -- APRS messaging shell
        DXFLAGS(7) -- DX List Control Flags

</code> **DX(1)                    END OF DOCUMENT** <code>
</code>
----
==== ECHO ====
<code>ECHO(1)                 XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        ECHO -- Start an Echo session.

</code> **SYNOPSIS** <code>
         EC[ho] [nodecall | nodealias]

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The ECHO command starts a "echo" session, whereby anything 
        received by XRouter is echoed back to the sender. This is
        useful for testing TNC's, link throughputs etc.

        Entering ECHO without any arguments starts an echo session
        on this XRouter.

        If the optional argument is a nodecall or alias, and that
        node is in the nodes table, XRouter connects to the echo
        service on the specified node. This only works if the target
        node is also an XRouter at present.

        An ECHO session can only be ended by sending "/x" or by
        disconnection.

</code> **NOTE** <code>
        The ECHO server is also available on NetRomX service 7, and
        by telnetting to TCP port 7 (This port may be altered or
        disabled using the ECHOPORT directive in XROUTER.CFG).

</code> **SEE ALSO** <code>
        DISCARD(1)  -- Start a sink session
        ECHOPORT(7) -- Specify TCP port for ECHO server
        ECHO-SRV(9) -- ECHO Server.

</code> **ECHO(1)                    END OF DOCUMENT** <code>
</code>
----
==== EXCLUDE ====
<code>EXCLUDE(1)             XROUTER REFERENCE MANUAL              20/9/2023

</code> **COMMAND** <code>
        EXCLUDE -- Prevent connections from a callsign.

</code> **SYNOPSIS** <code>
        EXC[lude] <port> [call[,call..] | clear | none]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The EXCLUDE command is used to manage AX25 level 2
        exclusions, i.e. callsigns that are blocked from connecting
        to the node using AX25.

        Exclusions can apply on a port-by-port basis, or globally.

        They can be added at boot-time using the EXCLUDE directive
        in XROUTER.CFG, or during run-time using the EXCLUDE command.

        The command can be used multiple times, to add one or more
        callsigns at a time. Callsigns are appended to the list, if
        they are not already in the list.


</code> **OPTIONS** <code>
        "EXC[lude] <port>" displays the exclusion list for <port>.

        If <port> is 0, the command applies globally, i.e. to all
        ports. To avoid confusion, global exclusions are not shown
        in port exclusion lists.

        "EXC[lude] <port> <callsign>" adds <callsign> to the list of
        stations prevented from connecting on <port>.

        Multiple callsigns may be added in this way, by adding them
        as a comma separated list, like so:

        "EXC[lude] <port> <callsign>,<callsign>,<callsign>..."

        "EXC[lude] <port> NONE" and  "EXC[clude] <port> CLEAR" can be
        used interchangeably, and they both clear the list.



        There is as yet no way to remove a single callsign, other
        than remove them all and reinstate the wanted ones. If anyone
        needs this, please request it.

</code> **EXAMPLES** <code>
        exclude 0 g9mtt                 Exclude G9MTT globally

        exclude 4                       Display list for port 4

        exclude 4 gd7dr                 Add GD7DR

        exclude 5 g8pzt,g2bof.fred      Add 3 calls

        exclude 5 none                  Delete all calls

        exclude 4 clear                 Delete all calls

    
</code> **SEE ALSO** <code>
        EXCLUDE(7)     -- AX25 L2 exclusion directive
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== EXIT ====
<code>EXIT(1)                XROUTER REFERENCE MANUAL               6/9/2023
</code> **COMMAND** <code>
        EXIT -- Exit XRouter (terminate the program)

</code> **SYNOPSIS** <code>
        EXIT <0-255>

</code> **AVAILABILITY** <code>
        The EXIT command is available only to sysops.

</code> **DESCRIPTION** <code>
        The EXIT command terminates XRouter. The numeric argument is
        returned to the calling program, allowing different actions
        to be taken depending on the value.

</code> **SEE ALSO** <code>
        EXIT(3) -- Leave PZTDOS mode.

</code>
----
==== FEC ====
<code>FEC(1)                  XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        FEC -- Control Forward Error Correction.

</code> **SYNOPSIS** <code>
        FEC <port> [0-255]

</code> **DESCRIPTION** <code>
        The FEC command allows you to display and set the Reed
        Solomon Forward Error Correction properties for a port.
        At present, the only property which can be controlled is
        FEC on/off.

        Forward error correction is useful on links with high BER
        (bit-error-rates). Up to 8 erroneous bytes per frame may be
        automatically corrected, at the expense slightly larger
        frames. FEC is not required on links with very low BER.

        In order to make use of FEC, the port needs to be using a
        KISS TNC with the CRC check disabled, or an SCC or YAM card.

</code> **OPTIONS** <code>
        The first argument is a port number, and is required. If not
        supplied, a syntax reminder is displayed.

        The second argument is optional. If supplied, the FEC flags
        for the specified port are set to the numeric value of the
        argument. If not supplied, the current value is reported.

        A zero value turns FEC off, and a non-zero value turns it on.

</code> **EXAMPLES** <code>
        FEC 1   - Display current FEC setting for port 1.
        FEC 1 0 - Turn off FEC on port 1

</code> **NOTES** <code>
        A suitable KISS ROM image for use with FEC is KISSFEC.BIN,
        which should be provided in the XRouter release package. Note
        that this ROM is for use only with XRouter, and only for FEC.

        The FEC flag may be changed in future to allow it to be
        enabled on TX, RX, both or neither.  This would allow one
        way FEC, e.g. for use in the case where a link is bad in one
        direction but good in another. Other flags may be used to
        control parameters such as interleaving.

</code> **FILES** <code>
        FEC is normally disabled by default, and is enabled by
        including the FEC=1 directive in the appropriate PORT
        configuration block in XROUTER.CFG. It can then be turned
        on and off at will from the command line.

        If FEC is used, the "allow L2 fragmentation" bit must be set
        in the port CFLAGS, to allow XRouter to fragment large Netrom
        L3 frames which might otherwise exceed the reduced L2 Paclen.

</code> **CAVEATS** <code>
        Frames containing FEC look like garbage to "normal" AX25
        systems. Thus in order to use FEC on a link, BOTH ends of
        the link must be FEC-capable.

        Stations who are not running FEC may interpret FEC-encoded
        frames incorrectly, leading either to a failure to decode
        or possibly to corrupt node broadcasts or inaccurate APRS
        positioning. Therefore FEC should not be used on a shared
        channel

</code> **AVAILABILITY** <code>
        Sysops-only.

</code> **SEE ALSO** <code>
        CFLAGS(7)      -- Connection Control Flags.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FINGER ====
<code>FINGER(1)               XROUTER REFERENCE MANUAL             27/9/2023

</code> **COMMAND** <code>
        FINGER -- Display information about users.

</code> **SYNOPSIS** <code>
        FINGER <user | user@host | @host>

</code> **AVAILABILITY** <code>
        The command is available to all users.

</code> **DESCRIPTION** <code>
        If the command is of the form "FINGER <user>", the router 
        searches the FINGER subdirectory for a text file which matches 
        "user", and sends the contents of that file if it exists.  The 
        file may contain anything you like, and "user" may be a 
        callsign, nickname or other form of hostname consisting of up 
        to 8 legal DOS characters

        If the form "user@host" or "@host" is used, the router will 
        attempt to resolve "host" into an IP address and establish a 
        TCP/IP contact with the finger server on that host.

</code> **EXAMPLES** <code>
        FINGER g8pzt          - Info on local user g8pzt
        FINGER g8jvm@iptlfd   - Info on user of another system

</code> **LIMITATIONS** <code>
        This feature is very rudimentary at present, requiring the 
        user account files to be created by the sysop.

</code> **SEE ALSO** <code>
        FING-SRV(9)   -- Finger Server.
        FINGERPORT(7) -- TCP Port for Finger Server.

</code>
----
==== FRACK ====
<code>FRACK(1)                XROUTER REFERENCE MANUAL             24/9/2023
</code> **COMMAND** <code>
        FRACK -- Display / Set FRACK for a port.

</code> **SYNOPSIS** <code>
        FRACK <port> [msec]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        Displays the current FRACK (AX25 level 2 T1 timer) setting for 
        the specified port, or allows it to be changed.

        If the second argument is ommitted, the current value is 
        displayed, otherwise the value in millseconds is used.

        The new setting overrides the value specified in the CFG file, 
        and remains in force until changed or the next restart.

</code> **EXAMPLES** <code>
        FRACK 2          - Display port 2 frack setting
        FRACK 2 6000     - Set port 2 frack to 6 seconds

</code> **NOTES** <code>
        A typical FRACK setting for 1200 baud is 7000 (7 secs), and 
        specifies how long AX25 will wait for a level 2 ack before 
        requesting confirmation.  Setting this figure too low is 
        antisocial, achieves nothing, and could result in the link 
        retrying out.

        However, on AXUDP links 7 secs is excessive, and a figure
        more like 2000 (2 secs) should be used.

        FRACK=n may be used within PORT definition blocks in
        XROUTER.CFG to specify the default setting for a port.

</code> **SEE ALSO** <code>
        FRACK(7) -- Frame Acknowledgement Time.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FTP-CMDS ====
<code>FTP-CMDS(1)             XROUTER REFERENCE MANUAL            16/10/2023
</code> **NAME** <code>
        FTP-CMDS -- FTP Server Commands.

</code> **DESCRIPTION** <code>
        XRouter's FTP server currently accepts the following commands:


           ABOR   CDUP   CWD    DELE   FEAT   HELP   LIST   MDTM
           MFMT   MKD    MODE   NLST   NOOP   PASS   PASV   PORT
           PWD    QUIT   REST   RETR   RMD    RNFR   RNTO   SIZE
           STOR   STRU   SYST   TYPE   USER


        All commands are case-insensitive, thus "cwd", "CWD" and
        "cWd" are equally valid. Pathnames are case-insensitive on
        DOS and Windows versions of XRouter, but are case-sensitive
        on Linux versions (XRLin / XRPi).

        Both UNIX style (e.g. /pub/fred) and DOS style (e.g.
        \pub\fred) pathname conventions are accepted.

        Disk drive letters (e.g. "C:") apply only to XR16 and XR32,
        but not to Linux versions.

        Unlike DOS, the server does not maintain separate "working
        directories" for each drive, so pathnames which include a
        drive letter must start at the root of that drive.  e.g.
        "c:mydir\fred.txt" is not valid, while "c:\mydir\fred.txt" is.

        The FTP commands are described in detail below:


        ABOR -- Abort data connection.

            Syntax: ABOR

            The ABOR command tells the server to abort any data
            transfer currently in progress and close the data
            connection.  The control connection is not closed.

            If the data connection is not open, this command has
            no effect.


        CDUP -- Change Directory Up By One Level

            Syntax:  CDUP

            The CDUP command changes the current working directory
            up one level to the parent directory, i.e. it performs
            the function of "CWD .."

            This command has no arguments, and if already at the
            root it has no effect.


        CWD  -- Change Working Directory

            Syntax:  CWD [drive:\]<path>

            The CWD command changes the current working directory
            (and drive if necessary) for the FTP session.

            Examples:

                CWD FRED        Change to sub-directory FRED.
                CWD ..          Change up one level to parent dir.
                CWD /           Change to root directory
                CWD /FRED/JIM   Change to JIM subdirectory of FRED.


        DELE -- Delete file(s).

            Syntax:  DELE [drive:\][dir\]<mask>

            Examples:

                DELE JIM.TXT         Delete JIM.TXT from current dir.
                DELE /FRED/DOG.EXE   Delete DOG.EXE from dir. /FRED
                DELE *.BAT           Delete files with .BAT extension.

            Notes:  Wildcards '*' and '?' are accepted.


        FEAT -- Feature negotiation mechanism.

            Syntax:  FEAT

            The FEAT command requests the server to list all extension
            commands, or extended mechanisms, that it supports. 

 
        HELP -- Display help for FTP server commands.

            Syntax:  HELP [command]

            Examples:  HELP        Displays basic info / cmd list.
                       HELP CWD    Gives help for the CWD command.

            Some FTP clients may intercept the HELP command to
            give help on client commands.  In this case, the
            REMOTEHELP command, if it is implemented should
            translate to a server HELP command. If not, the client
            may have a command which passes commands "RAW" to the
            server.  If all else fails, TELNET to port 21 and the
            HELP command will work.


        LIST -- lists FTP server directory contents.

            Syntax:  LIST [drive:\][dir\][mask]

            The LIST command causes a directory listing to be sent
            from the FTP server to the client over the data
            connection.  If the data connection cannot be
            established, the command will fail.

            The optional argument consists of a directory path and 
            filename mask.  If no path is specified, the current 
            directory is assumed.  If no mask is specified, "*"
            (all files) is assumed.  Wildcards '*' and '?' are
            accepted. 

            Examples:
                LIST              Show all files in current directory
                LIST C:\PUB       Show all files in PUB subdir of C:
                LIST /USR/*.EXE   Show all .exe files in /USR dir.

            See also:  NLST -- List names only


        MDTM -- Enquire file modification date and time.

            Syntax:  MDTM [drive:\][dir\]<filename>

            The MDTM command is used to obtain the "last modifed"
            date and time of the specified file.

            Examples:  MDTM XROUTER.CFG
                       MDTM C:\MyDocs\plans.txt


        MFMT -- Modify the last modification time of a file. 

            Syntax:  MFMT <timeval> [drive:\][dir\]<filename>

            Example:  MFMT 20020717210715 Fred.txt
                      (sets file date/time to 17/7/2002 21:07:15)


        MKD  -- Make new directory.

            Syntax:  MKD [drive:\]<pathname>

            The MKD command creates a new directory of the
            specified name.  If pathname is not fully qualified,
            the new directory is created within the current
            working directory.

            Examples:  MKD FRED
                       MKD C:/JIM/BILL

            See also:  RMD -- Remove directory


        MODE -- Specifies the data transfer mode.

            Syntax:  MODE <mode_code>

            MODE specifies how the data is to be formatted and 
            transferred via the data connection.  Mode codes are
            as follows:

                B - Block         Data is sent in blocks
                C - Compressed    Data is compressed
                S - Stream        Data sent as stream of characters

            The default transfer mode, which is the only one
            currently implemented, is Stream.  The command is
            included to prevent unnecessary error replies.

            Examples:  MODE S   Sets (S)tream transfer mode.


        NLST -- Lists directory contents in short form.

            Syntax:  NLST [<filespec>]

            The NLST (Name List) command causes a directory
            listing to be sent from the FTP server to the client
            over the data connection.  If the data connection
            cannot be established, the command will fail.

            The optional argument consists of a directory path and 
            filename mask.  If no path is specified, the current
            directory is assumed.  If no mask is specified, "*"
            (all files) is assumed.  Wildcards '*' and '?' are
            accepted. 

            The listing consists of filenames only, without size,
            date and other supplementary information.

            Examples:  NLST
                       NLST K:\PUB
                       NLST /USR/*.EXE

            See also:  LIST -- List directory contents


        NOOP -- (NO OPeration) does nothing. 

            Syntax:  NOOP

            The NOOP command does not affect anything, and its
            only action is to cause the server to send an "OK"
            reply.  It is perhaps useful for testing that the
            control connection is still functioning.


        PASS -- Specifies user password at login.

            Syntax:  PASS <password>

            The argument to the PASS command is either a string of
            up to 5 characters in response to the secure password
            challenge or, for use on secure links only, the
            password itself.  The string may not contain spaces.

            The command must be immediately preceded by the USER
            command, which causes the system to reply with a
            matrix consisting of 5 lines of 5 numbers thus:

                4 1 6 3 7
                3 5 2 6 3
                7 1 9 2 4
                2 7 1 4 6
                3 5 2 6 1

            The remote sysop must then choose ONE of the lines,
            and send the PASS command followed by the 5 characters
            from the password string which correspond to the 5
            numbers on the chosen line.  There must be a space
            after PASS but no spaces between the characters.

            Examples:  PASS RETAW        <-- Matrix response
                       PASS squirrels    <-- Raw password

            If the sysop has connected on a port which has SYSOP=1
            in the config file (e.g. a secure wire link), the
            response to this command is ignored, and the sysop is
            granted full access.

            See also:  USER -- Specify your username.


        PASV  -- Use "passive" transfer mode.

            Syntax:  PASV

            Normal FTP relies on the server being able to initiate
            a data connection to TCP port 20 on the client host.
            This method may however not work if the client is
            located "behind" a firewall or connection multiplexer.

            Passive mode opens a data connection on the server,
            informs the client of the IP address and port number,
            and waits for the client to connect to it.  It can
            therefore work via firewalls.


        PORT -- Specifies IP address and port for the data connection.

            Syntax:  PORT h1,h2,h3,h4,p1,p2

            The PORT command specifies the IP address and TCP port
            number to be used by the data connection.  The
            argument is the concatenation of a 32 bit IP address
            and a 16 bit TCP port number, split into 8 bit fields,
            each field being transmitted as a decimal number.  The
            fields are separated by commas, and the high order
            fields are transmitted first.

            Example:  PORT 44,131,91,2,4,1
                      Specifies IP address 44.131.91.2 and TCP
                      port number 0401 (1001 decimal)

            Under normal circumstances this command is not needed.
            The data connection defaults to TCP port 20 at the
            client's IP address of the control connection.
            However, it allows data to be sent to a different host
            if required.


        PWD  -- Print Working Directory.

            Syntax:  PWD

            The PWD command causes the full path of the user's
            current working directory to be displayed via the
            control connection.

            See also: CWD -- Change Working Directory


        QUIT -- Terminates an FTP session.  

            Syntax:  QUIT

            If a file transfer is not in progress, the QUIT
            command terminates the FTP session and closes the
            control connection.

            If file transfer is in progress, the control
            connection will remain open until transfer is
            complete, allowing the result code to be sent.  The
            control and data connections will then close.

            An unexpected close on the control connection will
            abort any data transfer currently in progress.

            See also:  ABOR -- Abort current command.


        REST -- Restart of Interrupted Transfer.

            Syntax:  REST <offset>

            The REST command specifies an offset from which a file
            transfer should be resumed. The REST command does not
            actually initiate the transfer. After issuing a REST
            command, the client must send the appropriate FTP command
            to transfer the file. The server resumes file transfer at
            the specified offset.

            Example: REST 32740

            NOTE: At present this only works for BINARY transfer mode!


        RETR -- Retrieve (download) file.

            Syntax:  RETR [drive:\][dir\]<filename>


            The RETR command causes the named file to be sent from
            the FTP server to the client over the data connection.
            If the file can't be found, or access is denied, or
            the data connection can't be opened, an appropriate
            error message is returned.

            Examples:  RETR JIM.TXT
                       RETR ../FRED/DOG.EXE
                       RETR C:\CONFIG.SYS

            Notes:  Single files only, wildcards not accepted.

            See also:  PORT -- Host/port for data connection.
                       STOR -- Send a file to the server.


        STOR -- Store (upload) file.

            Syntax:  STOR [drive:\][dir\]<filename>

            The STOR command requests the FTP server to accept
            data via the data connection and store it as a file
            with the specified name.

            If the file specified in the pathname already exists
            at the server, it is overwritten by the new data.  The
            overwrite doesn't take place until the file has been
            correctly received, which prevents a critical file
            being lost if the data connection fails. 

            Examples:  STOR JIM.TXT
                       STOR /FRED/DOG.EXE

            See also:  RETR -- Retrieve a file from the server.


        RMD  -- Remove Directory.

            Syntax:  RMD [drive:\]<pathname>

            The RMD command deletes the directory specified by
            <pathname> from the FTP server, providing you are the
            owner of that directory and have write access.

            Examples: RMD FRED
                      RMD K:/JIM/BILL

            See also: MKD -- Make directory


        RNFR -- Rename From

            Syntax:  RNFR [drive:\][dir\]<filename>

            The RNFR command specifies the old pathname of a file
            which is to be renamed, and must be immediately
            followed by an RNTO command.  The two commands
            together cause a file to be renamed.  If the file is
            not found the request is refused.

            Examples: RNFR ../JIM.TXT
                      RNFR K:/FRED/DOG.EXE

            See also:  RNTO -- Rename To


        RNTO -- Rename To

            Syntax:  RNTO [drive:\][dir\]<filename>

            The RNTO command specifies the new pathname of a file
            which is being renamed, and must immediately follow an
            RNFR command.  The two commands together cause a file
            to be renamed.

            If the new pathname isn't valid, the request is refused.

            Examples:  RNTO DOG.TXT
                       RNTO K:/FRED/CAT.EXE

            See also:  RNFR -- Rename From.


        SIZE -- Enquire Size of File.

            Syntax:  SIZE [drive:\][dir\]<filename>

            The SIZE command returns the transfer size of the file
            whose pathname was supplied, or an error response if the
            file does not exist, the size is unavailable, or some
            other error has occurred.  The value returned is in a
            format suitable for use with the RESTART (REST) command
            for mode STREAM, provided the transfer mode and type are
            not altered.


        STRU -- Specify File Structure.

            Syntax:  STRU <structure_code>

            STRU specifies the internal structure of the files
            being transferred, i.e.  how the data is organised
            within them.  Structure codes are as follows:

                F - File       No record structure (contiguous bytes)
                R - Record     Collection of sequential records
                P - Page       File is composed of independent pages

            The default structure, which is the only one currently
            implemented, is (F)ile.  The command is included to
            prevent unnecessary error replies.

            Example:  STRU F   Sets (F)ile structure.


        SYST -- Operating system enquiry.

            Syntax:  SYST

            The SYST command is used to discover what type of
            operating system is being used on the server.

            The first word of the reply is one of the agreed
            system names, in this case Windows NT. The rest of the
            reply gives the server version number and byte size.


        TYPE -- Specifies the data representation type.

            Syntax:  TYPE <type_code>

            The argument to the TYPE command specifies how the
            data is to be translated between storage and transfer.
            Type codes are as follows:

                A - ASCII      Text.  End of line is <CR><LF>   
                I - Image      No translation.  Bytes stored as rcvd.
                L <bytesize>   Size of local storage bytes

            Examples:  TYPE A    Specifies Ascii type.
                       TYPE L 8  Local byte size of 8 bits


        USER -- Specify user name for login.

            Syntax:  USER <username>

            The argument to the USER command is a string of up to
            8 characters specifying the user's login name
            (usually callsign).  The string must not contain
            spaces.

            Users are not allowed access to the system without
            logging in.

            If the username (or callsign) exists in the
            PASSWORD.SYS file the server sends a grid of 5x5
            numbers (see PASS command) generated from the user's
            stored password.  If the username is not found, an
            error message is sent instead, and access is denied.

            The USER command must be immediately followed by the
            PASS command.

            Example:  USER SYSOP   Enters login name as "SYSOP"
                      USER G8PZT   Use callsign


            Note: Because the FTP server allows you to use any
            string of characters as a name, you may set up
            different passwords for different login names, and
            these may be in addition to your callsign, which is
            the one used for ax25 sysop access.

            See also:  PASS -- Specify password.


</code> **SEE ALSO** <code>
        FTP-SRV(9) -- FTP Server.

</code>
----
==== FTP ====
<code>FTP(1)                 XROUTER REFERENCE MANUAL               8/9/2023
</code> **COMMAND** <code>
        FTP -- Invoke FTP Client.

</code> **SYNOPSIS** <code>
        FT[p] [hostname | ipaddr | nickname]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The FTP command invokes an inbuilt FTP (File Transfer
        Protocol) client. This client is part of XRouter, and has
        nothing to do with the host operating system.

        The client currently has 67 commands, all of which have brief
        help and syntax. Commands may be abbreviated. The command
        list is as follows:

          ?           <           abort       account     append
          ascii       bell        binary      bye         case
          cd          cdup        close       dir         delete
          get         hash        help        idle        keep
          lcd         ldel        ldir        ls          list
          lmkdir      lpwd        lrmdir      lren        lview
          mdelete     mget        mkdir       modtime     mput
          newer       nlist       open        passive     preserve
          progress    prompt      put         pwd         quit
          quote       reset       restart     recv        reget
          rename      rhelp       rmdir       rstatus     runique
          send        site        size        sndport     status
          sunique     system      timeout     type        user
          verbose     view

        Use "? <cmd>" for specific help on <cmd>, for example:

            ? ldir
            LDIR    List files in local directory
            Syntax: LDI[r] [local-path]

        The Q)uit command returns you to the node.

</code> **OPTIONS** <code>
        Typing "FTP" by itself, with no arguments, starts the client,
        but doesn't connect to a server. Local commands such as LDIR
        LCD etc can be performed. A connection can be initiated using
        the OPEN command.

        If the argument to "FTP" or "OPEN" is a hostname or IP
        address, the client connects to the standard TCP port (21)
        on that target.

        If the target server isn't on TCP port 21, the port number
        can be specified using a second argument, e.g.

            FTP 192.168.1.203 31

        Commonly-used targets can be given a "nickname", to simplify
        the connection process. Nicknames are specified in
        FTPCLI.SYS, along with connection details allowing automated
        login.

</code> **EXAMPLES** <code>
        FTP                   -- Start FTP without connect to server
        FTP 192.168.1.3       -- Connect to 192.168.1.3 tcp port 21
        FTP g8pzt.ath.cx 2521 -- Connect to g8pzt.ath.cx port 2521
        FTP gb7kr             -- Automated connect, account "gb7kr"

</code> **NOTES       ** <code>
        Some may wonder why XRouter includes an FTP client, when
        Linux already has one?

        One good reason is that it allows FTP over Amprnet, which is
        something that's not easy to set up in Linux itself.

        Secondly, I had a need for it. I won't elaborate why, just
        to say it has proved very useful to me. It might even prove
        useful to you. If not, just ignore it!

</code> **SEE ALSO** <code>
       FTP-SRV(9)      -- FTP Server.
       FTPCLI.SYS(8)   -- FTP Client Account File.
       NFTP(1)         -- NetRom File Transfer Protocol Client.

</code>
----
==== FULLDUP ====
<code>FULLDUP(1)              XROUTER REFERENCE MANUAL             24/9/2023
</code> **COMMAND** <code>
        FULLDUP -- Display / Set full duplex mode.

</code> **SYNOPSIS** <code>
        FULLDUP <port> [0 | 1]

</code> **AVAILABILITY** <code>
        SYSOP-only.

</code> **DESCRIPTION** <code>
        Displays the current duplex setting for a port, and allows it 
        to be changed without restarting the system.  If port is 
        operating in full duplex mode, DCD is ignored and the hardware 
        will transmit whenever it has anything to send.

        If two numeric arguments are supplied, the duplex flag is set 
        to the second argument, otherwise the current setting for the 
        specified port is displayed.  Values are: 0 - simplex, 1 - 
        full duplex.

        Modified settings remain in force until changed or system is 
        restarted.

</code> **EXAMPLE** <code>
        FULLDUP 3        - Display current setting for port 3
        FULLDUP 3 1      - Set port 3 into full duplex mode

</code> **NOTE** <code>
        On KISS ports, allow up to 5 minutes for modified settings to 
        reach the TNC.

        This parameter has meaning only on KISS TNCs, SCC cards, and
        YAM modems.

        FULLDUP=n may be used within PORT definition blocks in
        XROUTER.CFG to specify the default setting for a port.

</code> **SEE ALSO** <code>
        FULLDUP(7)     -- Set full duplex mode.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== GNET ====
<code>GNET(1)                 XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        GNET -- Display / Set GNET parameters.

</code> **SYNOPSIS** <code>
        G[net] A[ddress] [addr]
        G[net] R[oute] A[dd] <gnetaddr>[/bits] <nodecall>
        G[net] R[oute] D[rop] <gnetaddr> <bits>
        G[net] R[oute] L[ist]
        G[net] T[tl] [1-255]

</code> **AVAILABILITY** <code>
        Sysops-only.

</code> **DESCRIPTION** <code>
        The GNET commands allow sysops to display and set the GNET
        parameters such as address and routing.

        GNET is an experimental global network, which uses ip-like
        addressing and routing to tunnel traffic across the NetRom
        network, unrestricted by NetRom horizons.
  
        Not only does GNET offer global routing between all users,
        but it also offers up to 65536 possible session types
        between those users. 
 
</code> **OPTIONS** <code>
        "GNET ADDRESS" is used to display or set the XRouter's GNET
        address. See NOTES below for details of address format.
        The GNET address defaults to 0.0.0.0 which disables all GNET
        activity.

        "GNET ROUTE ADD" is used to add a route to the GNET routing
        table. The first argument is the address to be routed, with
        optional mask. e.g. 131.90.1.2/32 means "match all 32 bits",
        whereas 131.90.1.0/24 means "match the most significant 24
        bits", and would route all 256 addresses from 131.90.1.0 to 
        131.90.1.255. The second argument <nodecall>, is the NetRom
        callsign of the GNET gateway to which the addresses should
        be routed.

        "GNET ROUTE DROP" removes a routing entry from the GNET
        routes table. The arguments are the GNET address and mask.

        "GNET ROUTE LIST" lists all the GNET routes in the table.

        "GNET TTL" sets the "Time To Live", i.e. the maximum number
        of hops a packet is allowed to make. A low TTL helps to
        suppress bouncing packets in the event of a routing loop.
        The default is 25

</code> **EXAMPLES** <code>
        GNET ADDR 147.22.14.2
        GNET ROUTE ADD 131.91.2.0/24 G8PZT
        GNET ROUTE DROP 131.91.2.0 24
        GNET TTL 15

</code> **FILES** <code>
        There is no provision in XROUTER.CFG for spcifying the GNET
        address and routing, but this can be achieved by using the
        GNET commands in BOOTCMDS.SYS.

</code> **NOTES** <code>
        GNET addressing is based on numeric country and region codes
        and the addresses look like IP addresses, although this
        protocol does not involve IP at all.

        Addresses are of the form <country>.<region>.<router>.<user>
        allowing up to 255 countries, 255 regions per country, 255
        routers per region and 255 users per router. But this is not
        rigid; Each country may assign the regions as it sees fit.

        Country codes are the same as the ones used for amprnet,
        e.g. 131 is the UK, 147 is New Zealand etc. Region codes can
        be the same as the amprnet regions. Router codes can be
        assigned by local agreement, and user codes are assigned by
        the router sysops.

</code> **HISTORY** <code>
        GNET was invented in 2002 by G8PZT, and was implemented in
        XRouter. The development name adopted for the system was
        "GlobalNet", because it was a global networking system!
        However, it later transpired that the name was being used
        by an ISP, so the shorter name "GNET" (pronounced "jee-net")
        was adopted to avoid confusion.

        The system showed great promise, but never took off because
        there was no sysop documentation, and interest in DOS
        XRouter was waning as more people wanted to run their
        systems on Windows. The author's attention turned to more
        urgent matters, and no more development was done. There was
        so much more that could have been done.

        The GNET protocol and commands were retained when XRouter
        was ported from DOS to Windows and thence to Linux.
        Development may resume in future. In the meantime, sysops
        are encouraged to experiment with this mode.

</code> **LIMITATIONS** <code>
        There is currently no mechanism for resolving user callsigns
        to GNET addresses. This is a vital part of the system, which
        will be the next component to be added.
        
</code> **CAVEATS** <code>
        GNET relies on the NetRom network to provide links between
        its gateways. In order to route GNET traffic to a gateway,
        that gateway must be present in your node table

</code> **SEE ALSO** <code>
        GPING(1)    -- Send GNET Echo Requests
        IP-CODES(9) -- IP Country Codes

</code>
----
==== GPING ====
<code>GPING(1)                XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        GPING -- Send GNET Echo Request.

</code> **SYNOPSIS** <code>
        GP[ing] <addr> [len [sec]]

</code> **AVAILABILITY** <code>
        All users, except guests.

</code> **DESCRIPTION** <code>
        Sends GCMP (GlobalNet Control Message Prototcol) echo
        request(s) to the specified GNET (GlobalNet) address, for
        the purposes of route testing.

        An optional data portion may be specified, and the echo
        request may optionally be repeated at a specified interval.

        If there is a reply it will be displayed. For repeating pings 
        the system displays the number sent/rcvd, the average round 
        trip time in milliseconds, and the success rate.  The "wait 
        for reply" process may be cancelled at any time by entering 
        <CR> by itself.

</code> **OPTIONS** <code>
        <addr> is the GNET address of the target.

        [len] specifies the number of additional data bytes to send
              in the request packet. Default is 0.

        [sec] is the interval between requests. If present, this
              causes the ping to repeat every [sec] seconds. This
              field requires the [len] field to be present.       

</code> **EXAMPLES** <code>
        GPING 131.91.2.1           Single ping of minimum size
        GPING 131.91.2.1 50        Single ping with 50 bytes data
        GPING 131.91.2.1 512 10    Ping 512 bytes every 10 secs

</code> **NOTES** <code>
        See the MAN page for GNET(1) for more information about GNET.

</code> **CAVEATS** <code>
        In order for this command to work, XRouter's GNET address must
        be defined, and there must be a route to the destination.

        If XRouter's GNET address isn't defined, the response will be
        "Error 5 (bad configuration)", and if no route is defined
        the response is "Error 4 (no route)".

        If no response is received, the target doesn't exist, or the
        downstream routing is faulty, or there is no return route
        defined.

</code> **SEE ALSO** <code>
        GNET(1) -- GNET Configuration Commands

</code>
----
==== HELP ====
<code>HELP(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        HELP -- Displays help for commands and other topics

</code> **SYNOPSIS** <code>
        HELP [cmd | topic]

</code> **AVAILABILITY** <code>
        The HELP command is available to all users.

</code> **DESCRIPTION** <code>
        If no arguments are given, a short text gives directions on 
        how to access help.

        If the argument is a topic or a command name, the contents of 
        the appropriate file in the HELP subdirectory are displayed.

        The argument "*" lists all the help topics available.

        The minimum abbreviation for this command is "H".

</code> **EXAMPLES** <code>
        H *      - List available help topics.
        H PING   - Gives help for PING command.

</code> **LIMITATIONS** <code>
        The command or topic name must at present be given in full, 
        thus "H NODES" is acceptable, but "H N" is not (unless you 
        duplicate the NODES.HLP file to N.HLP).  Future versions will 
        search for the closest match.

        Topic names were originally restricted to 8 characters
        because in order to be a legal DOS filename. Thus some help
        files have names that are shorter than the command name.

</code> **NOTES** <code>
        The help available using the HELP command is intended to be of 
        use to both sysops and users alike, and is kept brief in order 
        to avoid wasting airtime.  The MAN system gives more detailed 
        information for sysops.

        The sysop may customise the help files, or add his/her own 
        help topics to the HELP directory as required.  The HELP 
        directory is located beneath the router's working directory, 
        and the files are simply plain text files with the .HLP 
        extension.  Files without the .HLP extension will not be 
        listed or accessible.

</code> **SEE ALSO** <code>
        HELP(9) -- Help System.
        INFO(1) -- Information System.
        MAN(1)  -- Sysops Manual.

</code>
----
==== HOST ====
<code>HOST(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        HOST -- Display information about a TCP/IP host

</code> **SYNOPSIS** <code>
        HO[st] <hostname> | <ip address>

</code> **DESCRIPTION** <code>
        The HOST command displays all known information about the 
        specified TCP/IP host.

        It would typically be used to find the IP address, given the 
        hostname, or vice versa.

</code> **OPTIONS** <code>
        The argument may be either a host name or an IP address.
        Hostnames not containing at least one dot (.) are first
        expanded by appending the domain suffix, as specified in
        XROUTER.CFG (default .ampr.org.)

</code> **EXAMPLE** <code>
        ho kidder

        G8PZT:KIDDER} Host name information for kidder:
        Hostname: kidder.ampr.org.
        Address:  44.131.91.245

</code> **FILES** <code>
        The HOST command uses information from DOMAIN.SYS.
        If domain resolution is to be performed by an external DNS
        instead of by Windows/Linux that DNS must be specified using
        the DNS=<ipaddr> directive in XROUTER.CFG.

</code> **AVAILABILITY** <code>
        All users.

</code> **LIMITATIONS** <code>
        The returned information is limited in scope at present. It
        will be expanded in a future version.

        In order to work properly, the HOST command requires either
        a populated DOMAIN.SYS, or access to a Domain Name Server,
        either directly, or via Windows / Linux.

</code>
----
==== IDPATH ====
<code>IDPATH(1)               XROUTER REFERENCE MANUAL             24/9/2023
</code> **COMMAND** <code>
        IDPATH -- Display / Set destination path for ID beacons.

</code> **SYNOPSIS** <code>
        IDP[ath] <port> [path]

</code> **AVAILABILITY** <code>
        Sysop only.

</code> **DESCRIPTION** <code>
        Displays or modifies the destination callsign, and digipeater
        path for the regular AX25 "ID" beacons.  The default setting
        is "ID" with no digipeaters.  You may wish to modify this,
        for example on APRS ports, to digipeat your beacon.

        If "path" is not specified, the current path (i.e.
        destination and digipeater callsigns) is displayed.

        If "path" is specified, the IDPATH parameter for the
        specified port is changed to the new value.

        The "path" argument should be supplied in the form

            <destcall>[,digicall,digicall,...]

        where <destcall> is the destination (i.e. "to") callsign,
        and [digicall] are optional digipeater callsigns.

        The minimum abbreviation of this command is IDP.

</code> **EXAMPLES** <code>
        IDP 3            - Display current IDPATH for port 3
        IDP 3 ID,G7GJP   - Port 3 beacon to "ID" via G7GJP

</code> **SEE ALSO** <code>
        IDINTERVAL(7)  -- Identification Beacon Interval
        IDPATH(7)      -- ID Beacon Path
        IDTEXT(1)      -- IDisplay / Set Identification Beacon

</code>
----
==== IDS ====
<code>IDS(1)                  XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        IDS -- Intrusion Detection System Commands.

</code> **SYNOPSIS** <code>
        IDS L[og] [on | off]
        IDS S[tats]
        IDS V[erbosity] [0-4]

</code> **DESCRIPTION** <code>
        The IDS commands are used to display the IDS statitics, and
        to control IDS logging and verbosity.

        The IDS is described in more detail in section 9 of the
        manual.

</code> **OPTIONS** <code>
        L[og]
            Displays or changes IDS logging state. If IDS logging is
            enabled, some (but not all) IDS events are logged to the
            file LOG/YYMMDD_IDS.LOG, where YYMMDD are the 2 digit
            year, month and day of the month.

        S[tats]
            Displays the IDS statistics. These ar more comprehensive
            than those displayed in the top pane of the IDS window.
            The meaning of each field is explained in IDS(9).

        V[erbosity]
            Displays / changes IDS verbosity, i.e. the amount of
            detail that is displayed and logged. There are 5
            verbosity levels as follows:

                0 - No notifications
                1 - Intrusion / Escalation attempts only.
                2 - As 1, plus recon attempts (port scans etc.
                3 - As 2, plus possible suspicious events.
                4 - As 3, plus "unusual" events.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        IDS(9) -- Intrusion Detection System.

</code>
----
==== IDTEXT ====
<code>IDTEXT(1)             XROUTER REFERENCE MANUAL               24/9/2023
</code> **COMMAND** <code>
        IDTEXT -- Display / Set ID Beacon Text.

</code> **SYNOPSIS** <code>
        IDT[ext] <port | 0> [text]

</code> **AVAILABILITY** <code>
        Sysop only.

</code> **DESCRIPTION** <code>
        Displays or modifies the contents of the regular AX25 "ID"
        beacons, which are transmitted every IDINTERVAL.

        The "port" argument is either a valid port number, or zero.
        In the latter case the command displays or sets the "global"
        IDTEXT.

        If "text" is not specified, the current IDTEXT for the
        specified port is displayed.

        If "text" is specified, the IDTEXT parameter for the specified
        port is changed to the new value.

        The minimum abbreviation of this command is IDT.

</code> **EXAMPLES** <code>
        IDT 0 !5220.00N/00102.13W Miltown Node.  - Set global IDTEXT
        IDT 3                   - Display current IDTEXT for port 3
        IDP 3 Test only         - Override global IDTEXT on port 3

</code> **LIMITATIONS** <code>
        The IDTEXT must be a single line only.

        Since the command line is limited to 80 characters, the
        maximum length of IDTEXT that can be entered using this
        command is 74 characters (IDTEXTs that exceed 74 characters
        can only be specified in XROUTER.CFG).

</code> **SEE ALSO** <code>
        IDINTERVAL(7)  -- Identification Beacon Interval
        IDPATH(1)      -- Display / Set Identification Beacon
        IDTEXT(7)      -- Identifation Text Directive
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IFACE ====
<code>IFACE(1)               XROUTER REFERENCE MANUAL               8/9/2023
</code> **COMMAND** <code>
        IFACE -- Description..

</code> **SYNOPSIS** <code>
        IF[ace] A[dd] <ifacenum> <type> <mtu> [id]
        IF[ace] D[isplay] <ifacenum> | all
        IF[ace] DR[op] <ifacenum>
        IF[ace] L[ist]
        IF[ace] STA[rt] <ifacenum> 
        IF[ace] STO[p] <ifacenum>
        IF[ace] <ifacenum> <command> [args]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The IFACE command can be used to add, modify, remove, list,
        start and stop XRouter's interfaces on the fly.

</code> **WARNING** <code>
        This is a bit buggy at present. Not all of the commands work
        properly for all types of interface. Stopping some types of
        interface can cause XRouter to crash!!

</code> **OPTIONS** <code>
        The A[dd] sub-command is used to create a new interface:

              IF[ace] A[dd] <ifacenum> <type> <mtu> [id]

              <ifacenum>  Number to assign to the interface.
              <type>      Interface type (see below)
              <mtu>       Maximum Transmission Unit
              [id]        Optional name for the interface

        Interface types (there are others):

              AGW          AGW Packet Engine
              ASYNC        Serial (COM) port
              AXIP         AX25 over IP
              AXTCP        AX25 over TCP
              AXUDP        AX25 over UDP
              EXTERNAL     External (eg Ethernet)
              LOOPBACK     Internal loopback (don't use!)
              TCP          Anything over TCP
              TUN          Linux "tunnel" (tun) interface
              UDP          Anything over UDP
              YAM          YAM 1200/2400/9600 modem

        For example, to create interface 3 (providing iface 3 doesn't
        already exist), type AXIP:

              iface add 3 axip 256 My new interface

        The DR[op] sub-command deletes an interface, for example:

              IFACE DROP 3

       The L[ist] sub-command lists the interfaces, showing their
       numbers, types, rotocols, MTU's and descriptions:

              IFACE LIST 

              G8PZT:KIDDER} Interfaces:

              Num Type     Prtcl    MTU  Description
                1 external ether    1064 eth0
                2 axudp    axudp     256 
                3 axtcp    axtcp     340 
              (End of list)

        The D[isplay] sub-command displays the details of a single
        interface:

              iface d 1

              G8PZT:KIDDER} Interface 1: 
                  Type=external, Ptcl=ether, MTU=1064, Descr=eth0
                  Used by port(s):  1
                  MAC Address=B8:27:EB:35:5C:5B

        If the argumemt is "ALL" instead of a specific number, all
        the interfaces are listed in detail.

        The STA[rt] sub-command is used to bring an interface into
        use, e.g.:

              IFACE START 2

        The STO[p] sub-command takes an interface out of use, for
        example:

              IFACE STOP 2

        You cannot stop an interface which has dependent ports until
        all those ports have first been stopped. At present,
        stopping an Ethernet interface may cause a segfault.

        Certain interface parameters can be changed on the fly,
        using the general command form:

              IF[ace] <number> <command> [args]

              e.g. IFACE 4 ID Paula's Interface
 
        The following parameters are accepted so far, but as this is
        a work in progress, they are not all fully functional...

              COM CONFIG FLOW ID INTNUM IOADDR KISSOPTIONS MTU
              NUMBER PROTOCOL SPEED TYPE

        (CONFIG, PROTOCOL and MTU are not yet working)

</code> **SEE ALSO** <code>
       PORTS(1)       -- Port management commands
       XROUTER.CFG(8) -- Main configuration file.

</code>
----
==== INFO ====
<code>INFO(1)                 XROUTER REFERENCE MANUAL              7/6/2023
</code> **COMMAND** <code>
        INFO -- Display information

</code> **SYNOPSIS** <code>
        I[nfo] [nodecall | nodealias | topic]
        I[nfo] PAGE
        I[nfo] MORE

</code> **AVAILABILITY** <code>
        The command is available to all users.

</code> **DESCRIPTION** <code>
        The INFO command displays information about the node, and
        other topics chosen by the sysop. It can also be used to
        display information from other nodes.

</code> **OPTIONS** <code>
        If no arguments are given, the text specified by INFOMSG in
        XROUTER.CFG is sent to the user.

        If [topic] is specified, the contents of the appropriate .INF 
        file, if it exists, are sent to the user instead.

        If [topic] is "*", all the available info topics are listed.

        "I[nfo] PAGE" displays a built-in page giving pertinent
        infomation about the system, such as its location, software,
        languages, services etc.

        "INFO MORE" displays a built-in page showing technical
        settings which may be of use when trying to diagnose network
        problems. 

        If the argument is a nodecall or alias, and that node is an
        XRouter, and it is in the nodes table, XRouter will obtain
        information from the INFO service (NetRomX service 1) on that
        node. The information is returned in a form which is readable
        by both humans and machines. i.e. of the "<keyword>: <value>"
        form, with each piece of information on a separate line.
        Every keyword is unique.

</code> **EXAMPLES** <code>
        I FOURPAK   - Displays contents of INFO/FOURPAK.INF file.
        I KIDDER    - Displays info from the KIDDER node.

</code> **LIMITATIONS** <code>
        Topic file names INFO.INF and MORE.INF are reserved. If you
        create those files, they will not be displayed.

        Info <node> only works with XRouters at present.

</code> **FILES** <code>
        The sysop may create INFO topics as required, and there is no 
        need to restart XRouter in order to activate them.

        Each topic should be created as a plain text file with the 
        .INF extension and should be placed in the INFO subdirectory 
        located immediately under the router's working directory.

        Files without the .INF extension will not be listed or 
        accessible.

</code> **SEE ALSO** <code>
        HELP(1)         -- User help command.
        INFO(9)         -- Info system.
        INFO-SVC(9)     -- NetRomX Information Service
        MAN(1)          -- XRouter sysop manual.
        XROUTER.CFG(8)  -- Main configuration file.

</code>
----
==== IPADDRESS ====
<code>IPADDRESS(1)          XROUTER REFERENCE MANUAL               25/9/2023
</code> **COMMAND** <code>
        IPADDRESS -- Display / Set global or port IPADDRESS.

</code> **SYNOPSIS** <code>
        IPA[ddress] <port | 0> [value]

</code> **AVAILABILITY** <code>
        This command is sysop-only.

</code> **DESCRIPTION** <code>
        The IPADDRESS command allows the global and port-specific
        IP addresses to be displayed or changed.

        The global and port IP addresses are specified in XROUTER.CFG,
        but may be changed on the fly using this command.

        The global IP address is inherited by all ports, and is
        usually an amprnet (44-net) one. The port-specific addresses
        are additional to the global one, and are used only on the
        port on which they are specified. 

        The minimum abbreviation for this command is "IPA".

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, and it is a valid
        port number, the current IPADDRESS for that port number
        is displayed.

        If two numeric arguments are supplied, the first specifies a 
        port number and the second specifies a new IPADDRESS for 
        that port only.

        If the first argument is zero, the command displays and sets
        the global IPADDRESS. This address is inherited by all
        ports, in addition to any port-specific address.

</code> **EXAMPLES** <code>
        IPA 0                 - Display global IPADDRESS
        IPA 0 44.131.91.2     - Set global IPADDRESS to 44.131.91.2
        IPA 3 192.168.0.11    - Set port 3 IPADDRESS to 192.168.0.11

</code> **SEE ALSO** <code>
        IPADDRESS(7) -- Main or Port IP Address.
        IP-STACKS(6) -- IP Stacks in XRouter.
        IP-PRIMER(9) -- IP Primer.

</code>
----
==== IPLINK ====
<code>IPLINK(1)             XROUTER REFERENCE MANUAL               25/9/2023
</code> **COMMAND** <code>
        IPLINK -- Display / Set Port IPLINK Address.

</code> **SYNOPSIS** <code>
        IPL[ink] <port> [ipaddress | hostname]

</code> **AVAILABILITY** <code>
        This command is sysop-only.

</code> **DESCRIPTION** <code>
        The IPLINK command allows the specified port's IPLINK address
        to be displayed and changed.

        IPLINK is the AXIP or AXUDP link partner's IP address or
        hostname.

        It is usually specified within a PORT configuration block in
        the XROUTER.CFG file, but since partner sysops sometimes
        change their IP address or hostname, this command allows it
        to be changed on the fly, without needing to take XRouter off
        line.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, and it is a valid
        port number, the current IPLINK value for that port, is
        displayed, along with the equivalent IP address.

        If two arguments are supplied, the first must specify a valid
        port number and the second specifies a new IPLINK address for 
        that port.

        If a hostname is specified, the IP address displayed in
        brackets may still show the old value until a frame is sent
        to, or received from the peer.

</code> **EXAMPLES** <code>
        IPLINK 16                - Display current IPLINK for port 16
        IPLINK 16 g8pzt.ath.cx   - Set port 16 IPLINK to g8pzt.ath.cx

</code> **SEE ALSO** <code>
        AXIP(9)        -- AX25-over-IP Tunnelling.
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        IPLINK(7)      -- Peer IP Address
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IP ====
<code>IP(1)                 XROUTER REFERENCE MANUAL                8/9/2023
</code> **COMMAND** <code>
        IP -- Display / Change IP routing parameters.

</code> **SYNOPSIS** <code>
        IP B[an] A[dd] <ipaddr> [netmask]
        IP B[an] D[rop] <ipaddr>
        IP B[an] L[ist]
        IP B[an] P[ort] A[dd] <TCP|UDP|ALL> <start> [end]
        IP B[an] P[ort] D[rop] <TCP|UDP|ALL> <start> <end>
        IP B[an] P[ort] L[ist]
        IP B[an] P[ort] S[ave]
        IP B[an] S[ave]
        IP C[onfig]
        IP H[eard]
        IP Q[uiet] [level]
        IP ROUTES
        IP R[oute] A[dd] <host>[/len] <gateway> <port>
                         [mode [metric [private]]
        IP R[oute] ADDP[rivate] <host/len> <mode> <gateway>
        IP R[oute] C[md] [0-1]
        IP R[oute] D[rop] <host> <len>
        IP R[oute] DE[fault] <port> [gateway [mode]]
        IP R[oute] L[ist]
        IP R[oute] LO[ad]
        IP R[oute] LOO[kup] <host>
        IP T[tl] [ttl]
        IP U[nban] <ipaddr>

</code> **AVAILABILITY** <code>
        The IP ROUTES command is available to all, providing it
        hasn't been disabled by sysop. The remaining commands are
        sysop-only.

</code> **DESCRIPTION** <code>
        The IP commands are used to display and alter some of the IP
        parameters, the contents of the table responsible for
        routing of IP datagrams, and the ban lists.

        The arguments are as follows:

        <host>      Target hostname or IP address. IP address is
                    preferred, as it is more efficient. Route default
                    must always be an IP address.

        <len>       No. of bits to be matched (from left) 0-32

        <gateway>   Destination gateway IP address in dotted quad.
 
        <port>      Port number on which to route the datagram.
                    For encapsulated modes (e,i,u), Netrom and reject
                    modes (r and s) this is ignored and should be 0.
                    For IPUDP, this can optionally specify the UDP
                    service number to use (default=94).

        <mode>      How the datagram is routed, as follows..

                      d = Datagram (direct)
                      e = Encap (ip-over-ip protocol 4)
                      i = IPIP  (ip-over-ip protocol 94)
                      k = kernel (via Linux/Windows)
                      n = Netrom (ip-over-netrom)
                      r = Reject
                      s = Silent discard
                      u = IPUDP  (ip-over-UDP) 
                      v = Virtual circuit (ip-over-ax25)

                    The usual mode is "datagram". However, on less
                    than perfect RF links, better performance can be
                    obtained by using Virtual Circuit mode.  Netrom
                    mode is inefficient, but can "tunnel" datagrams
                    across non-ip parts of the network.
                    Encap, IPIP and IPUDP are used for tunneling
                    amateur IP across the public internet.
                    Reject and Silent discard are used to suppress
                    bouncing and looping.
                    Kernel mode is a dummy mode. It tells XRouter to
                    use the Windows / Linux IP stack for anything
                    matching the entry, but see Caveats below.

</code> **OPTIONS** <code>
        The QUIET subcommand is used to display or set XRouter's
        "stealth" level, i.e. how it responds to ICMP echo requests
        and TCP port probes. If the level is zero, XRouter behaves
        normally. If a non-zero argument is supplied, XRouter becomes
        stealthy. The stealth level is specified by adding the
        following values:

            1   Suppress ICMP echo replies.
            2   Suppress Protocol unreachable
            4   Suppress TCP refusals
            8   Suppress all ICMP errors
        
        ROUTE CMD is used to allow / disallow the IP ROUTES and
        IPR[outes] commands from being used by non-sysops. On amateur
        networks however, it is considered bad practice to hide IP
        routing.

        The ROUTE DEFAULT subcommand sets up a default route which is
        used when no other route is found.  If no gateway is
        specified, the target will be assumed to be a direct
        neighbour.  If not specified, the mode defaults to datagram.

        The ROUTE ADD subcommand adds an entry to the routing table.
        The first argument is the target host IP address, with
        optional mask. e.g. 44.131.90.1/32 means "match all 32 bits",
        whereas 44.131.90.0/24 means "match the most significant 24
        bits", and would route all 256 addresses from 44.131.90.0 to 
        44.131.90.255.
        The second argument is the "gateway" address, i.e. the
        address  of the system which can handle the datagram.
        The third argument is the port to route the datagram on, and 
        the last argument is the mode (see above).
 
        The ROUTE ADDPRIVATE subcommand is the same as ROUTE ADD,
        except that it marks the route "private", hiding it from
        non-sysops. The regular form has the same syntax as ROUTE ADD
        and can accept any mode, whereas the shortened form is
        provided for backward compatibility with "encap.txt", and can
        only accept mode "encap".

        The ROUTE DROP subcommand removes an entry from the table.
        Both the target host and the mask must match.

        The ROUTE LOAD subcommand clears the existing IP parameters
        and tables, and reloads them from IPROUTE.SYS.

        The ROUTE LOOKUP subcommand displays the gateway and port
        which XRouter will use to reach a given destination.

        The CONFIG sub-command displays lots of information about the
        IP configuration of the main stack and the various ports.

        The HEARD subcommand displays the IP addresses from whom
        datagrams have been received, along with the date and time
        when they were last heard, the number of packets and number
        of bytes received.

        The TTL subcommand specifies the default "Time To Live" for
        datagrams originating at this host.

        Sub-commands "IP BAN ADD" and "IP BAN DROP" allow manual
        editing of the "banned IP" list. The short forms of those
        commands, IP BAN and IP UNBAN, still work....

        The sub-command "IP BAN SAVE" saves the list of banned IP
        addresses to the file IPBAN.SYS. The contents of the file
        are reloaded at boot-up. The ban list is always saved at
        closedown, but this command can be used in CRONTAB.SYS to
        additionallly save the ban list from time to time in case of
        power cuts.

        Sub-commands IP BAN PORT ADD, IP BAN PORT DROP, IP BAN PORT
        LIST, and IP BAN PORT SAVE allow management of the "honeypot"
        ports (see below).

</code> **EXAMPLES** <code>
        IP ROUTE DEFAULT 3 44.131.90.6 v
        IP ROUTE ADD 44.131.95.0/24 44.131.95.240 9 d
        IP ROUTE DROP 44.131.97.1 32
        IP ROUTE LOOKUP bbc.co.uk
        IP BAN PORT ADD tcp 445

</code> **FILES** <code>
        The IP commands may be used in IPROUTE.SYS and BOOTCMDS.SYS
        but the only ones that have any meaning in those locations
        are IP ROUTE ADD, IP ROUTE DEFAULT, IP TTL and IP QUIET. It
        is usual to define IP routing in IPROUTE.SYS.

        When XRouter boots, it first reads IPROUTE.SYS, then
        ENCAP.TXT, then finally BOOTCMDS.SYS.

</code> **CAVEATS** <code>
        Mode "k" should be used with caution. It means "Use kernal
        TCP/IP services to reach this destination", and is intended
        only for when the XRouter stack can't be used.

        For "security reasons" Windows does not allow applications
        to route raw IP traffic through its stack. It actively
        blocks IP protocol 4 (IPEncap), and puts severe restrictions
        on TCP and UDP traffic.

        Windows allows XRouter to originate and terminate TCP, UDP,
        IPIP, ICMP and AXIP, but not to *route* those protocols.
        Therefore you may Telnet and Ping from XRouter, but you are not
        allowed to route 3rd party traffic, e.g. from RF to Internet.

</code> **NOTES** <code>
        The IP routing table is necessary only for IP, and does not 
        take any part in normal ax25 and Netrom activities.  See the 
        full manual for details on how to set up the IP system.

        Please do not over-use ADDPRIVATE, as it hinders the
        diagnosis of networking problems, and many consider it to
        be contrary to the spirit of Ham Radio.

        Honeypots
        ~~~~~~~~~
        In this context, a honeypot a sticky trap, set up on popular
        TCP or UDP ports, for catching internet low-life.

        Hackbots generally start their attacks by probing for open
        TCP ports, and to save time they often start with the most
        popular ones - telnet, SSH, HTTP, VNC and so on. If they find
        an open port, they tend to inform each other, then they all
        concentrate their attacks on that port.

        Unless you have a particular service port open, the chances
        are that anyone who tries to connect to it is up to no good.
        So the honeypot is a mitigation measure. It LOOKS like an
        attractive open port, but it's not! Anyone who connects to it
        gets their IP address logged and banned. After that they
        can't do any more attacking unless they change their IP
        address.

        It's not foolproof. Nation states and sophisticated hackers
        have access to virtually unlimited IP addresses. But it slows
        them down, and the IDS alerts you that there is a problem.

</code> **SEE ALSO** <code>
        IP-PRIMER(9) -- IP Addressing / Routing Primer.
        IPROUTE(1)   -- Display IP Routes
        IDS(9)       -- Intrusion Detection System
        IPBAN.SYS(8) -- Banned IP addresses File.

</code>
----
==== IPROUTE ====
<code>IPROUTE(1)              XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        IPROUTE -- Display IP routing table.

</code> **SYNOPSIS** <code>
        IPR[OUTE]

</code> **DESCRIPTION** <code>
        The IPROUTE command, which may be abbreviated to IPR, displays 
        the contents of the table responsible for routing of IP 
        datagrams.

        For each route it displays the IP address, the subnet mask, 
        the gateway address, the port and the mode (Datagram, VC or 
        Netrom).

        The command "IP ROUTES" produces an identical result.

</code> **NOTE** <code>
        The IP routing table is initialised from file IPROUTE.SYS when 
        the router is started, and may contain other entries "learned" 
        by the system, or entered by the sysop.  It is not required in 
        any way for normal AX25 and NETROM activities.

</code> **AVAILABILITY** <code>
        The IPROUTE command is available to all users, providing the
        sysop hasn't disabled it. However, routes marked as "private"
        are only displayed to sysops.

</code> **SEE ALSO** <code>
        IP(1) -- Add / Delete / List IP routing entries.

</code>
----
==== J ====
<code>J(1)                    XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        J -- Displays recently connected stations.

</code> **SYNOPSIS** <code>
        J

</code> **DESCRIPTION** <code>
        The J (JustHeard) command lists the callsigns of the last 20 
        stations who have connected to XRouter since it was booted.

        The "Type" field shows the type of session as follows:

            AGWH - AGW Host app        APPL - Uplink to app
            APRS - APRS Server         AX25 - AX25L2
            CHAT - Chat session        CHGN - CHARGEN
            CONS - Console             DAYT - Daytime server
            DEDH - WA8DED Host app     DSCD - Discard server
            DXSV - DX Server           ECHO - Echo server
            FING - Finger server       FTPC - FTP Client
            FTPS - FTP Server          FTPX - FTP Proxy
            HLIB - Hamlib              Host - BPQHost application
            HTRM - HTTP Terminal       HTTP - HTTP Server
            INFO - Info server         MHSV - MHeard Server
            MQTT - MQTT Server         NFTP - Netrom FTP
            NTPX - NetRom/TCP Proxy    NTRM - Netrom
            PMS  - Personal Msg System PRXY - Proxy
            PSTN - Dial-in             RHP  - RHP app
            RHPC - RHP Control Sess    RHPP - RHP SeqPacket Socket
            RHPS - RHP Stream Socket   RIGS - Rig Server
            RLOG - Remote Login        SMS  - Short Message
            Sock - Socket app          SOKH - Uplink to Socket host
            SOKS - SOCKS Proxy         Teln - Telnet
            TPXY - Telnet Proxy        TTY  - Serial TTY 
            TTYL - TTYLink             WXSV - Weather server     

        The "Usercall" field shows the user's callsign.  If it was a 
        Netrom level 4 connection, the user's node is also shown, in 
        the form <user>@<node>.

        The "Logoff-time" field shows the date and time when the user 
        logged off.

        The "Mins" field shows how long the user was connected in 
        minutes.

        The "Bytes from/to" fields show how many information (i.e. 
        layer 7) bytes were received from, and sent to the user.

</code> **EXAMPLE** <code>
        G8PZT:KIDDER} Recent users:
        Type  Usercall           Logoff-time  Mins    From-bytes-To
        CHAT  G1WXA-6@GB7BHM     22/08 11:06  1          8     1674
        AX25  GB7COV-14          22/08 11:06  1        696       93
        NTRM  GB7PZT@GB7PZT      22/08 10:57  0       1370      236
        PMS   G4YUD              22/08 10:54  2         13      765
        (End of list)

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        USERS(1) -- Display current users

</code>
----
==== KEEPALIVE ====
<code>KEEPALIVE(1)            XROUTER REFERENCE MANUAL             22/3/2024

</code> **COMMAND** <code>
        KEEPALIVE -- Display / Change KEEPALIVE time for a port.

</code> **SYNOPSIS** <code>
        KE[eepalive] <port> [seconds]

</code> **DESCRIPTION** <code>
        Displays the current AXIP / AXUDP "keepalive" setting for the
        specified port, or allows it to be changed.

        If the second argument is omitted, the current value is 
        displayed, otherwise the value in seconds is used.

        The new setting overrides the value specified by the
        KEEPALIVE directive in the XROUTER.CFG file, and remains in
        force until changed, or until the next restart.

        Keep-alives are only used on AXIP and AXUDP ports. This
        command has no effect on other types of port.

</code> **EXAMPLES** <code>
        KEEPALIVE 2   - Display port 2 keepalive interval
        KE 2 120      - Set port 2 keepalive to 120 seconds

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        AXIP(9)        -- AX25-over-IP Tunnelling.
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        KEEPALIVE(7)   -- AXUDP / AXIP Keepalive Interval.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== KILL ====
<code>KILL(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        KILL -- Terminate any session

</code> **SYNOPSIS** <code>
         K[ill] [all | <session> [session] ...]

</code> **DESCRIPTION** <code>
        Immediately terminates the specified session(s),
        disconnecting any links.  Useful for disconnecting
        troublemakers or failed sessions.

        To kill multiple sessions, use "KILL ALL", or list the
        session numbers with space(s) (not commas) between each one.

        Session numbers are shown by the U(sers) command.

</code> **EXAMPLE** <code>
        K 301         - Terminate session numbered 301
        K 123 456 789 - Terminate sessions 123, 456 and 789

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **LIMITATIONS** <code>
        You are not allowed to kill your own session.

</code> **SEE ALSO** <code>
        USERS(1) -- Display current users

</code>
----
==== LANG ====
<code>LANG(1)               XROUTER REFERENCE MANUAL              29/10/2023
</code> **COMMAND** <code>
        LANG -- Display / Set Session Language

</code> **SYNOPSIS** <code>
         LA[ng] [en | fr | es | nl]

</code> **DESCRIPTION** <code>
        The LANG command can be used to display the available
        languages, report the current language, or change the
        language for the session.

        As of October 2023 only English (en), French (fr), Spanish
        (es) and Dutch (nl) are available. German (de) is still in
        progress. More languages can be added if there is any
        demand for them.

        The default language for XRouter is set by the DEFAULTLANG
        directive in XROUTER.CFG.

        The initial language for a session is controlled by entries
        in LANGS.SYS, if it exists. 

</code> **OPTIONS** <code>
        If used without arguments, LANG displays the available
        language codes, for example:

            lang
            G8PZT:KIDDER} Available languages: EN, FR, ES, NL 

        If the argument is a known language code, and the
        corresponding language file was present in the working
        directory when XRouter was started, the language for the
        session is changed as follows:

            lang es
            G8PZT:KIDDER} El idioma actual es ES

</code> **AVAILABILITY** <code>
        All users.
   
</code> **SEE ALSO** <code>
        CONSOLELANG(7) -- Console language
        DEFAULTLANG(7) -- Specify default language
        LANGS.SYS(8)   -- Language selection file
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== LINKED ====
<code>LINKED(1)               XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        LINKED -- Specify Temporary Callsign.

</code> **SYNOPSIS** <code>
        *** LINKED AS <callsign>

</code> **DESCRIPTION** <code>
        The "*** LINKED AS" command allows you to change your uplink
        callsign for the duration of the current session. This should
        be used for test purposes only.

</code> **EXAMPLE** <code>
        *** LINKED AS G8PZT     - Set console callsign to "G8PZT"

</code> **AVAILABILITY** <code>
        Usually Sysop-only, but may additionally be made available to
        users and/or applications, using the ENABLE_LINKED directive
        in XROUTER.CFG.

        It is recommended that this command is NOT made available to
        users.

</code> **SEE ALSO** <code>
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== LINKS ====
<code>LINKS(1)                XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        LINKS -- Displays the currently active level 2 sessions.

</code> **SYNOPSIS** <code>
        L[inks]

</code> **DESCRIPTION** <code>
        The LINKS command lists level 2 user up/downlinks and inter-
        node links.  It is mainly of interest to sysops, and shows the 
        callsigns being used at both ends of the link plus some other 
        data, such as frame counts and retry rates.

        The command may be abbreviated to "L".

</code> **EXAMPLE** <code>
        G8PZT:KIDDER} AX25 L2 Links:
        Remote Local  Prt Sta Ver Try  T3   Pac  Max Idle  Txq Rxq Asm
        G4FPV  G8PZT   5   5   2   0   177  160   1    90    0   0   0
        GB7PZT G8PZT   7   5   2   0   181  240   7   201    0   0   0
        GB7GH  G8PZT   9   5   2   0   176  120   1    32    3   1   0
        (End of list)

        Remote - L2 callsign at far end of link
        Local  - L2 callsign at our end of the link.
        Prt    - Port number
        Sta    - Link state (2 = connecting, 4 = disconnecting,
                             5 = connected)
        Ver    - AX25 version number
        Try    - Retry count
        T3     - Current state of the LAPB T3 countdown in secs
        Pac    - Paclen
        Max    - Maxframe
        Idle   - Secs since there was any activity on the link
        Txq    - No. of L2 frames queued for transmission
        Rxq    - No. of L2 frames on receive queue
        Asm    - No. of frame fragments awaiting reassembly

</code> **AVAILABILITY** <code>
        The LINKS command is available to all users.

</code> **SEE ALSO** <code>
        AXROUTES(1) -- Display current & recent L2 links

</code>
----
==== LISTEN ====
<code>LISTEN(1)               XROUTER REFERENCE MANUAL              5/8/2024

</code> **NAME** <code>
        LISTEN -- Listen For Incoming Connections.

</code> **SYNOPSIS** <code>
        LIS[ten] <portnum> [0]

</code> **DESCRIPTION** <code>
        The LISTEN command, which can be abbreviated to "LIS",
        initiates "listen mode" on a specified PORT.

        In this mode the user is (optionally) able to "monitor" packet
        traffic on the chosen port, and the node will accept incoming
        connections to the user's callsign.

        For scurity reasons, non-sysops may only listen on RADIO
        ports. It is not possible to listen on the session's "uplink"
        port.

        Traffic monitoring is enabled by default, but may be disabled
        by supplying 0 (zero) as an optional additional argument. 

        All the normal node commands are available in listen mode.
        Additionally the CQ command can be used to advertise the
        user's presence.

        The user's SSID is inverted in the usual Net/Rom way, so if
        the uplink is G9XYZ, they will be listening and beaconing as
        G9XYZ-15.

        Upon incoming connection to a "listener", traffic monitoring
        is disabled, the user is notified of the incoming connection,
        and the connection becomes a normal "transparent" throughlink.

        If either party disconencts, they are both disconnected.

</code> **OPTIONS** <code>
        To exit listen mode use "LISTEN 0" or "LISTEN OFF"

</code> **EXAMPLES** <code>
        LISTEN 3    - Listen on port 3 with traffic monitoring.
        LISTEN 5 0  - Listen on port 5 without traffic monitoring.
        LIS OFF     - Exit listen mode.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        CQ(1)    -- Send a CQ Message.
        WATCH(1) -- Monitor traffic on port(s).

</code>
----
==== LOADNODES ====
<code>LOADNODES(1)            XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        LOADNODES -- Load the nodes and routes tables from disk.

</code> **SYNOPSIS** <code>
        LOADNODES [filename]

</code> **DESCRIPTION** <code>
        The LOADNODES command loads the nodes and routes tables from 
        a "recovery" file.  This file is written when XRouter closes
        down, unless the "-N" switch is used, and read by XRouter at
        start up, unless the "-n" (noNodes) switch is used.

        The recovery file is used to reconstruct the Netrom routing
        tables without having to wait for nodes broadcasts to be
        received.  The LOADNODES command allows you to load the
        tables at any time without taking XRouter off line.

        The optional argument specifies the filename to load from, and 
        if not specified it defaults to XRNODES.

        It is recommended that, once in a while, you use the SAVENODES 
        command to save a "good" copy of the nodes tables to a file 
        other than XRNODES.  This will ensure that, should the tables 
        become depleted, for example due to a radio failure, they can 
        be reloaded when the problem is fixed, without rebooting.

</code> **EXAMPLES** <code>
        LOADNODES              - Load from default file XRNODES
        LOADNODES nodebak.txt  - Load from file "NODEBAK.TXT"

</code> **FILES** <code>
        The XRNODES file is similar in format to the BPQNODES file
        used with the DOS version of BPQ node, but is no longer
        compatible with it. 

        XRNODES is a plain text file, which may be viewed with
        Notepad by adding the extension .TXT.

</code> **CAVEATS** <code>
        The LOADNODES command should be used with caution, because it
        can result in obsolete nodes being re-introduced into the node
        table.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        SAVENODES(1) -- Save Nodes and Routes to Disk.
        XRNODES(8) -- Nodes / Routes Recovery File.

</code>
----
==== LOG ====
<code>LOG(1)                XROUTER REFERENCE MANUAL                9/9/2023
</code> **COMMAND** <code>
        LOG -- Control activity logging.

</code> **SYNOPSIS** <code>
        LOG [ON | OFF]
        LOG <flags>
        LOG <system> [level]

</code> **AVAILABILITY** <code>
        Console, BOOTCMDS.SYS, and remote sysops only.

</code> **DESCRIPTION** <code>
        The LOG command is used to enable or disable the logging 
        of XRouter activity, such as connections, disconnections, 
        errors, user commands etc.  It overrides the default setting
        that was specified using "LOG=n" in XROUTER.CFG, and allows
        finer control.

</code> **OPTIONS** <code>
        If LOG is used without arguments, the current setting of the
        "log flags" is shown. These are simple on-off switches for
        the various layers / sub-systems. The number returned is the
        sum of the active flags in the "value" column of the table
        below:

                 Value   Function
                 ----------------------------------------------
                    1    Enable/disable logging
                    2    Use CRLF instead of LF line endings
                    4    Log session activity
                    8    Log TCP/UDP events
                   16    Log Netrom layer 4 events
                   32    Log IP/ICMP layer events
                   64    Log Netrom layer 3/inp3
                  128    Log ODN activity.
                  256    Log IDS activity to IDS log
                  512    Generate PCAP file (use with caution)
                 1024    Log daemon process events
                 2048    Log AX25 over TCP
                 4096    Log AX25 connections etc
                 8192    Log interface layer events

        If the argument to LOG is a numeric value between 0 and 16383
        the log flags are set to that value.

        For example, to log session layer and Netrom L4 activity in
        Windows/DOS format, you would use "LOG 23" (1+2+4+16). To log
        EVERYTHING, it would be "LOG 16383", and to log everything
        except PCAP (packet capture), LOG would be 15871 (16383-512).

        If a "log flag" is "on", the verbosity level (see below) for 
        that subsystem or group of subsystems is set to 6, i.e. 
        "routine information". When the flag is "OFF", the verbosity
        level is 0 (no logging).

        If the argument to LOG is the mnemonic of a sub-system, the
        verbosity "level" for that sub-system can be displayed or
        changed. Sub-system mnemonics currently supported are:

          Mnemonic  Subsystem
          --------------------------------------------
            AGWC    AGW Client
            AXTCP   AXTCP Interface
            CHAT    Chat server
            CONS    Console
            FTPC    FTP and NFTP clients
            FTPS    FTP and NFTP servers
            HTTP    HTTP server
            IFTCP   TCP interface
            INP3    Inp3 network admin
            LAPB    AX25 connected mode
            MAPD    Map update daemon
            MQTT    MQTT client, broker and daemon
            NRL3    Netrom layer 3
            NRL4    Netrom layer 4
            ODN     On-demand networking
            PROC    Daemon processes
            PMS     Personal Message System
            PMSD    PMS forwarding daemon
            SESS    Session layer
            SMSD    Short Message System forwarding daemon
            TCPH    TCP operations on host (kernal) stack
            TELN    Telnet

        As the conversion of the logging subsystem is only partially
        complete, more mnemonics will be added in due course. Use the
        LOG command without arguments to list the available mnemonics.

        <level> is the event's "priority" level between 0 and 7. The
        LOWER the number, the higher the importance of the
        information, as shown in the table below. Low numbers
        represent errors and events that must not be ignored, whilst
        the highest level is for verbose debug information that you
        wouldn't usually want to log.

          Level  Meaning
          ------------------------------------------------
            0    Total system failure
            1    Immediate action required
            2    Critical errors, e.g. hardware problems
            3    Survivable software errors
            4    Warnings
            5    Notifications that may need attention
            6    Normal operational messages
            7    Debugging

        Events are only logged if their priority level is equal to
        or LOWER than the "verbosity" threshold set by the sysop.
        For example, if a subsystem's verbosity level is 6, normal
        operational information, warnings and errrors are logged,
        but debug information isn't. If the verbosity level is 4,
        only the warnings and errors are logged. If the verhosity
        level is 0, nothing is logged.

        In the absence of the "LOG=n" directive in XROUTER.CFG,
        logging defaults OFF.

</code> **EXAMPLES** <code>
        LOG 19      -- Log NetRom layer 4 in CRLF format
        LOG OFF     -- Turn logging off (retains flags)
        LOG ON      -- Turn logging back on with previous settings
        LOG SESS 4  -- Log warnings and errors from session layer

</code> **FILES** <code>
        Log files are created in the LOG sub-directory of the XRouter
        working directory. One file is created per day, running from
        midnight to midnight local time. The files are plain text,
        and the file names take the form YYMMDD.LOG. e.g. 130119.LOG.

        The format of the entries in the log files is as follows:

            <time> <level> <system>: <comments>

        <time> is the timestamp in the form HHMMSS.

        <level> is the event's "priority" level between 0 and 7, as
                detailed in the table above.

        <system> is a sub-system mnemonic as listed above.

        <comments> is free-form, usually terse, and may contain
                    various machine-readable action codes.

        Example:

            004101 7 CHAT: Peer G8PZT-8 sess 6 timeout
            004101 6 NRL4: Requesting disconnect from G8PZT-8,
                            theirCct=2930 ourCct=6
            004101 6 SESS: 6 G8PZT-8@G8PZT-8 SK R:97 S:33
            004121 6 NRL3: L3RTT request to G8PZT
            004121 6 NRL3: L3RTT request to G8PZT-14
            004121 6 NRL3: L3RTT reply from G8PZT, TT=60ms
            004206 7 PROC: PB MAPD

        The meaning of the action codes are as follows (incomplete
        list):

           CU  - Uplink connection (followed by session type)
           DU  - Uplink disconnection
           CD  - Downlink connection
           DD  - Downlink disconnection
           HE  - HTTP Error
           HR  - HTTP Request
           PB  - Process Begins
           PE  - Proceess Ends
           SK  - Session kill (i.e. session ends)
           U   - User entered command

        The reason for the cryptic logging is to (a) save space and
        (b) allow the logs to be analysed by programs, for example to
        generate usage statistics.

</code> **CAVEATS** <code>
        Logging is useful if you are trying to rack down a problem,
        but it generates large volumes of data. This is unlikely to
        be an issue on a modern PC, but may become so if you were
        running XRouter on a 256Mb USB memory stick for example.

        The effect of logging on the longevity of SD cards is not
        known, but the author has had full debug logging enabled for
        at least 5 years with no problems.

</code> **SEE ALSO** <code>
        LOG(7)          -- Directive to set log flags
        BOOTCMDS.SYS(8) -- Commands to run at bootup
        XROUTER.CFG(8)  -- Main configuration fie.

</code>
----
==== ! ====
<code>!(1)                   XRPi REFERENCE MANUAL                13/6/2019
</code> **COMMAND** <code>
        ! -- Run a command or program in an O/S shell.

</code> **SYNOPSIS** <code>
        ! <cmd> [args...]

</code> **AVAILABILITY** <code>
        Sysops only.

</code> **DESCRIPTION** <code>
        The "!" command is used for running commands and simple programs
        in a temporary operating system shell which terminates upon 
        completion of the program or command.

        It is suitable for simple non-interactive commands such as
        "ls", "mkdir" etc or programs that run and terminate without
        requiring any further input from the user.

        The "SHELL" command performs the same action.

</code> **EXAMPLE** <code>
        "! ls /dev"

</code> **LIMITATIONS** <code>
        Running interactive commands or programs via this means is
        (e.g. piping a directory listing via MORE) not possible.
        XRPi is suspended while the external command or program
        runs. This will be rectified in future versions.

</code> **NOTES** <code>
        This might seem pointless on a modern operating system. Why not
        just open another terminal, a VNC or SSH session?

        But if XRPi is on a remote hilltop and its only connection
        with the outside world is via the RF Packet Radio network (not
        unusual for a packet node) you can't run VNC or SSH.

        This command allows you to do simple Linux administration over
        the air with the most basic of equipment. 

</code>
----
==== @ ====
<code>@(1)                    XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        @ -- Request / answer password challenge

</code> **SYNOPSIS** <code>
        @ [string]

</code> **DESCRIPTION** <code>
        In order to gain access to sensitive commands, remote sysops 
        must first complete a password challenge.  Firstly, the
        remote sysop enters "@" alone, and the system replies with a
        matrix consisting of 5 lines of 5 numbers thus:

              4 1 6 3 7
              3 5 2 6 3
              7 1 9 2 4
              2 7 1 4 6
              3 5 2 6 1

        The remote sysop must then choose ONE of the lines, and send 
        the "@" command again, followed by the 5 characters from the 
        password string which correspond to the 5 numbers on the 
        chosen line.  There must be a space after the "@" but no 
        spaces between the characters.

        If the uplink is secure, the password may be entered in plain
        text, e.g. "@ mypassword", to save time. This is NOT
        recommended on RF links!

        If the challenge is correctly answered, the system replies 
        with "Ok", and the user has remote sysop status.

</code> **LIMITATIONS** <code>
        If the user does not have a password registered in 
        PASSWORD.SYS, the response to this command will be "Bad 
        command".

</code> **NOTE** <code>
        Console sysops already have full access and don't need to use 
        this command.

</code> **SEE ALSO** <code>
        PASSWORD.SYS(8) -- Sysop Password File.
        USERPASS.SYS(8) -- User Passwords File.

</code>
----
==== MAN ====
<code>MAN(1)                  XROUTER REFERENCE MANUAL             18/1/2024

</code> **COMMAND** <code>
        MAN -- Display Sysop's Manual pages.

</code> **SYNOPSIS** <code>
        MAN [section] [topic]

</code> **DESCRIPTION** <code>
        The MAN command is used to access the sysop's manual, which
        consists of a collection of pages, each covering a different 
        command or topic.

        The MAN pages are designed for sysop use, and usually give 
        more detail than the corresponding HELP pages.

        The manual is divided into several sections as follows:

           Section   Contents
           ------------------------------------------
              1      General Commands
              2      Chat Server Commands
              3      PZTDOS commands
              4      Mailbox commands
              6      Installation & Configuration Topics
              7      Configuration Directives
              8      Configuration / System Files.
              9      Miscellaneous Topics

        Some manual files are longer than the standard console review
        buffer size, and may therefore display only the last 400 or
        so lines. However they can be viewed in full via the HTTP
        interface, and by using <ALT+H> followed by <M> at the
        console.

</code> **OPTIONS** <code>
        Use MAN SECTIONS to list the sections.

        Entering MAN alone displays a list of available topics in
        section 1.

        To read a specific page in section 1, enter MAN followed by
        the topic for which you require help.

        To list topics in any other section, enter MAN followed by the
        section number.

        To read a topic in a section other than 1, enter MAN followed
        by a space, the section number, a space then the topic.

        If a topic name contains wildcards, all matching topic names
        in the section are displayed.

</code> **EXAMPLES** <code>
        MAN ARP      Display section 1 page for ARP command.
        MAN 7        List the topics in section 7
        MAN 7 MAXTT  Display section 7 page for MAXTT directive
        MAN 4 I*     List section 4 topics begining with 'I'

</code> **CONVENTIONS** <code>
        The following conventions are used in MAN pages:

        < >         Mandatory argument - These braces and the text 
                    enclosed within them represent any piece of text 
                    typed after the command.  The <> do not form part 
                    of the argument.

        [ ]         Optional argument - These braces enclose anything 
                    which is not always present. If used within a 
                    command name (e.g. N[ODES]), this indicates that 
                    the command may be abbreviated to a minimum form 
                    while remaining unique.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **FILES** <code>
        Manual files are normal text files, with the extension
        changed to ".MAN". They may be created and edited using a
        simple text editor such as Notepad (windows) or Leafpad, nano
        etc (Linux).

        All MAN files are located within the MAN directory, which
        itself is in the directory containing XRouter.

        As MAN files are for use only by the sysop, there is no need
        for separate directories for alternate language versions.
        Even if the MAN files are translated to a different language,
        they must always be situated in the MAN directory, not in a
        subdirectory thereof

        Filenames, including the extensions, MUST be in UPPER CASE.
        Lower case filenames and files without the .MAN extension are
        ignored.

        Within the .MAN files, lines beginning with a semicolon ';'
        are not displayed, so you can use them for comments, such as
        file modification details.

        Manual files can be viewed from the console using <ALT+H>
        followed by <M>. This browser window is only around 76
        characters wide, so try to keep the lines shorter than this,
        to preserve formatting. In any case, lines longer than 72
        characters are bad practice, typopgraphically-speaking.

</code> **LIMITATIONS** <code>
        Although most commands may be abbreviated, it is not currently 
        possible for the MAN command to correctly identify the 
        required page from an abbreviated argument.  Thus "MAN NODES" 
        is acceptable, whereas "MAN NO" is not. Use wildcards if
        necessary.

</code> **NOTE** <code>
        Due to its size and complexity, it would be impractical to
        produce a single-document sysop manual for XRouter. Therefore
        the manual only exists as a series of standalone pages with
        cross references. This makes it easier to keep the manual up
        to date by distributing new / updated pages as required. At
        present this is a "manual" process (no pun intended), but it
        masy one day be automated.

</code> **SEE ALSO** <code>
        HELP(1) -- General help system.

</code>
----
==== MAXFRAME ====
<code>MAXFRAME(1)             XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        MAXFRAME -- Display / Set port MAXFRAME value.

</code> **SYNOPSIS** <code>
        MAX[FRAME] <port> [n]

</code> **AVAILABILITY** <code>
        MAXFRAME is a sysop-only command.

</code> **DESCRIPTION** <code>
        The MAXFRAME command is used to display and set the AX25 L2
        MAXFRAME (window) value for the specified port.  This is the 
        maximum number of unacknowledged frames allowed before the 
        link must stop and wait for an ack.  The normal range is 
        between 1 and 7, although maxframes of up to 127 are allowed 
        in modulo-128 links.

        If the second argument is ommitted, the current value is 
        displayed.

        If the setting is changed, the new setting remains in force 
        until it is changed again, or until the router is restarted, 
        in which case it returns to the default value specified in the 
        port entry in the XROUTER.CFG file.

        If the port PACLEN is set to 0, XRouter dynamically adapts
        MAXFRAME (and PACLEN) to the link conditions, to maximise
        throughput.

</code> **EXAMPLE** <code>
        MAX 2       - Display current maxframe setting for port 2
        MAX 2 6     - Set maxframe for port 2 to 6.

</code> **SEE ALSO** <code>
        MAXFRAME(7)    -- Maximum Unacked AX25 Frames.
        PACLEN(1)      -- Display / Set Maximum Packet Length.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MHCLEAR ====
<code>MHCLEAR(1)             XROUTER REFERENCE MANUAL              23/1/2013
</code> **COMMAND** <code>
        MHCLEAR -- Clear MHeard list 

</code> **SYNOPSIS** <code>
        MHC[lear] <portnum>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The MHCLEAR command clears the MH list for the specified port, 
        and would typically be used if the radio had been changed from 
        one frequency to another.  If <portnum> is zero, all MH lists 
        are cleared.

</code> **EXAMPLE** <code>
        MHC 3  -- Clears port 3 MHeard list

</code> **SEE ALSO** <code>
        MHEARD(1)      -- List Recently Heard Stations
        MHFLAGS(1)     -- MHeard configuration flags
        MHSIZE(1)      -- Adjust size of MHeard list
        MHEARD(7)      -- Mheard enable/size directive.
        MHEARD(9)      -- "Monitor Heard".
 
</code>
----
==== MHEARD ====
<code>MHEARD(1)             XROUTER REFERENCE MANUAL               21/9/2023
</code> **COMMAND** <code>
        MHEARD -- List recently heard stations.

</code> **SYNOPSIS** <code>
        MH[eard] [nodecall] <portnum | ALL>

</code> **AVAILABILITY** <code>
        The MHEARD command is available to all users.

</code> **DESCRIPTION** <code>
        If the facility is enabled on the specified port, the MHEARD 
        command lists the most recently heard stations on that port, 
        along with the date / time of reception, the number of frames
        heard, and various other information (see below).

        This is useful for users to discover who else the router can 
        hear, to aid the search for suitable digipeaters, and to 
        diagnose problems.  Even on linking-only ports, where there is 
        only usually one partner, it provides a useful indication when 
        the frequency is being encroached, either by deliberate 
        squatting, unauthorised attempts to link, or lift conditions.

        The command may be abbreviated to "MH".

</code> **OPTIONS** <code>
        A <portnum> of zero lists the ports which have MH enabled.

        If the first argument is the callsign or alias of a known
        node, the MHeard list of that node is requested, provided the
        target node is XRouter v502s or later. In this case, the
        second argument specifies the port number on the target node.
        If a second argument is not supplied, or is 0 (zero), the
        MHeard-enabled ports on the target node are listed.

        If <portnum> is replaced by the word "ALL", e.g. "MH ALL" or
        "MH KIDDER ALL", the response is a single MHeard list,
        containing up to 100 entries from all MH-enabled ports, with
        the most recently heard at the start of the list

</code> **EXAMPLES** <code>
        MH 3          - Display heard list for port 3 on this node
        MH ALL        - Display heard list for all ports on this node
        MH KIDDER 16  - Display heard list for port 16 on KIDDER node
 
        G8PZT:KIDDER} Heard list for port 3:
        Callsign  Date  Time Frames  Via     Type  Position  Dist Dir
        G1LOA-10  09/06 13:42   309          DNIA  5221.51N... 13  24     
        G3TQG-2   09/06 13:19   599          D
        GB7PZT-15 09/06 13:18   708
        DY25      09/06 10:19   4    GB7DY-1  N

        Date     - Date when this callsign was last heard.
        Time     - Time when this callsign was last heard.
        Frames   - Total no. of frames heard from this callsign.
        Via      - Digipeater relaying this station, direct if blank.
        Type     - Flags as follows:
                   D - This station is a digipeater
                   N - This station is a node
                   I - This station handles IP traffic
                   A - This station handles ARP traffic
        Position - Position derived from APRS broadcast
        Dist     - Distance calculated from APRS broadcast
        Dir      - Bearing in degrees, calculated from APRS broadcast

</code> **FILES** <code>
        For each port, the MH facility can be enabled / disabled and 
        the maximum length of the list specified by appropriate 
        entries in the PORT sections of the XROUTER.CFG file,
        e.g. "MHEARD=15" - Sets MH list size 15
             "MHEARD=0"  - Disables MH list

</code> **SEE ALSO** <code>
        MHCLEAR(1)     -- Clear MHeard list
        MHFLAGS(1)     -- MHeard configuration flags
        MHSIZE(1)      -- Adjust size of MHeard list
        MHEARD(7)      -- Mheard enable/size directive.
        MHEARD(9)      -- "Monitor Heard".
        XROUTER.CFG(8) -- Main Configuration File.  

</code>
----
==== MHFLAGS ====
<code>MHFLAGS(1)            XROUTER REFERENCE MANUAL              18/10/2023
</code> **COMMAND** <code>
        MHFLAGS -- Display / Set MHeard options.

</code> **SYNOPSIS** <code>
        MHF[lags] <port> [0-255]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The MHFLAGS command is used to display and/or set the 
        MHEARD options for a specified port.  These flags control
        which callsigns are recorded in the MH list.

        New settings override those read from the XROUTER.CFG file,
        and remain in force until changed, or the system is restarted.

        The minimum abbreviation of this command is MHF.

</code> **OPTIONS** <code>
        The argument to MHF[lags] is the sum of the required options
        from this list:
 
           1   Record directly heard stations
           2   Record directly heard digipeaters
           4   Record digipeated stations
           8   Record direct/digipeated separately for each station
          16   Preserve MHeard list across reboot

        The default is 255 (record everything).

</code> **EXAMPLES** <code>
        MHF 3      Enquire current MHFLAGS setting for port 3
        MHF 4 1    On port 4, show directly heard stations only

</code> **SEE ALSO** <code>
        MHCLEAR(1)     -- Clear MHeard list.
        MHEARD(1)      -- List recently heard stations.
        MHSIZE(1)      -- Adjust size of MHeard list.
        MHEARD(7)      -- MHeard size/enable directive
        MHFLAGS(7)     -- MHeard option flags directive.
        XROUTER.CFG(8) -- Main Configuration File.
        MHEARD(9)      -- About "Monitor Heard".

</code>
----
==== MHSIZE ====
<code>MHSIZE(1)               XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        MHSIZE -- Adjust size of MHeard list.

</code> **SYNOPSIS** <code>
        MHS[ize] <portnum> [slots]

</code> **DESCRIPTION** <code>
        If MHEARD is enabled on the specified port, the MHSIZE 
        command allows the size of the table to be displayed or
        changed. The command may be abbreviated to "MHS".

</code> **OPTIONS** <code>
        When used without the [slots] argument, MHSIZE displays the
        current size of the MHeard table for the specified <portnum>

        If [slots] is supplied, the size of the MHeard table for the
        specified <portnum> is changed to that value.

</code> **EXAMPLES** <code>
        MHS 4        <-- show size of port 4's table

        MHS 4 25     <-- Set port 4's table to 25 slots

</code> **NOTE** <code>
        If the table is made larger, existing entries are retained.
        If it is made smaller, the oldest entries are discarded.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        MHEARD(9)      -- "Monitor Heard".
        XROUTER.CFG(8) -- Main Configuration File.  

</code>
----
==== MINQUAL ====
<code>MINQUAL(1)              XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        MINQUAL -- Display / Set port minimum quality

</code> **SYNOPSIS** <code>
        MIN[qual] <port> [0-255]

</code> **DESCRIPTION** <code>
        The MINQUAL command is used to display and set the Net/rom 
        minqual (Minimum Quality) value for the specified port.

        Within nodes broadcasts received on that port, any node
        whose quality (after derating by port QUALITY) is less than
        the minqual will not be accepted into the nodes table.

        If the setting is changed, the new setting remains in force 
        until it is changed again, or until the router is restarted, 
        in which case it returns to the default value specified in
        the port entry in the XROUTER.CFG file.

</code> **OPTIONS** <code>
        If the second argument is omitted, the current value for
        the specified port is displayed.

</code> **EXAMPLES** <code>
        MIN 2      - Display current setting for port 2
        MIN 2 30   - Set minqual for port 2 to 30.

</code> **FILES** <code>
        The MINQUAL value for a port is usually specified in the PORT
        configuration block within XROUTER.CFG. If not specified, it
        defaults to 10.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        QUALITY(1)     -- Display / set port Quality
        MINQUAL(7)     -- Minimum NetRom Quality Directive.
        MINTXQUAL(1)   -- Display / set minimum quality to transmit
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MINTXQUAL ====
<code>MINTXQUAL(1)            XROUTER REFERENCE MANUAL            25/9/2023
</code> **COMMAND** <code>
        MINTXQUAL -- Display / Set minimum quality to transmit

</code> **SYNOPSIS** <code>
        MINT[xqual] <port> [0-255]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The MINTXQUAL command is used to display and set the minimum
        Net/rom node quality to transmit on the specified port.

        This would typically be used to limit the size of nodes
        broadcasts on ports which are severely bandwidth limited, or
        when the neighbour nodes have limited table capacity.

        The neighbours could of course limit their table size using
        their MINQUAL, but there is no point in transmitting
        information which will be discarded.

        If the setting is changed, the new setting remains in force 
        until it is changed again, or until the router is restarted, 
        in which case it returns to the default value specified in
        the port entry in the CFG file.

</code> **OPTIONS** <code>
        If the second argument is omitted, the current value is 
        displayed.

</code> **EXAMPLES** <code>
        MINT 2      - Display current setting for port 2
        MINT 2 30   - Include only the nodes with quality >= 30

</code> **FILES** <code>
        The MINTXQUAL value for a port is usually specified in the
        PORT configuration block within XROUTER.CFG. If not
        specified, it defaults to 0, i.e. no minimum.

</code> **SEE ALSO** <code>
        MINQUAL(1)     -- Display / Set port minimum quality
        MINTXQUAL(7)   -- Minimum Quality to Transmit.
        QUALITY(1)     -- Display / Set default quality.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MMASK ====
<code>MMASK(1)                XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        MMASK -- Select which protocol(s) to monitor (trace)

</code> **SYNOPSIS** <code>
        MM[ASK] [0 - FFFFh]

</code> **AVAILABILITY** <code>
        The MMASK command is available only to console and remote 
        sysops.

</code> **DESCRIPTION** <code>
        The MMASK command selects which protocol layers will be 
        monitored when traffic tracing is enabled on the current
        console.

        The optional argument is a HEX number between 0000h and FFFFh, 
        which is calculated by adding together the desired values from 
        this table:

           0001 - Incoming frames          0100 - TCP
           0002 - Outgoing frames          0200 - UDP
           0004 - Data payloads            0400 - KISS
           0008 - AX25 layer 2             0800 - SLIP/PPP
           0010 - Net/Rom                  1000 - Ethernet
           0020 - ARP                      2000 - PASSALL
           0040 - IP frames                4000 - Hex Dump
           0080 - ICMP

        If no argument is supplied, the current setting is reported.

        The default setting for the first console is 03FF, which 
        displays all incoming and outgoing traffic from AX25 layer 2 
        upwards. The settings for each console are independent.

        This command duplicates the function of the <F4> key.

        The console can override a remote sysop's settings.

        The PASSALL option enables frames which fail the validity 
        checks at one layer (e.g. KISS checksum) to be passed to the 
        next layer above for tracing.

</code> **EXAMPLES** <code>
        MMASK 0101  -  display incoming TCP frames only, 
        MMASK 0142  -  display outgoing TCP and IP frames.

</code> **LIMITATIONS     ** <code>
        Remote sysops cannot trace activity on the port on which they 
        are uplinked

</code> **NOTE** <code>
        Remote sysops must ensure that their link with the router is 
        capable of carrying the large volume of traffic resulting from 
        tracing.  Attempting to trace too many ports / too much detail 
        on a slow link may result in poor performance.  You have been 
        warned!

</code> **SEE ALSO** <code>
        MONITOR(1) -- Enable / disable monitoring.
        MPORT(1)   -- Select port(s) to monitor.
        MTO(1)     -- Selective monitoring

</code>
----
==== MONITOR ====
<code>MONITOR(1)              XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        MONITOR -- Enable / disable traffic monitoring (tracing)

</code> **SYNOPSIS** <code>
        MON[ITOR] [on | off]
        MON[itor] IDS [on | off]

</code> **AVAILABILITY** <code>
        Console and remote sysops only.

</code> **DESCRIPTION** <code>
        The MONITOR command is primarily used to enable or disable
        the display  of incoming and outgoing traffic.

        The optional argument may be "ON", "OFF" or "IDS".  The
        first enables the display, the second disables it, and the
        third controls Intrusion Detection System monitoring.  If no 
        argument is supplied, the current setting is reported.

        If used at the console, this command enables and disables 
        tracing to the current console window, and works in
        conjunction with the <F2> (monitor toggle) key.

        If used by a remote sysop, there's a chance that the volume   
        of monitored data could overload the link, so the MPORT
        setting is cleared every time monitoring is enabled. The
        sysop must then issue the MPORT command to  select which
        port(s) to monitor.

        The MON IDS [on | off] sub-command controls IDS monitoring as
        follows:

        If MON is ON *and* MON IDS is ON, IDS warnings are echoed to
        the console (or remote monitoring session if you are logged
        on remotely). This allows you to keep an eye on the IDS while
        doing other things.

        This was mainly intended for use on remote monitorng
        sessions, so the default for a *remote* monitor session is
        ON. The default for consoles is OFF.

</code> **EXAMPLES** <code>
        MON ON     - Enable tracing.
        MON OFF    - Disable tracing.
        MON IDS    - Show current state
        MON IDS ON - Enable IDS warnings

</code> **LIMITATIONS** <code>
        To prevent infinite recursion, remote sysops are prevented
        from tracing activity on the port on which they are uplinked.
        This is not entirely foolproof, especially where the egress
        port may be uncertain (e.g a netrom or tunneled connection).

</code> **NOTE** <code>
        Remote sysops must ensure that their link with XRouter is 
        capable of carrying the large volume of traffic resulting
        from tracing.  Attempting to trace too many ports / too much
        detail on a slow link may result in poor performance.

</code> **SEE ALSO** <code>
        CAPTURE(1) -- Enable / disable tracing to disk file.
        MPORT(1)   -- Select port(s) to monitor.
        MMASK(1)   -- Select type of activity to monitor.
        MTO(1)     -- Selective monitoring

</code>
----
==== MOTD ====
<code>MOTD(1)                 XROUTER REFERENCE MANUAL            16/10/2023
</code> **COMMAND** <code>
        MOTD -- Maintain "Message Of The Day"

</code> **SYNOPSIS** <code>
        MOTD [<days> <text>] | [ @ ]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The MOTD command displays, sets or clears the "Message Of The 
        Day", which is a single line of text sent only after L2 ctext.
        If Ctext isn't sent, Motd isn't sent.

        The <days> count is decremented at midnight, and the message 
        stops being displayed when it reaches 0.  It is meant for 
        displaying urgent notifications, rally adverts etc.  Anything 
        more permanent should go in CTEXT.

</code> **OPTIONS** <code>
        If no arguments are supplied, the current MOTD (if any) is 
        displayed.

        If the first argument is "@", the current MOTD (if any) is 
        cleared.

        If two arguments are supplied, the first one should be the 
        number of days to display the message, and the second should 
        be the message itself, which can be up to 80 characters and 
        may include spaces.  A "days" count of 1 will display the
        MOTD until midnight.

</code> **EXAMPLES** <code>
        MOTD 3 WyrePak Meeting Tues 21/8 8pm Sutton Arms
        MOTD @

</code> **LIMITATIONS** <code>
        Message text may not exceed 80 characters, and 
        "days" may not exceed 32767.

</code>
----
==== MPORT ====
<code>MPORT(1)                XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        MPORT -- Select which port(s) to monitor (trace)

</code> **SYNOPSIS** <code>
        MP[ORT] [0-FFFFFFFF | p+p+p | ALL | NONE]

</code> **DESCRIPTION** <code>
        The MPORT command selects which port(s) will be monitored
        when traffic tracing is enabled.

        The optional argument is either a HEX number between 0 and
        FFFFFFFF, a list of port numbers concatenated with "+", or
        the words ALL or NONE.

        If no argument is supplied, the current setting is reported.
 
        The hex form is preferable when monitoring is to be enabled
        on many ports at once, but it only works up to port 31.
        The hex value is calculated by adding together the desired
        values from this table (see MORE INFO for details of hex
        arithmetic):

            Port HEX    Port HEX     Port HEX     Port HEX
            ---------------------------------------------------
             0    1      8   100     16  10000    24   1000000
             1    2      9   200     17  20000    25   2000000
             2    4     10   400     18  40000    26   4000000
             3    8     11   800     19  80000    27   8000000
             4   10     12  1000     20 100000    28  10000000
             5   20     13  2000     21 200000    29  20000000
             6   40     14  4000     22 400000    30  40000000
             7   80     15  8000     23 800000    31  80000000

        The P+P+P form is preferable when selecting a small number
        of ports to momitor, or when monitoring ports above 31. 

        This command duplicates the function of the <F3> key.

        When a remote sysop enables tracing, the MPORT setting is
        cleared to NONE, to avoid overloading the link with traffic
        which might otherwise prevent him from issuing further
        commands. The remote sysop must therefore always issue the
        MON ON command first, followed by the MPORT command to select
        which port(s) to monitor.

        The console can override a remote sysop's settings.

</code> **EXAMPLES** <code>
        MPORT 800  -  Trace port 11.
        MPORT 1803 -  Trace ports 12, 11, 2 and 1.
        MPORT 1+5+39 - Trace ports 1, 5 and 39

</code> **NOTES** <code>
        Port zero is a "pseudo-port" used to trace traffic coming
        and going via the operating system's TCP/IP stack. So
        "MPORT 0" traces port 0, instead of disabling tracing. You
        must use "MPORT NONE" to disable tracing - or just use
        MON OFF.

</code> **LIMITATIONS      ** <code>
        Remote sysops are prevented from tracing activity on the
        port on which they are uplinked, because this would cause
        an endless loop.

        Ports > 31 can only be traced using the P+P+P argument form.

</code> **CAVEATS** <code>
        Remote sysops must ensure that their link with XRouter is 
        capable of carrying the large volume of traffic resulting
        from tracing.  Attempting to trace too many ports or too
        much detail on a slow link may result in poor performance.

</code> **AVAILABILITY** <code>
        The MPORT command is available only to console and remote 
        sysops. It may be used in BOOTCMDS.SYS.

</code> **MORE INFO** <code>
        Hexadecimal arithmetic is based on powers of 16, and uses
        numbers 0-9 and letters A-F to represent numbers up to 15
        as follows: 

            Hex: 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
            Dec: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15

        Single "digits" are added / subtracted in the usual way,
        except for the fact that letters represent 10-15, therefore:

            The result of adding 1 and 4 is (unsurprisingly) 5
            The result of adding 4 and 8 is C (decimal 12)
            The result of subtracting 8 from F (decimal 15) is 7

        Things get more complicated when the result of a calculation
        is greater than 15, but fortunately that never happens when
        adding MPORT values.

        To create a composite MPORT value, simply add the desired
        values from each column. For example, to monitor ports 1,2,3
        6 and 7, the hex values 02, 04, 08, 40, and 80 must be added.

           02
         + 04
         + 08
         + 40  (note this is "Four zero", not "forty")
         + 80  (eight zero means "8 times 16 plus zero")
        ------
         = CE  (the decimal equivalent is (12*16)+14 = 206)
        ------

</code> **SEE ALSO** <code>
        MONITOR(1)      -- Enable / disable monitoring.
        MMASK(1)        -- Select type of activity to monitor.
        MTO(1)          -- Selective monitoring
        BOOTCMDS.SYS(8) -- Commands to Execute at Bootup.

</code>
----
==== MQTT ====
<code>MQTT(1)                 XROUTER REFERENCE MANUAL             22/2/2024

</code> **NAME** <code>
        MQTT -- MQTT Test Client / Commands.

</code> **SYNOPSIS** <code>
        MQTT <ip_address | hostname> [tcp_port]
        MQTT <nodecall | nodealias>        

</code> **DESCRIPTION** <code>
        The MQTT command is used either to initiate a client session
        with an external MQTT "broker" (server), or to send commands
        to XRouter's internal MQTT broker for test purposes.

        After successful connection to a server, the client accepts
        the following commands:

            BYE
            DISC[onnect]
            GET <topic>
            H[elp]
            PUB[lish] [-options] <topic> [text]
            PUT <topic>
            SUB[scribe] <topic>
            UNSUB[sribe] <topic>

</code> **OPTIONS** <code>
        If the argument is an ip address or host name, the optional
        second argument can be used to specify a TCP port number. If
        a port number is not supplied, the default is 1883.

        If the argument is the callsign or alias of a known XRouter,
        i.e. one that is currently in the netrom nodes table, the
        connection is made to NetRomX service 1883.
     
</code> **AVAILABILITY** <code>
        Sysop-only.
   
</code> **SEE ALSO** <code>
        MQTT-CLI(9)  -- MQTT Client
        MQTT-SRV(9)  -- MQTT Server / Broker.

</code>
----
==== MTO ====
<code>MTO(1)                  XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        MTO -- Monitor frames to/from specified destination.

</code> **SYNOPSIS** <code>
        MT[o] [<callsign> | <ipaddr>[:port] | ALL | NONE]

</code> **AVAILABILITY** <code>
        Sysops-only.

</code> **DESCRIPTION** <code>
        The MTO command allows you to selectively monitor (trace)
        frames to/from a specified callsign or IP address.

        This filter is additional to any filtering provided by MPORT
        and MMASK, i.e. only frames on the specified MPORT(s), which
        match the protocol specified by MMASK, and the address
        specified by MTO will be displayed.

</code> **OPTIONS** <code>
        "MTO <callsign>" enables selective monitoring of frames to
        and from AX25 <callsign>.

        "MTO <ipaddr>[:port]" enables selective monitoring of frames
        to and from an IP address.  If a port is not specified, all
        traffic to/from that IP address is  monitored.  If port is
        specified, only TCP and UDP frames to and from the specified
        IP address are monitored, and only if the source or dest port
        match the specified one.

        "MTO ALL" disables selective tracing, allowing all packets
        on the selected port, which match the MMASK to be displayed.

        "MTO NONE" provides a quick means to cancel the existing MTO,
        and results in no packets being displayed.

</code> **EXAMPLES** <code>
        MTO g8pzt
        MTO 44.131.91.2:23

</code> **LIMITATIONS** <code>
        Only one MTO filter can be in operation on each console and
        remote sysop session at any time. Setting a new MTO cancels
        the previous one on that console or session. 

</code> **SEE ALSO** <code>
        MMASK(1)   -- Set Monitor Mask
        MONITOR(1) -- Enable / disable monitoring
        MPORT(1)   -- Set port to monitor

</code>
----
==== NAT ====
<code>NAT(1)                  XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        NAT -- Network Address Translation commands.

</code> **SYNOPSIS** <code>
        NA[t] A[dd] STATIC <local> <global> [tcp | udp | mask]
        NA[t] A[dd] OVERLOAD <loc_ip> <pub_ip> <subnet_mask>
        NA[t] D[rop] <loc_ip>[:port] [tcp | udp]
        NA[t] L[ist]

</code> **DESCRIPTION** <code>
        The NAT commands controls Network Address Translation, i.e. 
        the process whereby the IP addresses contained in datagrams 
        are manipulated to allow hosts on one network to communicate 
        with hosts on a different network.

        For example, hosts on a private intranet using unregistered 
        192.168.0.x addresses cannot communicate with hosts on the 
        wider Internet because no-one would know where to route the 
        return datagrams.  NAT basically translates the unregistered 
        addresses into registered ones and vice versa.

        PAT (Port Address Translation) manipulates TCP and UDP service 
        port numbers, for example to allow several hosts to share one 
        IP address.  The NAT commands are also used to configure PAT.

</code> **OPTIONS** <code>
        The arguments for NAT commands are as follows:

        <loc_ip>        Local private (unregistered) IP address.
        <pub_ip>        Public routable IP address.
        <port>          TCP or UDP service port number.
        <local>         <loc_ip>[:port] combination
        <global>        <pub_ip>[:port] combination
        <subnet_mask>    Bit pattern used for matching addresses.
                         e.g. 255.255.255.0

        NAT ADD adds an entry to the NAT table.  There are two forms: 
        STATIC and OVERLOAD.  STATIC is used to add static NAT and PAT 
        entries, i.e. those where there is a one-to-one mapping 
        between private and public IP addresses.  OVERLOAD is used 
        only for dynamic PAT, where several hosts share one public IP 
        address.

        NAT DROP removes an entry from the NAT table.

        NAT LIST lists the NAT table entries.

</code> **EXAMPLES** <code>
        NAT ADD STATIC 192.168.0.2:87 44.131.91.2:23 tcp
        NAT ADD OVERLOAD 192.168.0.0 44.131.91.3 255.255.255.240
        NAT DROP 192.168.0.5:23 tcp

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **FILES** <code>
        The NAT ADD commands are usually used in IPROUTE.SYS, but
        may also be used in BOOTCMDS.SYS.

</code> **SEE ALSO** <code>
        NAT(9) -- Network Address Translation

</code>
----
==== NETMASK ====
<code>NETMASK(1)            XROUTER REFERENCE MANUAL               25/9/2023
</code> **COMMAND** <code>
        NETMASK -- Display / Set Port NETMASK.

</code> **SYNOPSIS** <code>
        NE[tmask] <port> [value]

</code> **AVAILABILITY** <code>
        This command is sysop-only.

</code> **DESCRIPTION** <code>
        This command allows the NETMASK for the specified port to be
        displayed or changed.

        The NETMASK is used together with the port IPADDRESS to
        specify the range of IP addresses that are on the same
        physical network segment as XRouter. If XRouter sees any
        datagrams with a destination address within that range, and
        not addressed to itself, it will not attempt to route them.

        For example, if the NDISXPKT driver is being used, XRouter
        and Windows will have different IP addresses, but will share
        the same Ethernet address. Thus both XRouter and Window "see"
        the same datagrams. Without a suitable NETMASK value, XRouter
        would attempt to route any datagram not addressed to itself,
        which means it would attempt to route any datagrams that are
        addressed to the Windows IP address.

        The netmask is specified in dotted-quad form, for example
        "255.255.255.0". Any non-zero bit within the netmask
        specifies that the corresponding bit in the IP address should
        be non-zero. Any zero bit specifies that the corresponding
        bit in the IP address may be zero or one. e.g. if the port IP
        address is "192.168.0.11", and the netmask is "255.255.255.0",
        XRouter will process datagrams addressed to "192.168.0.11" but
        will ignore datagrams addressed to any other 192.168.0.x
        destination (where x represents a number between 0 and 255).

        The default value for NETMASK is "0.0.0.0", which disables the
        function. 

        The minimum abbreviation for this command is "NE".

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, and it is a valid
        port number, the current NETMASK for that port number is
        displayed.

        If two numeric arguments are supplied, the first specifies a 
        port number and the second specifies a new NETMASK for that
        port.

</code> **EXAMPLES** <code>
        NET 1                 - Display current NETMASK for port 1.
        NET 2 255.255.255.0   - Set port 2 NETMASK to "255.255.255.0"

</code> **SEE ALSO** <code>
        IPADDRESS(1) -- Display / Set Port IP Address.
        NETMASK(7)   -- Subnet Mask Directive.

</code>
----
==== NFTP ====
<code>NFTP(1)              XROUTER REFERENCE MANUAL                 9/9/2023
</code> **COMMAND** <code>
        NFTP -- Netrom File Transfer Server / Client.

</code> **SYNOPSIS** <code>
        NF[tp] <target>

</code> **AVAILABILITY** <code>
        Client is sysop-only. Server is open to all.

</code> **DESCRIPTION** <code>
        The NFTP command invokes either the NFTP client or the NFTP
        server, depending on <target>.

        NFTP is used to exchange files with other sysops, over the 
        Netrom network.

</code> **OPTIONS** <code>
        1) If <target> is the callsign or alias of the node where the
        user is logged on, it invokes the local NFTP server at that
        node. This mode is available to non-sysops, and uses fairly
        standard FTP server commands, such as LIST, STOR, RETR etc.

        2) If <target> is the callsign, alias or amprnet IP address of
        any other node, and the user is a verified sysop, it invokes a
        client which connects to the target server.

        The client uses standard FTP client commands such as DIR, GET,
        PUT etc. Most commands may be abbreviated. The full command
        list is shown below:

          ?           abort       ascii       binary      bye
          cd          cdup        close       dir         delete
          get         hash        help        lcd         ldel
          ldir        ls          list        lmkdir      lpwd
          lrmdir      lren        lview       mkdir       modtime 
          nlist       open        put         pwd         quit 
          restart     recv        rename      rmdir       send 
          status      user        verbose     view 

        Most of these commands should be familiar to FTP users.

        Typing "HELP <cmd>" gives specific help and syntax for <cmd>
        NFTP>

</code> **NOTES** <code>
        The NFTP client has full access to the local system, so is
        available only to verified sysops. A sysop connection via
        44-net is not considered secure enough to use the client.

        The client uses a "standard" L4 connection to the server,
        rather than an "extended" (NetRomX) one. This results in a
        rather clumsy connection sequence, but allows other software
        authors to incorporate NFTP, if they so desire, without
        needing to implement L4X.  The next version of XRLin/XRPi will
        use L4X if the target node supports it, otherwise it will use
        normal L4.

        A typical usage scenario would be like this:

        Sysop ALICE is chatting with sysop BOB on XR sysop chat.
        She wants his help, because her TUN interface doesn't work.

        Bob says "send me your XROUTER.CFG and I'll have a look".

        Alice types "NFTP BOB", then "PUT XROUTER.CFG" to send it,
        informing BOB via the chatserver.

        BOB studies Alice's file, but sadly can't find the error.

        Meanwhile sysop CHARLES has downloaded the file from BOB,
        and spots the error. He corrects it and uses "NFTP ALICE",
        then "PUT XRNEW.CFG" to send it back to ALICE.

        BOB downloads the new file and is enlightened. ALICE copies it
        from FTP/public to her XRPI working directory and reboots. The
        TUN interface now works. CHARLES is a genius!

        CHARLES writes a useful HOWTO about the TUN interface, and
        uploads it to ALICE's public directory, from where DICK, EDDIE,
        FRANK etc can download it.

        No-one needed to know anyone else's email address. No-one
        needed to copy files from their node machine to an email
        machine and back. There was no need to set up accounts and
        passwords. No-one had privileged access to anyone elses
        machine. It could all be done from XRouter's console.
   
</code> **SEE ALSO** <code>
        FTP(1)      -- FTP client
        NFTP-SRV(9) -- Netrom File Transfer Protocol Server
       
</code>
----
==== NODESINT ====
<code>NODESINT(1)            XROUTER REFERENCE MANUAL              25/9/2023
</code> **COMMAND** <code>
        NODESINT -- Display / Set global or port NODESINTERVAL.

</code> **SYNOPSIS** <code>
        NODESI[nt] <port | 0> [value]

</code> **AVAILABILITY** <code>
        This command is sysop-only.

</code> **DESCRIPTION** <code>
        The NODESINT command allows the global and port-specific
        NODESINTERVAL settings to be displayed or changed.

        The NODESINTERVAL is the number of minutes between NetRom
        nodes broadcasts, as specified in XROUTER.CFG. The default
        is 60 minutes.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, and it is a valid
        port number, the current NODESINTERVAL for that port number
        is displayed.

        If two numeric arguments are supplied, the first specifies a 
        port number and the second specifies a new NODESINTERVAL for 
        that port only.

        If the first argument is zero, the command displays and sets
        the global NODESINTERVAL. This value is inherited by all
        ports, except those with a port-specific value.

</code> **EXAMPLES** <code>
        NODESINT 0        - Display global NODESINTERVAL
        NODESINT 0 30     - Set global NODESINTERVAL to 30 minutes
        NODESINT 10 60    - Set port 10 NODESINTERVAL to 60 minutes

</code> **SEE ALSO** <code>
        NODESINT(7)    -- Nodes Broadcast Interval.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== NODES ====
<code>NODES(1)                XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        NODES -- Display / Modify the Nodes table.

</code> **SYNOPSIS** <code>
        N[odes] [nodecall]
        N[odes] +
        N[odes] *
        N[odes] > <qual>
        N[odes] < <qual>
        N[odes] A[dd] <call>[:alias] <via_call> <port> <qual> [!]
        N[odes] B (y) <nodecall>
        N[odes] C (allsign)
        N[odes] D[rop] <nodecall>
        N[odes] F (rames)
        N[odes] H (ops)
        N[odes] HE[lp]
        N[odes] I (paddr
        N[odes] J (BPQ)
        N[odes] N (etrom) 
        N[odes] O (bsolete)
        N[odes] P (osition)
        N[odes] Q (ueue)
        N[odes] R (tt)
        N[odes] S (tats)
        N[odes] T (imes)
        N[odes] V (ia) <nodecall>
        N[odes] X (router)

</code> **DESCRIPTION** <code>
        The NODES command is used to list the contents of the Netrom
        nodes table in a variety of diferent ways, according to the
        format of the command.

        Sysops may also use the command to add and delete nodes.

        Nodes may be listed in callsign or alias order, and wildcard
        searches may be performed on either field.

        The display may be restricted to those nodes whose NetRom
        quality is greater or lesser than a specified figure, or to
        those who are netrom-only, time-only, obsolete and so on.

        Or the sysop may choose to display only those nodes for whom
        an IP address or round trip time is known, or those who have
        frames waiting, or those who have non-zero counters.

        The command may also be used to find which nodes are routed
        via which neighbour node. 

</code> **OPTIONS** <code>
        N           List all nodes, excluding "hidden" ones
        N *         List all nodes, including hidden ones
        N +         List nodes with both time and qual metrics valid
        N > <qual>  List nodes whose NetRom Quality exceeds <qual>
        N < <qual>  List nodes with NetRom Quality less than <qual>
        N <call>    List information and routes to target <call>
        N A[dd]     Add a node to the table (sysop only)
        N B <call>  List nodes advertised by neighbour <call>
        N C         List nodes by callsign instead of in alias order
        N D[rop]    Remove a node from the table (sysop only)
        N F         List nodes with a non-zero "Frames" count
        N H         List nodes with a non-zero Hop count
        N HE[lp]    Display subcommands and brief descriptions
        N I         List nodes which have an IP address
        N J         List nodes which might be BPQ
        N N         List nodes whose only usable metric is Netrom
        N O         List only Obsolete nodes
        N P         List nodes whose position is known
        N Q         List nodes which currently have frames queued
        N R         List nodes for whom a RTT count is known
        N S         List nodes with a position, RTT or frame count 
        N T         List nodes whose only usable metric is Trip Time
        N V <call>  List nodes for whom preferred route is via <call>
        N X         List confirmed XRouter nodes

</code> **DETAIL** <code>
        When used without arguments, this command lists all the NetRom 
        nodes (but not KA nodes) known to XRouter, except those 
        "hidden" nodes whose alias begins with the hash (#) character.

        If the argument is an asterisk (*), all nodes, including 
        "hidden" nodes will be displayed.

        If the argument is a known node call or alias (e.g. N MLVN),
        the preferred route to the specified node, and up to two
        alternative routes will be displayed. Other information, such
        as the position (in APRS format) and IP address will be
        displayed if known. The response looks like this:

            G8PZT:KIDDER} Nodes:
            Info for: MLVN:G4FPV  FR=3538  RTT=2.8  Q=0  Hop=1 {PEER}
              Pos=52.2321N 2.0213W Loc=IO82QJ Qth=Malvern
              IP=44.131.92.50/32  TCP=23
              Supports: INP3 L3ROUT NRR NCMP L4X NDP PMS XRCHAT RTCHAT
              Updated: 18/10 14:43  Confirmed: 16/10 13:23

            Routes to: MLVN:G4FPV
              Qty Obs Pt Via      Stt Hop Obs2
            > 150  5   5 G4FPV   1.22  1   4 <
              110  5   9 GB7GH
                0  4   2 G1DKI-7

        Not all the above fields may be present, and additional
        fields may be displayed if available. The following
        information may be displayed after the callsign:

            "FR"  indicates the number of level 3 frames sent to that
                  node.

            "RTT" (Round Trip Time) is a running average of the time
                  (in seconds) taken to get a response from the node.

            "Q"   is the number of Level 3 frames currently queued
                  for that destination.

            "Hop" is the number of hops to the node (if known)

            "XR"  indicates that the node is known to be an XRouter.

            "PEER" indicates that the node is the nearest XRouter
                   via the route.

            "HOST" indicates that the node has a command line and may
                   host additional services, such as BBS, PMS, CHAT
                   etc.

            "PMS" indicates that the target is a Personal Message
                  System.

            "XRCHAT" indicates that the target is an XRouter chat
                     server.

        Subsequent lines may display the following:

            Pos=       Latitude and longitude
            Loc=       Maidenhead locator code
            Qth=       Location
            IP=        Amprnet IP address (if enabled)
            TCP=       TCP port for access via amprnet
            v502y      Software version
            Updated:   Date and time last seen in a broadcast
            Confirmed: Date and time confirmed by probe response
            Supports:  Some of the supported capabilities:
                       INP3    - INP3 routing information protocol
                       L3ROUT  - NetRom layer 3 routing
                       NRR     - NetRom Record Route
                       NCMP    - NetRom Control Message Protocol
                       L4X     - Extended L4 (NetRomX)
                       NDP     - NetRom Datagram Protocol
                       PMS     - Personal Mesaage System
                       XRCHAT  - XRouter chat system
                       RTCHAT  - RoundTable chat system

        In the "Routes To" section:

            ">"   in the left-most column indicates the currently 
                  active route.

            "Qty" is the overall NetRom path quality to the node.

            "Obs" is the NetRom "obsolescence count", which shows how
                  how recently the route was heard about or used.  It
                  is usually reset to OBSINIT (usually 5) upon being
                  seen in a nodes broadcast from the neighbour node,
                  and decrements by one every time XRouter makes a
                  node broadcast (typically once per hour). If it
                  drops below OBSMIN (usually 3) the route is
                  considered to be obsolete. 

            "Pt"  is the port number for the neighbour. 

            "Via" is the neighbour node via which the target is
                  reached.

            "Stt" is "Smoothed Trip Time", which is the average
                  one-way transit time to the neighbour in seconds.
                  This field may not be present in all cases.

            "Hop" is the total no. of hops to the target via this
                  neighbour. It is one more than the number of
                  intermediate nodes. This field may not always be
                  available.

            "Obs2" is the obsolescence count for the time domain
                   information (Stt & hops) which is learned via
                   INP3. This info is maintained independently of
                   NetRom "quality" metrics. A node may have obsolete
                   quality metrics, but still have valid temporal
                   metrics.
  
            "<"   indicates the preferred route, which may differ
                  from the route actually used at that instant.

        If the requested nodecall or alias is not in the table, an 
        error message results.

        If the specified callsign or alias contains wildcards, a list
        of matching nodes will be displayed.

        "N A[add]" adds a node callsign to the table. Mandatory fields
         are <call>, <via_call>, <port> and <qual>. Optional fields
         are [alias] and lock flag [!].

        "N B <call>" displays the list of nodes "advertised" by
        <call>, i.e. those nodes the neighbour claims to be able to
        reach. This is not necessarily the same as the nodes *routed*
        via that neighbour, because some of the nodes may be
        advertised with better metrics by other neighbours.

        "N C" displays nodes in callsign order instead of the standard
        alias order. If you wish the nodes to be displayed in callsign
        order by default, use SORTBYCALL=1 in XROUTER.CFG.

        "N D <call>" drops (removes) a node from the table.

        "N F" displays nodes with a non-zero "Frames" count. The frame
        count is only available for nodes with to whom XRouter has
        routed some traffic.

        "N H" lists the nodes which have a non-zero "hop" count. This
        hop count is derived from actual measurements, rather than the
        "hypothetical" count derived from INP3, and is available for
        only a few nodes at most.

        "N I" displays the nodes which have an amprnet IP address.
        In practice this list is likely to contain only XRouter and
        X(Net) nodes.

        "N J" displays the nodes which MIGHT be BPQ. This information
         is currently only available for nodes which have routed some
         traffic via XRouter.

        "N N" displays the nodes whose only usable metric is NetRom
        quality, i.e. those for whom a trip time is unknown or has
        gone obsolete.

        "N O" lists the "obsolete" nodes, i.e. those for whom all
        metrics are too "stale" to be used. These nodes are probably
        off-line or otherwise unreachable.

        "N P" lists the nodes whose position is known. In practice,
        the only nodes which curently show in this list will be
        XRouters.

        "N Q" displays the nodes which currently have frames waiting
        to be delivered to them. The queues may be the result of
        link bottlenecks, and the figure is likely to change rapidly.

        "N R" displays the nodes for whom a Round Trip Time is known.
        This is an averaged value for all connections between XRouter
        and the target node, and may differ from the current
        "hypothetical" trip time, derived from INP3 information. This
        RTT is only available for nodes which XRouter has connected
        to. 

        "N S" displays the nodes for whom some "stats" are known, i.e.
        position, Round Trip Time or frame count.

        "N T" lists the nodes whose only usable metric is Time, i.e.
        those which have a valid trip time, but for whom the NetRom
        quality is unknown or is considered obsolete.

        "N V <call> displays the nodes who would be routed via
        neighbour <call> at the current instant. This choice may
        change with time, as the metrics fluctuate.

        "N X" lists the nodes known to be XRouter. This may not show
         ancient versions of XRouter.

</code> **EXAMPLES** <code>
        N           - List nodes except those beginning with #
        N *         - List nodes including those beginning with #
        N MLVN      - Display routes to MLVN node
        N V VK2DOT  - Display nodes routed via VK2DOT
        N > 100     - Display nodes with qualities greater than 100

</code> **AVAILABILITY** <code>
        The NODES command is available to all users, but the ADD and
        DROP sub-command are sysop-only.

</code>
----
==== NPING ====
<code>NPING(1)                XROUTER REFERENCE MANUAL            25/10/2023
</code> **COMMAND** <code>
        NPING -- Send a Netrom echo request

</code> **SYNOPSIS** <code>
        NP[ing] <nodecall | nodealias> [bytes [secs]]

</code> **DESCRIPTION** <code>
        The NPING command sends an NCMP (Network Control Message 
        Protocol) echo request to the specified target system.

        If the target understands NCMP, a reply is returned,
        allowing the round-trip-time and number of hops to be
        determined.  It is intended mainly as a network diagnostic.

</code> **OPTIONS** <code>
        The command allows the user to specify an additional data 
        payload, and an interval between pings.  This can be used to 
        assess the consistency of link performance.

</code> **EXAMPLES** <code>
        nping gb7gc
        G8PZT:KIDDER} NPING: hit <RETURN> to quit...

        Pinging gb7gc with 0 bytes of data:

        GB7GC: echo reply - rtt 17985 msec, 3 hop(s)


        nping  gb7gc 10 20
        G8PZT:KIDDER} NPING: hit <RETURN> to quit...

        Pinging gb7gc with 10 bytes of data:

        Target             Interval   Sent   Rcvd   %  Ave Rtt
        GB7GC                 20020      1      1  100 5170
        GB7GC                 20020      2      2  100 6930
        GB7GC                 20020      3      3  100 6765

</code> **LIMITATIONS** <code>
        NCMP is under development and is currently implemented only
        in XRouter, so you can only NPING another Xrouter at present.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        NRR(1)      -- Netrom Record Route.
        NTRACERT(1) -- NetRom TraceRoute.
        NCMP(9)     -- NetRom Control Message Protocol.

</code>
----
==== NRR ====
<code>NRR(1)                  XROUTER REFERENCE MANUAL            25/10/2023
</code> **COMMAND** <code>
        NRR -- Netrom Record Route

</code> **SYNOPSIS** <code>
        NRR <nodecall | nodealias>

</code> **DESCRIPTION** <code>
        This command sends a "record route" packet to the specified 
        netrom target system.  It the target is NRR-capable (e.g. 
        Xrouter, Xnet, Flexnet?), the packet is returned otherwise
        the packet is ignored by the target.

        Each NRR-capable router along the path inserts its own 
        callsign into the packet, and these are displayed when the 
        reply is received.  Non-capable systems are shown by a 
        question mark "?".  The target is marked by a "*" and both
        the outgoing and return routes are displayed because they may 
        differ.

</code> **EXAMPLE** <code>
        nrr gb7gc

        G8PZT:KIDDER} Request sent
        Route reply:  G8PZT ? GB7GC* ? G8PZT

</code> **LIMITATIONS** <code>
        Targets which are not NRR-capable (e.g. BPQ, TheNet, FPAC,
        LinuxNode, JNOS, TNOS) will not respond to probes.

        As of 2013, BPQ32 systems do NOT respond to NRR requests,
        although they do correctly handle in-transit NRR traffic.

</code> **SEE ALSO** <code>
        NPING(1)    -- Send NetRom Echo Request(s).
        NTRACERT(1) -- NetRom TraceRoute.
        NCMP(9)     -- NetRom Control Message Protocol.

</code>
----
==== NTRACERT ====
<code>NTRACERT(1)             XROUTER REFERENCE MANUAL            25/10/2023

</code> **COMMAND** <code>
        NTRACERT -- NetRom TraceRoute.

</code> **SYNOPSIS** <code>
        NT[racert] <nodecall> [maxhops [maxwait(ms)]]

</code> **DESCRIPTION** <code>
        The NTRACERT commmand traces the route to a NetRom node.

        It is a diagnostic tool for displaying the route to a NetRom
        target, and measuring the transit delays of packets at each
        step along the route.

        It uses the replies from a series of NCMP (Netrom Control
        Message Protocol) echo requests to produce a list of the
        nodes that the packets have passed through.

        NCMP is only understood by XRouters at present. Therefore
        only XRouter nodes show in the trace.

        3 attempts are made at each hop, thus for each hop, 3 round
        trip times are displayed, along with the nodecall at that
        hop.

        The 3 times indicate the consistency of the route. If no
        response is received from a node within the timeout
        period, a "*" is displayed in the time field.

        The operation can be aborted by sending a blank line.

</code> **OPTIONS** <code>
        <nodecall> - Callsign or alias of the target node.

        [maxhops]  - Maximum number of hops to trace (default 30)

        [maxwait]  - Maximum number of milliseconds to wait for a
                     response from each node. Default 4000 (4 secs).

        The only mandatory parameter is <nodecall>. In order to
        specify [maxwait], [maxhops] must also be specified.

</code> **EXAMPLES                                                                                           ** <code>
        NT VA2OM        - Trace to VA2OM with default parameters.
        NT G7VJA-5 10   - Trace to G7VJA-5 to a max of 10 hops.
        NT XBAL 5 20000 - Trace to XBAL, 5 hops, maxwait 20secs

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        NCMP(9)  -- NetRom Control Message Protocol.
        NPING(1) -- Send NetRom Echo Request(s).
        NRR(1)   -- NetRom Record Route.

</code>
----
==== NTTY ====
<code>NTTY(1)                 XROUTER REFERENCE MANUAL             27/9/2023

</code> **COMMAND** <code>
        NTTY -- Talk to a user or another sysop.

</code> **SYNOPSIS** <code>
        NTT[y] <nodecall | nodealias>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The NTTY command allows a sysop to have a one-to-one private
        keyboard chat with the sysop of another XRouter.

        This is not related to the "sysop chat" channel on the chat
        server. It is the NetRom equivalent of the TTYLINK command,
        and is very similar to the TALK command. It uses NetRomX
        service 87.

        The sysop of the target node has 90 seconds to respond. At
        any point during or after the 90 seconds, the caller has the
        option to leave a short one-line message (160 chars max) or
        to abort the call. Messages are saved into the sysop's PMS.

        If the target sysop takes more than 90 seconds to respond,
        and the caller has not disconnected, the target sysop can
        use the TALK command to initiate a chat with the caller.

</code> **EXAMPLES** <code>
        NTTY G8PZT-3 - Initiate chat with sysop of G8PZT-3 node
        NTTY KIDDER  - Initiate chat with sysop of KIDDER node

</code> **LIMITATIONS** <code>
        This currently only works if the target node is running
        a recent version of XRouter. Other types of node will not
        respond to the request. 

</code> **SEE ALSO** <code>
        NTTY-SVC(9) -- NetRomX TTYlink Service
        TALK(1)     -- Talk to a user or another sysop.
        TTYLINK(1)  -- Keyboard chat with another TCP/IP system.
        TTYLINK(9)  -- About TTYLINK.
        SERVICES(9) -- NetRomX Standard Services.

</code>
----
==== PACLEN ====
<code>PACLEN(1)              XROUTER REFERENCE MANUAL              25/9/2023
</code> **COMMAND** <code>
        PACLEN -- Display / Set global or port paclen values.

</code> **SYNOPSIS** <code>
        PA[clen] <port | 0> [value]

</code> **AVAILABILITY** <code>
        This command is sysop-only.

</code> **DESCRIPTION** <code>
        The PACLEN command allows the global and port-specific PACLEN 
        settings to be displayed and changed.  Paclen is the maximum 
        data field length within an AX25 or Netrom packet.

        The global PACLEN is specified (using PACLEN=n) in the L2
        global parameters section of the XROUTER.CFG file, and is
        the default value, used where not overriden by a port-specific
        paclen.  

        All frames originating at the router use the global or port 
        paclens specified, but Netrom frames originating at other 
        systems can not be fragmented, so we have no control over 
        them, and they may be larger than our paclen.

        If the port PACLEN is set to 0, XRouter dynamicallys adapts
        PACLEN (and MAXFRAME) to the link conditions, to maximise
        throughput.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, and it is a valid
        port number, the current paclen for that port number is 
        displayed.

        If two numeric arguments are supplied, the first specifies a 
        port number and the second specifies a new paclen value for 
        that port.

        If the first argument is zero, the PACLEN command displays
        and sets the global paclen.

</code> **EXAMPLES** <code>
        PACLEN 0         - Display global default paclen
        PACLEN 0 120     - Set default paclen to 120
        PACLEN 10        - Display current paclen for port 10
        PACLEN 10 160    - Set port 10 paclen to 160

</code> **SEE ALSO** <code>
        MAXFRAME(1)    -- Display / Set MAXFRAME.
        PACLEN(7)      -- Maximum Packet Length.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PCAP ====
<code>PCAP(1)               XROUTER REFERENCE MANUAL                9/9/2023
</code> **COMMAND** <code>
        PCAP -- IP Packet Capture.

</code> **SYNOPSIS** <code>
        PC[ap] [on | off]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The PCAP command controls IP packet capture. 

        If enabled, every IP datagram entering or leaving XRouter's
        IP stack is recorded to a "pcap" file in a standard format
        that can be examined with Wireshark.

        This can be useful when chasing obscure crashes or doing a
        security audit. Other node authors will no doubt use it to
        reverse-engineer XRouter's protocols, which incidentally are
        not secret, just as-yet undocumented!

        The default packet capture state is controlled by LOG_PCAP
        (bit 9, value 512) in the argument to the "LOG" command, or
        in the "LOG=" directive in XROUTER.CFG. If the bit is set by
        the LOG= directive, packet capture is on by default,
        otherwise it is off.

        Packet capture can generate huge files, especially if you are
        using FTP to transfer large amounts of data, so it is not
        recommended for long-term use.

</code> **SEE ALSO** <code>
       LOG(1)         -- Log settings command.
       LOG(7)         -- Directive to set log levels
       XROUTER.CFG(8) -- Main configuration file.

</code>
----
==== PEERS ====
<code>PEERS(1)               XROUTER REFERENCE MANUAL             25/10/2023
</code> **COMMAND** <code>
        PEERS -- Show the nearest NCMP-capable nodes.

</code> **SYNOPSIS** <code>
        PEE[rs]

</code> **DESCRIPTION** <code>
        The PEERS command displays the closest NCMP (Netrom Control
        Message Protocol)-capable neighbours, for example: 

            Nodecall   RTT  Hop  Last-cnfrmd  Last-update 
            G8PZT        0    1  26/05 04:18  26/05 04:18
            ZL2BAU-3   248    3  26/05 04:10  xx/xx xx:xx
            VK2DOT-1    31    1  26/05 04:18  xx/xx xx:xx
            G8PZT-1      6    1  26/05 03:50  26/05 03:50
            VE2PKT-4     8    1  26/05 04:17  xx/xx xx:xx
            VE3UIM-7    16    1  26/05 04:16  xx/xx xx:xx

        (For reasons of clarity, the additional fields "Latitude",
        "Longitude" and "S/ware" are not show here.)

        "RTT" is the smoothed round trip time in hundredth of a
        second, e.g "6" = 60ms. It is a running average, so it may
        show longer round trip times if traffic is heavy.

        "Hop" is the no. of hops to the peer, where "1" denotes a
        direct (netrom neighbour) link.

        "Last-cnfrmd" shows when the peer was last confirmed to be
        NCMP-capable, by the reception of any form of NCMP message
        from it. Over time, sysops may change from one brand of
        software to another, retaining the same callsign and alias.
        So it can't be assumed that a PEERS entry is valid unless
        the last-comfirmed date/time is relatively up to date. 

        "Last-update" shows the most recent time when the peer
        responded to a neighbour discovery request. 

        "S/ware" shows what software the peer is running, if known.

</code> **LIMITATIONS** <code>
        At the moment, only XRouters (XR16 / XR32 / XRLin / XRPi)
        are NCMP-capable.

        The old DOS and Windows versions of XRouter are NCMP-capable,
        so they will show up in the peers list. But they use an
        earlier version of the protocol which doesn't support the
        "last-update" feature and don't report the software version.

</code> **NOTES** <code>
        XRouter uses NCMP peers as "stepping stones" through the
        vanilla NetRom network, so that it can exchange all sorts of
        informaton that makes packet more modern, interesting and
        useful.

        If all nodes were NCMP-capable, they could pass information
        seamlessly from neighbour to neighbour. Then there would be
        no more need for neighbour discovery and the PEERS command,
        as all nodes would be peers. Like that's ever going to
        happen!

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        NPING(1)    -- Send Netrom echo request(s)
        NTRACERT(1) -- Trace route to a netrom node.
        NCMP(9)     -- NetRom Control Message Protocol.

</code>
----
==== PERSIST ====
<code>PERSIST(1)              XROUTER REFERENCE MANUAL             25/9/2023
</code> **COMMAND** <code>
        PERSIST -- Display / Set the persist value for a port.

</code> **SYNOPSIS** <code>
        PER[SIST] <port> [0-255]

</code> **AVAILABILITY** <code>
        The PERSIST command is available only to sysops.

</code> **DESCRIPTION** <code>
        The PERSIST command is used to display and set the PERSIST 
        value for a port.  This is the "probability to transmit" in a
        given time slot (see SLOTTIME), used as part of the CSMA
        channel access procedure, to minimise media contention.

        A low value is used when there are several stations sharing
        the channel, giving each a fair chance to transmit.  A high
        value can be used when the channel isn't shared.

        The optimum setting is 255/n  where n is the number of
        stations sharing the channel. The default is 64. 

</code> **OPTIONS** <code>
        If the command is used with a single numeric argument, the 
        current setting for that port number is displayed.

        If two arguments are supplied, the PERSIST value for the port 
        specified by the first is set to the value of the second. 
        The new setting remains in force until changed again or until
        XRouter is restarted, in which case the value specified in
        the XROUTER.CFG file will apply.

</code> **EXAMPLES** <code>
        PERSIST 5        - Display current PERSIST value for port 5
        PERSIST 5 64     - Set port 5 PERSIST to 64

</code> **NOTE** <code>
        On KISS ports, you should allow up to 5 minutes for a new 
        setting to become active.

</code> **SEE ALSO** <code>
        PERSIST(7)     -- AX25 Probablity to Transmit.
        SLOTTIME(1) -- Display / Set CSMA interval timer
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PING ====
<code>PING(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        PING -- Send ICMP echo request(s).

</code> **SYNOPSIS** <code>
        PING <hostname | ipaddr> [length [interval]]

</code> **AVAILABILITY** <code>
        The PING command is available to all users except guests,
        i.e. those who access from the public Internet without using
        a password.

</code> **DESCRIPTION** <code>
        Sends ICMP echo request(s) to the specified IP address or 
        hostname for the purposes of route testing.

        An optional data portion of "length" bytes may be specified, 
        and the echo request may optionally be repeated every 
        "interval" seconds.

        If there is a reply it will be displayed.  For repeating pings 
        the system displays the number sent/rcvd, the average round 
        trip time in milliseconds, and the success rate.  The "wait 
        for reply" process may be cancelled at any time by entering 
        <CR> by itself.

        If you specify a hostname (e.g. gb7pzt.ampr.org) instead of a 
        numeric IP address the request may take longer to action if 
        the hostname isn't found in DOMAIN.SYS, because the name will 
        have to be resolved by sending a DNS request.

</code> **EXAMPLES** <code>
        PING 44.131.91.2           Single ping of minimum size
        PING 44.131.91.2 50        Single ping with 50 bytes data
        PING gb7pzt                Uses DNS to resolve host.
        PING 44.131.91.2 512 10    Ping 512 bytes every 10 secs

        The response for a single ping looks like this:

           G8PZT:KIDDER} PING: Pinging 44.131.91.2: hit <RETURN> to 
           quit...

           44.131.91.2: echo reply - rtt 495 msec

        And for a repeating ping it looks like this:

           G8PZT:KIDDER} PING:
           Target             Interval   Sent   Rcvd   %  Ave Rtt
           44.131.91.2            9955      1      1  100  880
           44.131.91.2            9955      2      2  100  880
           44.131.91.2            9955      3      3  100  880

</code> **LIMITATIONS** <code>
        The router must have an IP address and have IP routing defined 
        for this command to work.  Unrealistic ping rates are 
        prevented. The run length of a repeating ping for non-sysops
        is restricted to 5 to prevent abuse.

</code> **SEE ALSO** <code>
        GPING(1) -- Globalnet Ping
        NPING(1) -- Netrom Ping 

</code>
----
==== PIPEFLAG ====
<code>PIPEFLAG(1)             XROUTER REFERENCE MANUAL             25/9/2023

</code> **COMMAND** <code>
        PIPEFLAG -- Display / Set Frame Piping Options.

</code> **SYNOPSIS** <code>
        PIPEF[lag] <port> [0-255]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The PIPEFLAG command is used to display and/or set the 
        PIPE options for a specified port.  These flags are only
        used when piping is active, and they control which frames
        are piped.

        New settings override those read from the XROUTER.CFG file,
        and remain in force until changed, or XRouter is restarted.

        The minimum abbreviation of this command is PIPEF.

</code> **OPTIONS** <code>
        The argument is the sum of the required options from this
        list:
 
             1  - UI frames *not* addressed to nodecall/alias.
             2  - Non-UI frames *not* addressed to nodecall/alias
             4  - UI frames addressed to nodecall/alias.
             8  - Non-UI frames addressed to nodecall/alias.
            16  - UI frames transmitted by XRouter.
            32  - Non-UI frames transmitted by XRouter.
            64  - Allow budlisted users to be piped.
           128  - Netrom frames
           256  - IP / ARP frames
           512  - Bi-directional piping

        The default is 3 (pipe UI and non-UI frames not addressed to
        Nodecall or Nodealias).

</code> **EXAMPLES** <code>
        PIPEF 3      Enquire current PIPEFLAG setting for port 3.
        PIPEF 4 5    On port 4, pipe received UI frames only.

</code> **SEE ALSO** <code>
        PIPE(1)        -- Display / Set Frame pipe.
        PIPEFLAG(7)    -- Frame Pipe Option Flags.
        PIPES(9)       -- About "Frame Pipes".
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PIPE ====
<code>PIPE(1)                XROUTER REFERENCE MANUAL              25/9/2023
</code> **COMMAND** <code>
        PIPE -- Display / Set "frame piping" for a port.

</code> **SYNOPSIS** <code>
        PIP[e] <port> [destport]

</code> **DESCRIPTION** <code>
        Displays the current PIPE setting for a port, and allows 
        it to be changed. Pipes "tunnel" frames from one port to
        another. Exactly which frames are piped is controlled by
        PIPEFLAG.

        If two numeric arguments are supplied, a "frame pipe" is set
        up from <port> to [destport], otherwise the current setting
        for the specified port is displayed.

        If the second argument is zero, piping is disabled.

        Modified settings remain in force until changed or system is 
        restarted.

</code> **EXAMPLES** <code>
        PIPE 3     - Display current PIPE setting for port 3
        PIPE 3 5   - Create pipe from port 3 to port 5
        PIPE 3 0   - Remove pipe from port 3.

</code> **AVAILABILITY** <code>
        Requires SYSOP status.

</code> **SEE ALSO** <code>
        PIPE(7)     -- Frame Pipe.
        PIPES(9)    -- About Frame Pipes
        PIPEFLAG(1) -- Display / Configure Piping Options

</code>
----
==== PMS ====
<code>PMS(1)                XROUTER REFERENCE MANUAL                7/9/2023
</code> **COMMAND** <code>
        PMS -- Access Personal Message System(s)

</code> **SYNOPSIS** <code>
        PM[s] [nodecall | nodealias] 

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The PMS command connects the user either to this node's
        integral PMS (Personal Message System), or to the PMS on
        another XRouter. 

        If the user accesses the PMS using the "PMS" command, he is
        returned to XRouter's main command prompt upon exit,
        otherwise he is disconnected.

</code> **OPTIONS** <code>
        If no argument is supplied, the user is connected to the
        built-in PMS.

        If the argument is the nodecall or alias of another XRouter,
        which is in the nodes table, the user is connected to the
        PMS of that node instead.

</code> **EXAMPLES** <code>
        PMS       -- Connect to the PMS on this node
        PMS G8PZT -- Connect to the PMS on G8PZT node.

</code> **NOTE** <code>
        If a command alias, or an application, with the name "PMS"
        is defined, it takes priority over the inbuilt PMS.

</code> **SEE ALSO** <code>
        PMS(9)     -- About the PMS.
        PMS-SVC(9) -- NetRomX PMS Service.
        WALL(1)    -- Message Wall / Guestbook.

</code>
----
==== PORTS ====
<code>PORTS(1)              XROUTER REFERENCE MANUAL               10/9/2023
</code> **COMMAND** <code>
        PORTS -- Display / Edit the ports.

</code> **SYNOPSIS** <code>
        P[orts]
        P[orts] A[dd] <portnum> <ifacenum> <id>
        P[orts] D[rop] <portnum>
        P[orts] L[ist]
        P[orts] S[tart] <portnum> 

</code> **DESCRIPTION** <code>
        The PORT[s] command, which may be abbreviated to "P". can
        be used to add, remove and list the communication ports.

</code> **OPTIONS** <code>
        "P[ports]" and "P[orts] L[ist]" have identical function.
        They display XRouter's port numbers along with their brief 
        descriptions as specified by the PORTID fields in the CFG 
        file.

        The "ADD" sub-command is used to create a new PORT, using
        the INTERFACE (which must already exist) specified by
        <ifacenum>, and having a PORTID specified by the <id> field.
        The new port is not operational until after a "PORT START"
        command (see below). This allows for the port parameters to
        be set up and adjusted without affecting anything else. 

        The "START" sub-command starts operations on the port. If
        anything is seriously wrong it will complain, allowing the
        configuration to be changed bfore attempting START again.

        The "DROP" sub-command stops and removes a port. 

</code> **AVAILABILITY** <code>
        The basic "PORTS" command is available to all users, but the
        ADD and DROP and START sub-commands are sysop-only.

</code> **NOTES** <code>
        The lack of a STOP sub-command is deliberate, to prevent
        ports being stopped and forgotten about.

</code> **CAVEATS** <code>
        Starting and stopping ports on a system with so many hardware
        and protocol combinations is horrendously complex. It is not
        practicable to test all combinations prior to release,
        therefore this cannot be guaranteed to be bug free. Please
        report any issues, so they can be corrected.

</code>
----
==== PPP ====
<code>PPP(1)                  XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        PPP -- Point to Point Protocol Configuration commands.

</code> **SYNOPSIS** <code>
        PPP <port> IDLE [secs]
        PPP <port> IPCP <LOCAL | REMOTE> <ADDRESS | DNS> [ipaddr]
        PPP <port> LCP <LOCAL | REMOTE> AUTH [PAP]
        PPP <port> LCP <LOCAL | REMOTE> DEFAULT
        PPP <port> LCP <LOCAL | REMOTE> MRU [mru]
        PPP <port> LOG [0-255]
        PPP <port> PAP <USER> [username password]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        Point to Point Protocol (PPP) is a protocol suite intended
        for use over simple links which transport packets between two 
        peers, such as an RS232 link.  The PPP commands are used to 
        configure the system.

</code> **OPTIONS** <code>
        The IDLE subcommand is used to display or set the PPP link 
        inactivity timer, which disconnects the link after a period of 
        inactivity.  The argument is in seconds.

        The IPCP subcommands control the IPCP (IP Control Protocol) 
        parameters for each end of the link.  ADDRESS specifies the
        IP addresses used for the link, and DNS specifies the IP 
        addresses of the Domain Name Server.  

        The LCP subcommands control the LCP (Link Control Protocol) 
        parameters for each end of the link.  AUTH specifies the 
        authentication protocol (if any) which the link will use.
        The only authentication protocol currently supported is PAP.

        The MRU command specifies the Maximum Receive Unit, i.e. the 
        largest datagram the host is prepared to accept.  The limits 
        are 128 and 4096. DEFAULT restores the default LCP parameters 
        which all hosts understand. 

        The LOG subcommand displays or sets the PPP logging level, 
        which controls how much diagnostic detail is recorded in the 
        PPLOG.TXT file.  The argument is as follows:

                0       No logging
                1       PPP start/stop/timeout events
                2       As 1, plus layer up/down events
                3       As 2, plus layer start/stop events
                4       as 3, plus option accept/reject events
                5       as 4, plus hexdump of configuration packets

        The PAP subcommand displays or sets PAP (Password 
        Authentication Protocol) parameters.  At present the only 
        parameter is USER, which specifies the username and password 
        for PAP login.

</code> **EXAMPLES** <code>
        PPP 1 IDLE 300
        PPP 1 IPCP LOCAL ADDRESS 62.31.45.67
        PPP 3 LCP LOCAL AUTH PAP
        PPP 3 LCP LOCAL DEFAULT
        PPP 3 LCP LOCAL MRU 1500
        PPP 3 LOG 3
        PPP 1 PAP USER g8pzt zedfrgc

</code> **NOTES** <code>
        When used from the command line, or with a BOOTCMDS.SYS file, 
        the first argument must be a port number.  However, PPP 
        commands used within PPPHOST and dialler scripts *do not* 
        include a port number, because XRouter knows which port is 
        executing the script.

        e.g. at the command line: PPP 3 IDLE 300
             in a dialler script: PPP IDLE 300

        You are advised against using the higher PPP LOG levels other 
        than on a temporary basis because they can create very large 
        logfiles.

</code> **SEE ALSO** <code>
        DUN(9)    -- Dial-up Networking
        PPP(9)    -- Point to Point Protocol.
        SCRIPT(9) -- Dialler script commands

</code>
----
==== QUALITY ====
<code>QUALITY(1)             XROUTER REFERENCE MANUAL              25/9/2023
</code> **COMMAND** <code>
        QUALITY -- Display / Set default quality value for a port.

</code> **SYNOPSIS** <code>
        Q[UALITY] <port> [0-255]

</code> **AVAILABILITY** <code>
        This command is only available to sysops.

</code> **DESCRIPTION** <code>
        Displays or sets the default quality for nodes heard on the 
        specified port.  It should be set to zero to suppress all 
        level 3/4 activity on a port, e.g. on user access frequencies.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current quality 
        for that port number is displayed.

        If two numeric arguments are supplied, the quality for the 
        port specified by the first is set to the value of the second.  
        The new setting remains in force until changed, or until the 
        router is restarted, in which case the setting reverts to that 
        specified in the config file.

</code> **EXAMPLE** <code>
        QUALITY 3        - Display current quality for port 3
        QUALITY 3 40     - Set port 3 default quality to 40

</code> **SEE ALSO** <code>
        QUALITY(7) -- Default NetRom Quality.
        QUALADJ(7) -- NetRom Quality Manipulation.

</code>
----
==== QUIT ====
<code>QUIT(1)                 XROUTER REFERENCE MANUAL            16/10/2023

</code> **COMMAND** <code>
        QUIT -- Disconnect from the router.

</code> **SYNOPSIS** <code>
        Q[uit]

</code> **DESCRIPTION** <code>
        The QUIT command performs the same function as BYE, namely to 
        terminate your session with the router.  The disconnection 
        will occur only when all outstanding data has been sent to 
        you.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        BYE(1) -- Disconnect

</code>
----
==== RADIO ====
<code>RADIO(1)              XROUTER REFERENCE MANUAL               21/9/2023

</code> **COMMAND** <code>
        RADIO -- Add/delete/list/control radios.

</code> **SYNOPSIS** <code>
        RA[dio] A[dd] <number> [options]
        RA[dio] C[ontrol] <number>
        RA[dio] D[rop] <number>
        RA[dio] L[ist]
        RA[dio] <number> [subcommand [args..]]

</code> **AVAILABILITY** <code>
        Sysop-only?

</code> **DESCRIPTION** <code>
        The RADIO command is used to add, remove, list and control
        radios that are connected to XRouter. 

        This can be used for controlling the operating parameters of
        a CAT-controlled radio that is being used for Packet, or for
        controlling a voice receiver or transceiver, e.g. for VOIP
        operations.

        Up to 5 radios can currently be supported. If there is any
        need for more, this can be changed in a future version.

        *** This system is unfinished and may change ***

        Radios are usually added at boot-time using RADIO definition
        blocks in XROUTER.CFG, but the RADIO command allows them to
        be added and removed during run-time.

        There are TWO ways to control a radio. The first is by using
        "one-shot" commands such as "radio 2 frequency 144800000"
        (see list below).

        The second method is to start a "control session" on a radio,
        which allows commands to be entered directly, e.g. "mode AM",
        "tx on" and so on. 

</code> **OPTIONS** <code>
        "RA[dio] **" lists the sub-commands, in case you forget.

        The A[dd] sub-command adds a radio to the list. The <number>
        must be within the range 1 to 5 inclusive. The [options] are
        yet to be decided.

        The D[rop] sub-command removes a radio from the radio list.

        The L[ist] sub-command lists the radios.

        The C[ontrol] command starts a "radio control" session,
        which allows direct entry of the various control commands
        listed below:

        Radio Control Commands:
        ~~~~~~~~~~~~~~~~~~~~~~~
        A[m]                 Select Amplitude Modulation mode
        CT[css] [frq | code] Display/set CTCSS frequency or code
        CW                   Select CW mode
        CWR                  Select 'reverse' CW mode
        D[own] [Hz]          Step frequency down by STEPsize or Hz
        E[xit]               Exit radio control session
        F[requency] [Hz]     Enquire or set radio's frequency
        FI[lter] [Hz]        Enquire or set IF filter width,
        FM                   Select Narrow FM mode,
        FMN                  Select Narrow FM mode
        FMW                  Select Wide FM mode
        LSB                  Select Lower Side Band mode,
        M[ode] [mode | LIST] Enquire or set modulation mode
        NFM                  Select Narrow FM mode
        O[ffset] [Hz]        Display / Set Repeater TX Offset
        P[ower] [on | off]   Enquire or set radio's on/off state
        S[hift] [- | 0 | +]  Display / Set Repeater TX Shift
        SQ[uelch] [0-100]    Enquire or set squelch level
        SSB                  Select Single Side Band mode
        ST[atus]             Display current settings
        STE[p] [Hz]          Enquire / set step size for UP/DOWN
        T[x] [on | off]      Begin / end transmissions
        TS[q] [freq | code]  Display/set Tone Squelch freq or code
        V[olume] [0-100]     Enquire or set audio volume
        U[p] [Hz]            Increase frequency by STEP or Hz
        USB                  Select Upper Side Band mode
        WFM                  Select Wide FM mode

        Not all radios support all commands. For example, the "TX"
        command is meaningless on a receiver, and "USB" is pointless
        on an FM-only radio.

</code> **SEE ALSO** <code>
        RADIO(7)       -- Rig control definition block
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== REBOOT ====
<code>REBOOT(1)               XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        REBOOT -- Reboot machine.

</code> **SYNOPSIS** <code>
        RE[boot]

</code> **DESCRIPTION** <code>
        This command is available only in the DOS version of XRouter.

        It reboots the machine immediately and ungracefully.

        It is typically used by remote sysops to restart the machine 
        after editing autoexec.bat/config.sys, installing a new 
        version of the software, or to recover from potentially 
        dangerous situations such as a corrupt hard drive.

        Console sysops can use the "Vulcan Nerve Pinch" (Ctrl-alt-del) 
        or interrupt the power instead.

</code> **NOTE** <code>
        Remote sysops should only use this command if XRouter has been
        started from AUTOEXEC.BAT, otherwise it won't restart.

        It is recommended that you include an automatic disk check and 
        repair utility within AUTOEXEC.BAT to remove any problems 
        which resulted in the REBOOT command being used.

</code> **SEE ALSO** <code>
        RESTART(1) -- Restart XRouter.

</code>
----
==== RESPTIME ====
<code>RESPTIME(1)            XROUTER REFERENCE MANUAL              26/9/2023

</code> **COMMAND** <code>
        RESPTIME -- Display / Set L2 delayed ack time for port.

</code> **SYNOPSIS** <code>
        RESPTIME <port> [millisecs]

</code> **AVAILABILITY** <code>
        This is a sysop-only command.

</code> **DESCRIPTION** <code>
        The RESPTIME command allows the value of the AX25 T2 (delayed 
        ack) time for a port to be displayed or altered.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies
        the port number, and the second specifies the new value for
        the parameter.  The new setting remains in force until
        changed, or until XRouter is restarted, in which case the
        value specified by RESPTIME in the relevant PORT block in
        XROUTER.CFG is reapplied.

</code> **EXAMPLE** <code>
        RESPTIME 3       - Display current setting for port 3
        RESPTIME 3 150   - Set port 3 resptime to 1500 millisecs

</code> **NOTES** <code>
        The RESPTIME parameter specifies how long XRouter waits,
        after receiving a frame, before sending an ack for that 
        frame.  It helps to improve the efficiency by reducing 
        unnecessary acks.  It allows a single ack to be sent when a 
        transmission contains several frames, instead of acking each 
        frame in turn.

        The value must therefore be at least the length of time it 
        takes the link partner to transmit a single packet.  At 1200
        bauds (120 bytes/sec) a 120 byte packet lasts 1 second, a 180
        byte packet lasts 1500 millisecs and a 256 byte packet lasts
        just over 2 seconds.  Therefore RESPTIME should reflect the
        PACLEN used by the link partner.  1500 millisecs is a good
        compromise, but if the other end regularly uses high paclens,
        2000 or 2500 ms would be more appropriate.

        At 9600 baud, or on AXUDP links, 200 millisecs is probably
        adequate.

        Too high a value will cause the link to be too "relaxed", 
        whereas too low a value will cause too many acks.  Both 
        extremes reduce the link efficiency.

</code> **SEE ALSO** <code>
        FRACK(1)       -- Frame Acknowledgement Time.
        PACLEN(1)      -- Maximum Packet Length.
        SLOTTIME(1)    -- CSMA Interval Time
        RESPTIME(7)    -- AX25 Delayed Ack Time.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RESTART ====
<code>RESTART(1)              XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        RESTART -- Restart XRouter.

</code> **SYNOPSIS** <code>
        RES[tart]

</code> **AVAILABILITY** <code>
        Sysops only.

</code> **DESCRIPTION** <code>
        Re-starts the XRouter program immediately and ungracefully.

        It is typically used by remote sysops to restart the program 
        after modifying the config files, or installing a new version
        of the software.

        All open links are closed, and the program starts again from
        scratch.

</code>
----
==== RETRIES ====
<code>RETRIES(1)             XROUTER REFERENCE MANUAL              26/9/2023
</code> **COMMAND** <code>
        RETRIES -- Display / Set Maximum AX25 Retries.

</code> **SYNOPSIS** <code>
        RETRIES <port> [value]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The RETRIES command allows the value of the level 2 maximum 
        retry value for a port to be displayed or altered, i.e. the 
        maximum no. of attempts at sending a frame without a reply 
        being received.  The usual setting is 10.  A setting of 0 
        means "try forever", and should be avoided except for testing.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies the 
        port number, and the second specifies the new value for the 
        parameter.  The new setting remains in force until changed, or 
        until the router is restarted, in which case the value 
        specified in the CFG file is reapplied.

</code> **EXAMPLE** <code>
        RETRIES 3       - Display current setting for port 3
        RETRIES 3 15    - Set port 3 max retries to 15

</code> **SEE ALSO** <code>
        RETRIES(7) -- AX25 Maximum Retry Count.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RIP ====
<code>RIP(1)                  XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        RIP -- Routing Interface Protocol configuration commands.

</code> **SYNOPSIS** <code>
        RIP AC[cept] <ip_address>
        RIP A[dd] <ip_address> <secs>
        RIP D[rop] <ip_address>
        RIP L[earn] [ON | OFF]
        RIP R[efuse] <ip_address>
        RIP S[tatus]
        RIP T[imeout] [secs]

</code> **DESCRIPTION** <code>
        RIP allows IP routers to learn of each other's routing, in a 
        similar fashion to NetRom.  XRouter implements both RIP2,
        used by the IPEncap-based "44-net", and RIP98, which is a
        form optimised for radio, and the RIP commands are used to 
        configure the system.

</code> **OPTIONS** <code>
        Peers which have been added to the refuse list using the RIP 
        REFUSE command can be removed using RIP ACCEPT, allowing the 
        router to learn information from them.  <ip_address> is the
        IP address of the peer.

        RIP ADD adds a peer to the list of those who will receive RIP 
        transmissions from us.  The <secs> parameter specifies the 
        interval between transmissions, and should be chosen in 
        agreement with the peer, so that <secs> is approximately one
        quarter of the lifetime of their RIP entries.  This allows up 
        to 4 transmissions to be lost before the route is purged.

        RIP DROP removes a peer from the list of those who receive
        RIP transmissions from us.

        RIP LEARN turns route learning on or off.  By default, RIP98 
        route learning is OFF.  If no arguments are given, the
        current status is reported.  "ON" allows XRouter to learn
        routes from its RIP98 peers, and "OFF" prevents it.  I
        recommend enabling LEARN mode.

        RIP REFUSE is the opposite of ACCEPT.  It adds a peer to the 
        refuse list so broadcasts from that peer will be ignored.
        This command is provided in case you need to exclude a peer 
        which is advertising faulty routes.

        RIP STATUS displays various RIP98 parameters such as the list 
        of peers who receive broadcasts from us, the list of peers we 
        are ignoring, the timeout value, and the setting of learn 
        mode.

        RIP TIMEOUT is used to display and set the lifetime of
        learned routes.  Routes learned from peers have a finite
        lifetime.  If the route entry is not refreshed within this
        lifetime, it is removed from the routes table.  The timeout
        should preferably be 4 times the interval between broadcasts
        from peers, and the default is currently 4 hours.

</code> **EXAMPLES** <code>
        RIP ACCEPT 44.131.95.2
        RIP ADD 44.131.95.240 3600
        RIP DROP 44.131.90.6
        RIP LEARN ON
        RIP REFUSE 44.131.57.1
        RIP STATUS
        RIP TIMEOUT 14400

</code> **FILES** <code>
        The RIP ADD, LEARN, REFUSE and TIMEOUT commands may also be
        used within IPROUTE.SYS or BOOTCMDS.SYS.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        BOOTCMDS.SYS(8) -- Commands to Execute at Bootup.
        IPROUTE.SYS(8) -- IP Router Configuration File.

</code>
----
==== ROUTES ====
<code>ROUTES(1)               XROUTER REFERENCE MANUAL            18/10/2023
</code> **COMMAND** <code>
        ROUTES -- Add, Drop and List NetRom Routes.  

</code> **SYNOPSIS** <code>
        R[outes] [* | H | L | R | Q | T | X ] [portnum]
        R[outes] A[dd]  <call> <port> <qual> [!] [V digis] [opts]
        R[outes] D[rop] <call> <port>
 
</code> **DESCRIPTION** <code>
        The ROUTES command, which may be abbreviated to "R", lists
        the immediately adjacent NetRom nodes, i.e. those who can be
        heard directly, providing those nodes are making NetRom nodes 
        broadcasts.

        For each neighbour node the display always shows the port
        number, the neighbour's callsign, the route quality, and the
        number of nodes accessible via that neighbour.

            G8PZT:KIDDER} Routes:
            Port Callsign  Qty Nod
            >  5 G4FPV     150  70!
            >  7 GB7PZT    250   1!
            >  8 GB7WV-12  100  32!
            >  9 GB7GH     150 104!
              10 GB7CL     150   1!
            > 11 GB7IPT-7  150   3!
              12 G1LOA-10  150   2!

        A chevron (>) in the left-most column indicates a route which
        is in use. A tilde (~) indicates that the connection is in
        the process of being established. An "x" indicates a failed
        route, and a blank space indicates a closed (but not failed)
        route.

        An exclamation mark (!) in the right-most column indicates
        that the data has been "locked in" by the sysop.

        Any additional information, displayed to the right of the
        above, depends on which additional option is supplied, as
        detailed in the next section.

</code> **OPTIONS** <code>
        Some of the options give identical output, because they were
        renamed and the old ones were retained for backward
        compatability.

        If no options are specified, the output is similar to the
        example above.

        The following options don't display any routes:

            *      displays a brief list of the available options.
            **     lists the options with brief descriptions.
            A[dd]  is used to add a route.
            D[rop] is used to remove a route.
            H[elp] lists the options with brief descriptions.

        Options which display routes and modify the display format
        are as follows:

            L[oad] displays traffic loading & connection percentage
            Q[ual] displays estimated route qualities
            R[etr] displays sent/resent frames & retry rates
            T[ime] displays trip times & settings for time metrics
            X[tra] displays running average & peak retry rates
            Y      is the same as T[ime] (deprecated)
            Z      is the same as L[oad] (deprecated)

        If the first or second option is a valid port number, only
        the information for that port is displayed.

</code> **DETAILS** <code>
        L[oad] displays information about connection percentage and
               data throughputs, for example:

           Con%  Peak  Best  Mean  Load   Last heard
            98%  3024  3024   102     9  19/10 05:34

           Con%  - Percentage of time that link has been connected.
           Peak  - Max throughput in bytes/sec including resends
           Best  - Best mean throughput achieved, excluding resends
           Mean  - Running mean throughput in bytes/sec.
           Load  - Long term average throughput (TX+RX) in bytes/sec.
           Last  - Last date/time that any traffic used this route.

        
        Q[ual] displays the estimated route qualities, for example:

           Qual  Min  Max  Mdev
            245  240  252     1

           These are based on measurements of actual link
           performance, regardless of qualities specified by sysops.
           They are intended as a guide to help sysops make informed
           choices for link quality. The values shown are the
           smoothed calculated quality, the minimum and maximum
           calculated qualities, and the standard deviation of the
           mean.


        R[etr] displays the current MAXFRAME, FRACK and PACLEN
               settings, and retry rates, for example:

           Max  Frack  Pac    Sent  Resent  Rty%  Last bcast
             3   7000  256    4415    1296   29% 19/10 05:29

           Max    - Maxframe (maximum allowed unacked frames)
           Frack  - Frack (Frame Acknowledgement time) Millisecs
           Pac    - Paclen (maximum packet length in bytes)
           Sent   - Total information frames sent
           Resent - Information frames re-sent
           Rty%   - Retry rate in percent
           Bcast  - Date/time of neighbour's last nodes broadcast


        T[ime] displays information and settings concerned with
               temporal metrics, i.e those based on trip time:

           Tdr     Stt  Flg  Maxtt/hops 
            63    0.03   14   5000   30   5000

           The displayed values are as follows:

           Tdr    - Nodes learned from neighbour via temporal metrics
           Stt    - Smoothed Trip Time to the neighbour.
           Flg    - Flags, the sum of the following:

                      1 - Route locked in by sysop.
                      2 - Neighbour is INP3 compatible.
                      4 - Neighbour responds to our L3RTT probes.
                      8 - Neighbour is XRouter
                     16 - Automatic route quality enabled.

           MaxTT  - Max Trip Time allowed via this route.
           MaxHop - Max Hop count allowed via this route.

           The final figure is the neighbour's MaxTT setting, which
           may differ from ours.


        X[tra] displays extended information about the retry rates:

           Sent  Resent  Rty%   Now%   Max% @dd/mm hh:mm 
           4427    1301   29%  31.08  40.00  12/10 23:21 

           Sent   - Total information frames sent
           Resent - Information frames re-sent
           Rty%   - Long-term mean retry rate
           Now%   - Running average retry rate
           Max%   - Peak value of the running average
           @dd... - Date and time of the peak value

           The running average retry rate is more responsive to
           short-term variations (e.g. due to QRM on a link) than the
           long term mean.

           These stats often reveal links with low *mean* retry rates
           that display some surprising short term highs.
      

        A[dd] adds a new route or modifies an existing one. The
              arguments are as follows:

           <call> is the callsign of the neighbour node.

           <port> is the radio port via which the neighbour is
                  reached.

           <qual> is the netrom "quality" to use for that route.
                  A quality between 256 and 511 will instruct
                  XRouter to use "automatic" quality, with a starting
                  value of (qual-256). 

           [!] locks the entry to prevent it being overridden by
               learned information.

           [V digis] specifies a digipeated route, where "digis"
                     is a string of digipeater calls seperated by
                     commas, i.e. in the form "DIGI,DIGI,DIGI".

           [opts] are optional maxframe, frack, paclen, maxtt and
                  maxhops values to override the port defaults.
                  The format is:

                      [maxframe [frack [paclen [maxtt [maxhops]]]]]

                  i.e. in order to specify maxtt you must also
                  specify maxframe, frack and paclen  Use zero in
                  any field you don't wish to change.

</code> **EXAMPLES** <code>
         route add g8pzt 5 100
         route add g6yak 2 100 ! V G8EPR,G8NTU 5 7000
         route add g8klm 3 150 ! 0 0 245 2000 3
         route drop mb7uyl 14
         r 4      -- Display basic information for routes on port 4
         r t 5    -- Display TDR information for routes on port 5

</code> **AVAILABILITY** <code>
        The ROUTES command is available to all users, but the ADD
        and DROP options are sysop-only.

</code> **SEE ALSO** <code>
        AUTOQUAL(9)  -- Automatic Route Quality
        NODES(1)     -- Display Nodes Tables.
        PERMLINKS(9) -- Permanent NetRom Neighbour Links.

</code>
----
==== SAVENODES ====
<code>SAVENODES(1)            XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        SAVENODES -- Save Nodes and Routes Tables to Disk.

</code> **SYNOPSIS** <code>
        SA[venodes] [filename]

</code> **DESCRIPTION** <code>
        The SAVENODES command dumps the nodes and routes tables to 
        a "recovery" file.  This file is read by XRouter at start up,
        and used to reconstruct the tables without having to wait
        for nodes broadcasts to be received.

        Table dumping occurs automatically to file XRNODES every 
        hour, and when XRouter is closed down using Alt-x, but this 
        command allows you to dump and examine the tables at any
        time, without taking XRouter off line.

</code> **OPTIONS** <code>
        The optional argument specifies the filename to dump to, and 
        if not specified it defaults to XRNODES.

</code> **FILES** <code>
        The XRNODES file is similar in format to the BPQNODES file
        used with the DOS version of BPQ node, but is no longer
        compatible with it. 

        XRNODES is a plain text file, which may be viewed with
        Notepad by adding the extension .TXT

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        LOADNODES(1) -- Load Nodes and Routes.
        XRNODES(8)   -- Nodes / Routes Recovery File.

</code>
----
==== SCRIPT-CMD ====
<code>SCRIPT-CMD(1)           XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        < -- Execute XRouter Command Scripts.

</code> **SYNOPSIS** <code>
        < <script_file>

</code> **DESCRIPTION** <code>
        The "<" command reads a specified file, and executes any
        XRouter commands contained therein.

        This would typically be used to execute frequently used
        command sequences.

</code> **EXAMPLE** <code>
        < MYCMDS.TXT

</code> **CAVEATS** <code>
        The script must not include any commands which require
        interaction with the sysop, otherwise it will stop XRouter.

</code> **AVAILABILITY** <code>
        Sysops-only.

</code> **SEE ALSO** <code>
        SHELL(1) --  Run Command or Program in an O/S Shell.

</code>
----
==== SECTIONS ====
<code>SECTIONS(1)             XROUTER REFERENCE MANUAL             18/1/2024

</code> **NAME** <code>
        SECTIONS -- List of Sysop Manual Sections.

</code> **DESCRIPTION** <code>
        The manual is divided into several sections as follows:

           Section   Contents
           ------------------------------------------
              1      General Commands
              2      Chat Server Commands
              3      PZTDOS commands
              4      Mailbox commands
              6      Installation & Configuration Topics
              7      Configuration Directives
              8      Configuration / System Files.
              9      Miscellaneous Topics

        For sections other than 1 and 8, the section is indicated
        by a number appended to the topic name, e.g. MHEARD.9

</code> **SEE ALSO** <code>
        MAN(1) -- The MAN command.

</code>
----
==== SEND ====
<code>SEND(1)                 XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        SEND -- Send unproto text

</code> **SYNOPSIS** <code>
        SE[nd] <port> <destcall> [V digi,digi,..] <text>

</code> **AVAILABILITY** <code>
        All users, except guests.

</code> **DESCRIPTION** <code>
        Sends an unproto (UI) packet on the specified port.  The 
        destination address and up to 8 digis may be specified.

        This command is included to facilitate tests, and may be
        called by entries in CRONTAB.SYS for sending extra beacons.

</code> **EXAMPLE** <code>
        Send 7 CQ V G8EPR,G8AKX Meet me on 144.800!

</code>
----
==== SHELL ====
<code>SHELL(1)                XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        SHELL -- Run a Command or Program in an O/S Shell.

</code> **SYNOPSIS** <code>
        SH[ell] <cmd> [args...]

</code> **DESCRIPTION** <code>
        The SHELL command is used for running commands, scripts and
        simple programs in a temporary DOS, Windows or Linux shell
        which terminates upon completion of the operation.

        It is suitable for simple non-interactive commands such as
        DIR, MD, and TYPE, or programs that run and terminate without
        requiring any further input from the user.

        The "!" command performs the same action.

</code> **EXAMPLES** <code>
        SHELL DIR /W     (on a DOS / Windows platform)
        SHELL ls -l      (on a Linux platform)
        SHELL fetch_weather_data.sh

</code> **LIMITATIONS** <code>
        Running interactive commands or programs via this means
        (e.g. piping a directory listing via MORE) is not possible,
        as XRouter is suspended while the external command or program
        runs.

</code> **AVAILABILITY** <code>
        Sysops only

</code> **SEE ALSO** <code>
        SCRIPT-CMD(1) -- Execute XRouter Command Scripts.

</code>
----
==== SLOTTIME ====
<code>SLOTTIME(1)            XROUTER REFERENCE MANUAL              26/9/2023

</code> **COMMAND** <code>
        SLOTTIME -- Display / Set the slottime parameter for a port.

</code> **SYNOPSIS** <code>
        SLOTTIME <port> [millisecs]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The SLOTTIME command allows the value of the CSMA interval 
        timer for a port to be displayed or altered.  The usual 
        setting is 100 milliseconds.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the slottime value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies
        the port number, and the second specifies the new value for
        the  parameter. The new setting remains in force until
        changed, or until XRouter is restarted, in which case the
        value specified in XROUTER.CFG is reapplied.

</code> **EXAMPLES** <code>
        SLOTTIME 3       - Display current setting for port 3
        SLOTTIME 3 150   - Set port 3 slottime to 150

</code> **SEE ALSO** <code>
        PERSIST(7)     -- AX25 Probablity to Transmit.
        SLOTTIME(7)    -- CSMA Interval Time.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SMS ====
<code>SMS(1)               XROUTER REFERENCE MANUAL                10/9/2023
</code> **COMMAND** <code>
        SMS -- Short Messaging System for XR sysops.

</code> **SYNOPSIS** <code>
        SMS [nodecall [text]]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The SMS command can either invoke an SMS client, or directly
        send a short message to the sysop of another XRouter. This is
        a messaging service for XRouter sysops, and has nothing to do
        with telephone SMS.

        Sysops have a need to communicate with each other. Some of
        them leave messages for each other on the sysop chat, but
        that tends to scroll off the screen and get lost. It is also
        very public, and unecessarily broadcasts the message to every
        chat server. The PMS can be used, but it isn't very "instant",
        and has no sense of "conversation"; only a random list of
        incoming messages.

        To try and solve this problem, the SMS system was created.

        Unlike the BBS system, SMS messages are delivered directly
        from the source node to the recipient node, without
        intermediate store and forward. Thus it curently only works
        with nodes that are in your list. However, as most XRouter
        nodes are known to each other, that's not much of a problem.
        In future there will be no such restriction.

        There is a "read receipt" mechanism, so the sender knows
        whether or not their message has been received and read.

        The recipent is alerted to the presence of a short message
        by a flashing "S" on the top status bar. The SMS client is
        used to display the messages, send relies etc.

        The SMS Client
        ~~~~~~~~~~~~~~
        Upon entering the client, any new message(s) are displayed.
        If there is more than one new message in a conversation, the
        first unread one is displayed:

            sms
            G8PZT-1:MOBILE} Starting SMS Client..

            SMS Conversations:

               Nodecall   New  Date/Time    Text
               G8PZT-14     0  09/06 02:56  another test back from me
               G8PZT        0  18/05 03:27  test at 03:25 tuesday

            R)ead   S)end   A)rchive   D)elete   E)xit SMS

        Note that unlike a PMS or BBS, this is CONVERSATION not
        MESSAGE oriented. 

        Each {nodecall} in the above list indicates a conversation
        with the sysop of that node. A conversation consists of one
        or more messages between you and the other party in strict
        chronological sequence. Both sides of the conversation are
        included.

        The argument to each command, with the exception of "E)xit",
        is a {nodecall}, i.e. a conversation. So "A)rchive G8PZT"
        archives the conversation to a file, removing it from the
        list.

            R)ead     Reads a conversation
            S)end     Sends a message to a conversation
            A)rchive  Removes conversation & archives it to disk.
            D)elete   Permanently deletes a conversation.
            E)xit     Exits the client and returns to the node.

        "R G8PZT" reads the conversation between you and G8PZT,
        starting at the first unread message. If there are no unread
        messages it displays the last message.

        In this example there are both previous and subsequent
        messages, which can be displayed using the Next and P)revious
        commands:

            r g8pzt

            Sent: 18/05/21 03:27:20
              To: G8PZT

            test at 03:25 tuesday

            S)end,  N)ext,  P)revious,  C)onversations,  E)xit SMS

        The "S)end" option is a little ambiguous in this menu, and
        shows how unfinished the user interface is!! It really means
        "create a new message", not "send the above message".

        The C)onversations option returns you to the list of
        conversations.

</code> **OPTIONS** <code>
        Typing "SMS" by itself invokes the SMS client, from where
        you view the conversations, read, send, and delete messages.

        The "SMS <nodecall>" form initiates the sending of a message,
        and prompts for the message body.

        The "SMS <nodecall> <text>" form sends a message instantly,
        and returns to the command line.

</code> **EXAMPLES** <code>
        SMS
        SMS G8PZT
        SMS G8PZT I'll be on sysop chat at 3pm UTC

</code> **SEE ALSO** <code>
        CHAT(1)    -- Connect to chat server
        PMS(1)     -- Personal Message System
        SMS-SVC(9) -- SMS Service

</code>
----
==== START ====
<code>START(1)                XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        START -- Start a daemon process.

</code> **SYNOPSIS** <code>
        ST[art] <process_name>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The START command is used to start daemons, which in this
        context are XRouter processes which run independently of any
        controlling session.  For example the IGATE and dialler
        processes are daemons.

</code> **EXAMPLE** <code>
        START IGATE

</code> **NOTE** <code>
        Attempting to start a daemon which is already running will 
        have no harmful effect.

</code> **SEE ALSO** <code>
        STOP(1) -- Stop a daemon.

</code>
----
==== STATS ====
<code>STATS(1)                XROUTER REFERENCE MANUAL              3/1/2024
</code> **COMMAND** <code>
        STATS -- Display XRouter statistics.

</code> **SYNOPSIS** <code>
        S[tats] [ L1 | L2 | L3 | L4 | IP | TCP | * ]
        S[tats] [AXIP | AXUDP | AXTCP | IDS]

</code> **AVAILABILITY** <code>
        All users, but IDS stats can only be viewed by sysop.

</code> **DESCRIPTION** <code>
        Displays information about the performance of XRouter, such 
        as the uptime, the no. of packets routed, error rates etc.

        Stats may be displayed for a single ISO layer, or for all
        layers.  

</code> **OPTIONS** <code>
        Entering S by itself will give a single page synopsis.

        "S ?" displays a list of the subcommands,
 
        "S *" displays the full stats for all layers.

        "S <layer>" displays the stats for <layer> as follows:

             L1    - Physical layer (interfaces etc)
             L2    - Link layer (AX25L2 etc)
             L3    - Network layer (NetRom datagrams)
             L4    - Transport layer (NetRom connections)
             IP    - Internet Protocol layer (non-ISO)
             TCP   - Transmission Control Protocol layer (non-ISO)
             AXIP  - "AX25 in IP" encapsulation
             AXUDP - "AX25 in UDP/IP" encapsulation
             AXTCP - "AX25 in TCP/IP" encapsulation

        "S IDS" displays brief stats for XRouter's Intrusion
        Detection System. This is mainly of use to remote sysops,
        because all the information is already available to console
        sysops via the "Security Monitor" window.

        A typical response  to "S IDS" is as follows: 

        G8PZT:KIDDER} Security stats:

        TCP Scans: SYN=837 FIN=0 ACK=152 NUL=0 MAI=37 XMS=0 OTH=1632
        Bogus SYNs: 2083
        Rejected Logins: Telnet=77, Rlogin=0, FTP=7, TelProxy=0
        Malicious Logins: Telnet=334, Rlogin=0, FTP=47, TelProxy=0
        FTP directory hacks: 0
        IDS Notifications: 132682
        IP frames from banned senders: 3155
        IP Fragmentation attacks: Tiny=5  Huge=0  Overlapped=3
        Smurfs: 0  Fraggles: 0
        Honeypot Hits: 27

        Note that if your node is AX25-only, or completely hidden
        behind a firewall, many of these stats will be 0, which is a
        good thing :-)

</code> **EXAMPLES** <code>
             S       Display single page synopsis
             S *     Display all stats for all layers
             S IP    Display only the IP-layer stats

</code> **LIMITATIONS** <code>
        Screen width is only 80 characters, so on systems with many
        ports and interfaces the display may wrap.

</code> **SEE ALSO** <code>
        STATS(9) -- Explanation of the individual stats fields.

</code>
----
==== STOP ====
<code>STOP(1)                 XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        STOP -- Stop a daemon process / List active daemons.

</code> **SYNOPSIS** <code>
        STO[p] [process_name]

</code> **DESCRIPTION** <code>
        The STOP command is used to stop an XRouter internal daemon
        process whose name name is specified as the argument.

        If STOP is used without arguments, a list of the active
        processes is displayed.

</code> **EXAMPLE** <code>
        STOP IGATE

</code> **NOTE** <code>
        Attempting to stop a process which is not running will simply 
        produce an error message.

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        START(1) -- Start a daemon.

</code>
----
==== TALK ====
<code>TALK(1)                 XROUTER REFERENCE MANUAL             28/9/2023

</code> **COMMAND** <code>
        TALK -- Talk to a user or another sysop.

</code> **SYNOPSIS** <code>
        TA[lk] <sessnum | nodecall>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The TALK command allows a sysop to have a keyboard chat with
        a locally connected user, or the sysop of another XRouter.

        It is usually, but not always, invoked in response to a user
        issuing the YELL command.

        If the argument is a session number, e.g. "talk 123", it
        allows the sysop to talk to a logged-in user.

        If the argument is a node callsign or alias, for example.
        "talk VK2DOT"  it initiates a private keyboard to keyboard
        chat with the sysop of that node, if he is available. This
        is not related to the "sysop chat" channel on the chat
        server. It is the NetRom equivalent of the TTYLINK command,
        and this form is identical to the NTTY command.

        The sysop of the target node has 90 seconds to respond. At
        any point during or after the 90 seconds, the caller has the
        option to leave a short one-line message (160 chars max) or
        to abort the call. Messages are saved into the sysop's PMS.

        If the sysop takes more than 90 seconds to respond, and the
        user has not disconnected, the sysop can still use the
        "talk <sessnum>" form of the command to initiate a chat with
        the user.

</code> **EXAMPLES** <code>
        TALK 21     - Initiate chat with session 21 on this node
        TALK KIDDER - initiate chat with sysop of KIDDER node

</code> **LIMITATIONS** <code>
        Sysops may interrupt users' command sessions, but may not
        interrupt established circuits, because that might damage
        the data being sent or received by the user.

        The "TALK <nodecall>" form currently only works if the target
        node is running a recent version of XRouter. Other types of
        node will not (yet) respond to the request. 

</code> **SEE ALSO** <code>
        NTTY(1)    -- Netrom TTYLink.
        YELL(1)    -- Page the sysop.
        TTYLINK(1) -- Keyboard chat with another TCP/IP system.

</code>
----
==== TCP ====
<code>TCP(1)                 XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        TCP -- TCP status / configuration commands.

</code> **SYNOPSIS** <code>
        TC[p] C[ache] L[ife] [secs]
        TC[p] C[ache] SI[ze] [slots]
        TC[p] C[ache] S[tatus]
        TC[p] L[isteners]
        TC[p] R[eset] <sock#> [sock#]...
        TC[p] S[tatus]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The TCP command is used to display or modify various
        settings in XRouter's TCP module, and to reset connections.

</code> **OPTIONS** <code>
        "TC[p] C[ache] L[ife] [secs]" is used to display or change
        the SYN cache lifetime. The default is 10 seconds.

        "TC[p] C[ache] SI[ze] [slots]" is used to display or change
        the size of the SYN cache. The default is 1000 slots. The
        maximum is 9999 slots, which together with a 10 second
        lifetime would cope with 999 SYNs per second.

        "TC[p] C[ache] S[tatus]" displays the status and statistics
        of the SYN cache.

        "TCP L[isteners]" displays the IP addresses and TCP port
        numbers for the listener (server) sockets that XRouter is
        using on both its own stack and the operating system's.
        An IP address of 0.0.0.0 indicates that the socket is
        listening on all of XRouter's IP addresses.

        "TCP R[eset] <sock#> is used to reset (close) the connection
        whose socket number is specified by <sock#>. This would
        typically be used to close a malicious or "stuck" connection.
        The socket number may be obtained by the STATUS subcommand.

        "TCP S[tatus]" displays the status of all the current TCP
        connections.

        The display shows the socket number, the remote and local 
        addresses, the state, and the amount of queued data in bytes. 
        The states are as follows (see RFC793):

               0    Closed              6    FINWAIT2
               1    Listen              7    Close wait
               2    SYN sent            8    Closing
               3    SYN Received        9    Last ACK
               4    Established         10   Time Wait
               5    FINWAIT1

</code> **SEE ALSO** <code>
        UDP(1) -- Display UDP status

</code>
----
==== TELNET ====
<code>TELNET(1)               XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        TELNET -- Establish a TCP "connection".

</code> **SYNOPSIS** <code>
        TELNET <hostname | ipaddress> [port]

</code> **DESCRIPTION** <code>
        The TELNET command allows users to "connect" to other TCP/IP 
        systems, using a "shell" account, i.e. the user does not need 
        to be running TCP/IP as XRouter does all the TCP/IP <> AX25 
        translation.

</code> **OPTIONS** <code>
        The first argument <hostname | ipaddress> is either the
        hostname or the IP number of the target system. If the
        hostname doesn't contain at least one period (.), the domain
        suffix specified in XROUTER.CFG (default .ampr.org.) is
        appended.

        The optional <port> parameter specifies the desired service
        on the target host.  If not supplied, the default is 23, i.e.
        the "Telnet" port. Common port numbers are 21 (FTP), 23
        (Telnet), 25 (SMTP), and 87 (TTYLINK).

</code> **EXAMPLES** <code>
        TELNET 44.131.90.6 21   Connect to FTP server at 44.131.90.6
        TELNET gb7lgs.ampr.org  Telnet login to gb7lgs
        TELNET gb7pzt 25        Connect to SMTP server at gb7pzt

</code> **LIMITATIONS** <code>
        This command will only work if XRouter has an IP address 
        and IP routing has been defined.  It should be obvious that 
        XRouter also needs to be connected to an IP-capable network!

</code> **NOTES** <code>
        Specifying target hosts by their IP addresses will often 
        result in faster connection if the hostname is not in 
        domain.sys, as it will not have to wait for DNS resolution.

</code> **AVAILABILITY** <code>
        All users except "guests".

</code> **SEE ALSO** <code>
        PING(1)       -- For testing if the target host is reachable.
        TELNETPORT(7) -- TCP Port for Telnet Access
        
</code>
----
==== TIME ====
<code>TIME(1)                 XROUTER REFERENCE MANUAL              6/9/2023
</code> **COMMAND** <code>
        TIME -- Show time at any XRouter /  Set time here.

</code> **SYNOPSIS** <code>
        TI[me] [node | hh:mm]

</code> **AVAILABILITY** <code>
        Available to all users, but time setting is sysop-only.

</code> **DESCRIPTION** <code>
        If no argument is supplied, this command displays the current 
        setting of the PC clock.

        If an argument of the form HH:MM is used, it sets the PC 
        clock to the specified time. (24 hour format)

        If the argument is the callsign or alias of an XRouter which
        is in the nodes table, the local date and time at that node
        is shown. This may involve a connection to the target node's
        time service, so please allow time for the response.

</code> **EXAMPLE** <code>
        TIME         - Display current setting of PC clock.
        TIME 23:06   - Sets PC time to 23:06
        TI G8PZT     - Display time at G8PZT node

</code> **SEE ALSO** <code>
        DATE(1)  -- Enquire / set system date
        TSYNC(1) -- Synchronise with an Internet time standard

</code>
----
==== TNC ====
<code>TNC(1)                XROUTER REFERENCE MANUAL                6/9/2023
</code> **COMMAND** <code>
        TNC -- Control TNC-style peripherals.

</code> **SYNOPSIS** <code>
        TN[c] <port>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The "TNC" command is for controlling TNC-style peripherals,
        e.g. real TNC's or any applications or devices that use
        plain text commands.

        The <port> argument refers references a PORT whose interface
        PROTOCOL is "TNC".

        After issuing the TNC command, the session talks directly to
        the peripheral in plain text mode. This could be used for
        example to interface with an ARDOP TNC.

</code> **SEE ALSO** <code>
        PROTOCOL(7) -- Protocol Used on INTERFACE.

</code>
----
==== TRACERT ====
<code>TRACERT(1)              XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        TRACERT -- Trace Route to TCP/IP host.

</code> **SYNOPSIS** <code>
        TR[acert] <host> [maxhops [maxwait(ms)]]

</code> **DESCRIPTION** <code>
        The TRACERT command is a diagnostic tool for displaying the
        route to an Internet Protocol host, and measuring the transit
        delays of packets at each step.

        It uses the replies from a series of ICMP echo requests to
        produce a list of the routers that the packets have passed
        through.

        3 attempts are made at each hop, thus for each hop, 3 round
        trip times are displayed, along with the IP address of the
        router at that hop. The 3 times indicate the consistency of
        the route. If no response is received within the timeout
        period, a "*" is displayed in the time field.

</code> **OPTIONS** <code>
        <host> is the hostname or IP address of the target host.

        [maxhops] is the maximum number of hops to trace (default 30).

        [maxwait] is the maximum time to wait for a reply from each
                  router. The default is 4 seconds.

        The only required parameter is <host>. If the hostname
        doesn't contain at least one dot (.) the domain suffix
        specified in XROUTER.CFG (default .ampr.org.) is appended.

        Entering TRACERT without any arguments displays a syntax
        reminder.

</code> **EXAMPLES** <code>
        TR bbc.co.uk       - Trace bbc.co.uk with default parameters.
        TR 44.141.91.2 10  - Trace 44.131.91.2 to a max of 10 hops.
        TR g8pzt 5 20      - Trace g8pzt.ampr.org, 5 hops, max 20secs.

            G8PZT-12:PZT12} Tracing route to g8pzt [44.131.91.4],
            max. 5 hops

             1      0 ms     0 ms     0 ms   [44.131.91.246]
             2      0 ms    55 ms    55 ms   [44.131.91.245]
             3    165 ms    55 ms    55 ms   [44.131.91.4]

             Trace complete.

</code> **CAVEATS** <code>
        TRACERT relies on ICMP messages, and therefore requires that
        ICMP is correctly routed via front-end routers and firewalls
        etc. It will fail to produce a response from systems that are
        "stealthy" i.e. those that do not respond to ICMP. Such
        systems are indicated by "* * * Request timed out" lines.

        The Traceroute function will not work unless XRouter has an
        IP address, and IP routing has been correctly set up.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        IP(1)      -- IP Configuration Commands
        PING(1)    -- Send ICMP Echo request
        STEALTH(9) -- TCP/IP Stealth Issues

</code>
----
==== TSYNC ====
<code>TSYNC(1)                XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        TSYNC -- Synchronise Time using Internet Time Server.

</code> **SYNOPSIS** <code>
        TS[ync] <ipaddr>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The TSYNC command causes XRouter to synchronise the PC time
        with an Internet TIME server.

        It is doubtful whether this relic from DOS-XRouter has
        any purpose on a Windows or Linux platform, since those
        operating systems contain tools to do the same job more
        effectively.

</code> **OPTIONS** <code>
        The only required option is the IP address of an RFC-868 TIME
        server. Hostnames are not acepted in this field. A list of
        TIME servers is available on the nist.gov web site.

        If no options are supplied, a syntax reminder is displayed.

</code> **EXAMPLE** <code>
        TS 129.6.15.28

</code> **CAVEATS** <code>
        This command may set your PC clock to the wrong timezone if
        the TZ environment variable is not set correctly.

        NIST plans to phase out RFC-868 TIME servers in April 2013,
        in favour of NTP (Network Time Protocol) servers, although
        there may still be a few servers operated by other
        organisations.

</code> **SEE ALSO** <code>
        DATE(1) -- Set PC Date.
        TIME(1) -- Set PC Time.
 
</code>
----
==== TTYLINK ====
<code>TTYLINK(1)              XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        TTYLINK -- Keyboard To Keyboard Chat

</code> **SYNOPSIS** <code>
        TT[YLINK] <hostname | ipaddress> [port]

</code> **DESCRIPTION** <code>
        The TTYLINK commmand allows users of any type (i.e. AX25, 
        console, wire link, TCP/IP) to chat directly to TCP/IP 
        users.

        This is similar to the TELNET comand, except that the default
        port number is 87, which is reserved for keyboard to keyboard
        chat.  Other port numbers may be specified.

        This command is deprecated, and may be removed from future
        versions.

</code> **OPTIONS** <code>
        The first argument <hostname | ipaddress> is either the
        hostname or the IP number of the target system. If the
        hostname doesn't contain at least one period (.), the domain
        suffix specified in XROUTER.CFG (default .ampr.org.) is
        appended.

        The optional [port] parameter specifies the desired service
        on the target host.  If not supplied, the default is 87.

</code> **EXAMPLE** <code>
        TTY 44.131.91.4       - Chat to user of this IP address
        TTY g8pzt             - form if hostname is in domain.sys

</code> **LIMITATIONS** <code>
        In order for this command to work, XRouter must have an IP 
        address and have IP routing defined.

</code> **NOTE** <code>
        If the target hostname is not known to XRouter, it will be 
        more efficient to specify the target as an IP address, since 
        this will not require DNS resolution.

</code> **AVAILABILITY** <code>
        All users except guests.

</code> **SEE ALSO** <code>
        PING(1)   -- Test if a host is reachable
        TELNET(1) -- Make TCP connection
        TTYLINK(9) -- About TTYLINK.

</code>
----
==== TXDELAY ====
<code>TXDELAY(1)            XROUTER REFERENCE MANUAL               26/9/2023

</code> **COMMAND** <code>
        TXDELAY -- Display / Set Port Transmit Delay.

</code> **SYNOPSIS** <code>
        TXD[ELAY] <port> [millisecs]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The TXDELAY command allows the value of the transmit 
        delay for a port to be displayed or altered. This is the
        interval between the transmitter being activated and the
        start of a transmitted packet. (see NOTES).

        Any changes made by this command override the settings
        specified in the PORT sections of XROUTER.CFG, and remain in
        force only until XRouter restarts.

        On KISS TNC's, you should allow up to 5 minutes for any new 
        setting to take effect.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies the 
        port number, and the second specifies the new value for the 
        parameter in milliseconds.

</code> **EXAMPLE** <code>
        TXDELAY 3       - Display current setting for port 3
        TXDELAY 3 300   - Set port 3 txdelay to 300 millisecs

</code> **NOTES** <code>
        TXDELAY is the interval between transmitter activation 
        and the start of a transmitted packet.  It allows time for the 
        RF to reach its full value, and for the TX audio circuits to 
        stabilise.  Some synthesised rigs require a large txdelay (500 
        or more) to allow the synthesiser to swing between RX and TX 
        frequencies, and many rigs have audio stages which take 100 ms 
        to stabilise while oversized electrolytics charge up.

        One factor which is often overlooked is the other end's 
        receiver.  It takes a finite time for the squelch to open, and 
        if the rig has just been transmitting it may take a while to 
        stabilise back to receiving, especially with synthesised rigs.
  
        If your txd is too short, you will be sending replies before 
        the other end is ready to hear you, and unnecessary retries 
        will result.

        Software TNC's such as "Direwolf" might complain that your
        TXDELAY setting is too long, but they have no knowledge of
        how long it takes the transmitter frequency to stabiise, nor
        how long it takes the link partnar's squelch to open, so you
        should ignore it and trust your own judgement!

</code> **SEE ALSO** <code>
        TXDELAY(7)     -- Transmit Delay.
        TXTAIL(1)      -- Transmit Tail Time.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TXOK ====
<code>TXOK(1)                 XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        TXOK -- Display / Set "ok to tx" for a port.

</code> **SYNOPSIS** <code>
        TXO[k] <port> [0 - 3]

</code> **DESCRIPTION** <code>
        Displays the current TXOK flag setting for a port, and allows 
        it to be changed.  This flag controls whether or not the 
        transmitter is allowed to key up, and whether or not the
        receiver is enabled.

        If two numeric arguments are supplied, the TXOK flag is set
        to  the second argument, otherwise the current setting for
        the specified port is displayed.

        Values are:  0 = TX disabled, RX enabled
                     1 = TX enabled,  RX enabled
                     2 = TX disabled, RX disabled
                     3 = TX enabled,  RX disabled

        State 2 would typically be used to disable all traffic on a
        port, to time out troublesome connections, or to do tests.

        By default, all ports have this flag set to 1 (TX and RX
        enabled).

        Modified settings remain in force until changed or system is 
        restarted.

</code> **EXAMPLE** <code>
        TXOK 3        - Display current setting for port 3
        TXOK 3 0      - Stop port 3 transmissions.

</code> **AVAILABILITY** <code>
        Requires SYSOP status.

</code> **CAVEATS** <code>
        It should be obvious, but setting TXOK=0 for the port you are
        using to send commands, will cause you to lose control of the
        node!

        Setting TXOK=0 does not actually disable the transmitter 
        itself, it merely prevents any frames being sent to the TNC, 
        so if the latter has a built-in CWID, it will still key up
        the TX so send the CWID.

</code>
----
==== TXPORT ====
<code>TXPORT(1)              XROUTER REFERENCE MANUAL              26/9/2023

</code> **COMMAND** <code>
        TXPORT -- Display / Set Port to Transmit On.

</code> **SYNOPSIS** <code>
        TXP[ort] <port> [destport]

</code> **AVAILABILITY** <code>
        Sysop only.

</code> **DESCRIPTION** <code>
        Displays or specifies the port upon which outgoing frames 
        should be transmitted. This would typically be used where
        there are several ports (e.g. multiple receivers) sharing a
        common transmitter.

        The minimum abbreviation of this command is TXP.

</code> **OPTIONS** <code>
        If "destport" is not specified, the current setting is 
        displayed.

        If "destport" is zero (the default setting), frames are
        received and transmitted on the same port.

        If "destport" is a valid port number, frames which would
        normally be transmitted on <port> are transmitted on
        "destport" instead.

</code> **EXAMPLES** <code>
        TXP 3 5   - Receive on port 3 and transmit on port 5

</code> **SEE ALSO** <code>
        TXPORT(7) -- Port to Transmit On.

</code>
----
==== TXTAIL ====
<code>TXTAIL(1)               XROUTER REFERENCE MANUAL             26/9/2023

</code> **COMMAND** <code>
        TXTAIL -- Display / Set Transmit Turnoff Delay.

</code> **SYNOPSIS** <code>
        TXT[AIL] <port> [millisecs]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The TXTAIL command allows the value of the transmit turnoff 
        delay for a port to be displayed or altered.  This is a 
        parameter used only by KISS TNC's, and you should refer to the 
        TNC documentation for an explanation. The default is 100 ms.

        Any changes made by this command override the settings
        specified in the PORT sections of XROUTER.CFG, and remain in
        force only until XRouter restarts.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies
        the port number, and the second specifies the new value for
        the parameter in milliseconds.

</code> **EXAMPLE** <code>
        TXTAIL 3       - Display current setting for port 3
        TXDELAY 3 100   - Set port 3 txtail to 100 millisecs

</code> **NOTES** <code>
        After modifying this value, you may have to wait up to 5 
        minutes for it to take effect.

</code> **SEE ALSO** <code>
        TXDELAY(1)     -- Display / Set TX Activation Delay.
        TXTAIL(7)      -- TX Tail Time. 
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== UDPLOCAL ====
<code>UDPLOCAL(1)           XROUTER REFERENCE MANUAL               26/9/2023
</code> **COMMAND** <code>
        UDPLOCAL -- Display / Set a port's UDPLOCAL parameter.

</code> **SYNOPSIS** <code>
        UDPLOCAL <port> [0-65535]

</code> **DESCRIPTION** <code>
        The UDPLOCAL command allows the UDP service number (often
        confusingly called a "port") at the local end of an AXUDP
        link to be displayed or altered. 

        This number must match the link partner's UDPREMOTE, i.e. the
        destination service number in the frames from him to you.

        If not specified, UDPLOCAL defaults to 93.

        It is usually specified within a PORT configuration block in
        the XROUTER.CFG file, but this command allows it to be
        changed on the fly, without needing to take XRouter off line.

        Please see the manual section on AXUDP for more information.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies
        the port number, and the second specifies the new value for
        the parameter.  The new setting remains in force until
        changed, or until XRouter is restarted, in which case the
        value specified in the XROUTER.CFG file is reapplied.

</code> **EXAMPLE** <code>
        UDPLOCAL 3       - Display current UDPLOCAL for port 3
        UDPLOCAL 3 9393  - Set port 3 UDPLOCAL to 9393

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        UDPLOCAL(7)    -- Local UDP POrt.
        UDPREMOTE(1)   -- Display / Set a port's UDPREMOTE parameter.
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== UDP ====
<code>UDP(1)                  XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        UDP -- UDP status and statistics commands.

</code> **SYNOPSIS** <code>
        UD[p] S[ockets]
        UD[p} ST[ats]

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The UDP command is used to display the active UDP sockets,
        their status, and UDP layer statistics.

</code> **OPTIONS** <code>
        UD[p] S[ockets] display the active UDP sockets, along with
        their local addresses and port numbers, the stack they are
        using, and the number of frames queued for reception. For
        example:

           Sock#  Local_address          Stack    Rxq
          7338e0  0.0.0.0 9701           O/S        0
          733b78  0.0.0.0 9702           O/S        0
          737050  127.0.0.1 10095        O/S        0
          737768  0.0.0.0 10094          O/S        0
          731dc0  0.0.0.0 53             XrLin      0 

        "0.0.0.0" means "any IP address". "O/S" means the socket is
        on the operating system's stack.


        UD[p} ST[ats] produces a display like this:
                                                                                               
             19 Segments sent,    921 bytes
           2178 Segments rcvd, 177583 bytes
              0 Malformed segments rcvd
              0 Segments rcvd with bad checksum
           2160 Unwanted segments rcvd
              0 Broadcast segments
              0 Segments ignored from banned IP's
              0 Attempted Fraggle attacks

        The fields are largely self-explanatory.

        "Malformed segments" are those which are too short to contain
        a valid UDP header.

        "Unwanted segments" is the number of UDP frames received for
        which there was no receive socket.

        "Broadcast segments" is the number of UDP frames whose
        destination IP was the subnet broadcast address.

        A "fraggle attack" is one where an attacker sends a large
        amour of data with spoofed source addresses to the ECHO (7)
        or CHARGEN (19) ports. XRouter does not implement those
        services on UDP, but keeps records so that attacks can be
        detected.

</code> **SEE ALSO** <code>
        TCP(1) -- Display TCP status

</code>
----
==== UDPREMOTE ====
<code>UDPREMOTE(1)            XROUTER REFERENCE MANUAL            21/10/2023
</code> **COMMAND** <code>
        UDPREMOTE -- Display / Set a port's UDPREMOTE parameter.

</code> **SYNOPSIS** <code>
        UDPREMOTE <port> [0-65535]

</code> **DESCRIPTION** <code>
        The UDPREMOTE command allows the UDP service number (often
        confusingly called a "port") at the remote end of an AXUDP
        link to be displayed or altered. 

        This is the UDP destination number in the AXUDP frames from
        you to your link partner. It must match the link partner's
        UDPLOCAL, otherwise the link will not function.

        If not specified, UDPREMOTE defaults to 93.  It is only used
        on AXUDP ports.

        It is usually specified within a PORT configuration block in
        the XROUTER.CFG file, but this command allows it to be
        changed on the fly, without needing to take XRouter off line.

        Please see the manual section on AXUDP for more information.

</code> **OPTIONS** <code>
        If a single numeric argument is supplied, the current value 
        for that port number is displayed.

        If two numeric arguments are supplied, the first specifies
        the PORT number, and the second specifies the new value for
        the  parameter.  The new setting remains in force until
        changed, or until XRouter is restarted, in which case the
        value specified in the XROUTER.CFG file is reapplied.

</code> **EXAMPLE** <code>
        UDPREMOTE 3       - Display UDPREMOTE setting for port 3
        UDPREMOTE 3 9393  - Set port 3 UDPREMOTE to 9393

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **SEE ALSO** <code>
        AXUDP(9)        -- AX25-over-UDP Tunnelling.
        UDPLOCAL(1)     -- Display / Set a port's UDPLOCAL parameter.
        UDPREMOTE(7)    -- Remote UDP Port for Link.
        XROUTER.CFG(8)  -- Main Configuration File

</code>
----
==== UNPROTO ====
<code>UNPROTO(1)            XROUTER REFERENCE MANUAL               26/9/2023

</code> **COMMAND** <code>
        UNPROTO -- Display / Set Path for Unproto Broadcasts.

</code> **SYNOPSIS** <code>
        UN[proto] <port> [path]

</code> **AVAILABILITY** <code>
        Sysop only.

</code> **DESCRIPTION** <code>
        Displays or modifies the destination callsign, and digipeater
        path for "unproto" broadcasts from applications on this port.

        If "path" is not specified, the current path (i.e. destination
        and digipeater callsigns) is displayed.

        If "path" is specified, the UNPROTO parameter for the
        specified port is changed to the new value.

        The "path" argument should be supplied in the form

                <destcall>[,digicall,digicall,...]

        where <destcall> is the destination (i.e. "to") callsign, and
        [digicall] are optional digipeater callsigns.

        The minimum abbreviation of this command is UN.

</code> **EXAMPLES** <code>
        UNP 3            - Display current UNPROTO for port 3
        UNP 3 CQ,G7GJP   - Set port 3 UNPROTO to "CQ" via G7GJP

</code> **SEE ALSO** <code>
        UNPROTO(7)  -- Path for Unproto Broadcasts.
        APRSPATH(7) -- Default Digipeater Path for APRS.

</code>
----
==== USERS ====
<code>USERS(1)                XROUTER REFERENCE MANUAL            19/10/2023
</code> **COMMAND** <code>
        USERS -- Show Who is Using XRouter.

</code> **SYNOPSIS** <code>
        U[sers]

</code> **DESCRIPTION** <code>
        The USERS command displays the ISO layer 7 sessions which
        originate or terminate at XRouter.  Unconnected "through
        traffic" is not shown by this command.

        No arguments are required, and a typical response includes
        the following fields:

                Session  Start-time   Idle   Type  Lnk   User

        "Session" is a unique session number for the connection.

        "Start-time" is the date/time when the uplink was first made.

        "Idle" is the amount of time since there was any activity on
               the session.

        "Type" is the session type:

            AGWH - AGW Host app        APPL - Uplink to app
            APRS - APRS Server         AX25 - AX25L2
            CHAT - Chat session        CHGN - CHARGEN
            CONS - Console             DAYT - Daytime server
            DEDH - WA8DED Host app     DSCD - Discard server
            DXSV - DX Server           ECHO - Echo server
            FING - Finger server       FTPC - FTP Client
            FTPS - FTP Server          FTPX - FTP Proxy
            HLIB - Hamlib              Host - BPQHost application
            HTRM - HTTP Terminal       HTTP - HTTP Server
            INFO - Info server         MHSV - MHeard Server
            MQTT - MQTT Server         NFTP - Netrom FTP
            NTPX - NetRom/TCP Proxy    NTRM - Netrom
            PMS  - Personal Msg System PRXY - Proxy
            PSTN - Dial-in             RHP  - RHP app
            RHPC - RHP Control Sess    RHPP - RHP SeqPacket Socket
            RHPS - RHP Stream Socket   RIGS - Rig Server
            RLOG - Remote Login        SMS  - Short Message
            Sock - Socket app          SOKH - Uplink to Socket host
            SOKS - SOCKS Proxy         Teln - Telnet
            TPXY - Telnet Proxy        TTY  - Serial TTY 
            TTYL - TTYLink             WXSV - Weather server     

        "Lnk" is the uplink type:

            CON - Console           TCP - TCP/IP
            TTY - Remote console    HST - Hosted application
            L2  - AX25 level 2      RHP - Remote Host Protocol app
            L4  - NetRom level 4    DED - DEDHOST application
            TRM - HTTP Terminal

        "User"  is the callsign or Internet address of the uplinked
                user. There may be another user shown on the
                downlink side.

        In this context UPLINK is a connection from a user (who may
        be located at another node) to the router, and DOWNLINK is a
        connection from the router to a user. The combination of both
        is called a CIRCUIT.

        Established circuits are shown by <--> and circuits being set 
        up are shown thus:  <~~>.

</code> **PORTABILITY** <code>
        Unlike the equivalent BPQ command, this does not show the 
        version number - use the VERSION command for that, or buffer 
        count (this system does not use fixed buffers).

</code> **SEE ALSO** <code>
        J(1) -- Show Recent Sessions

</code>
----
==== VERSION ====
<code>VERSION(1)              XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        VERSION -- Display software version and author.

</code> **SYNOPSIS** <code>
        V[ersion]

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The VERSION command, which takes no arguments, displays the 
        software version, author and compilation date.

        This information may be needed when upgrading to later 
        versions of the program or its files.

        Please specify the version when reporting bugs.

</code>
----
==== WAIT ====
<code>WAIT(1)                XROUTER REFERENCE MANUAL               6/9/2023
</code> **COMMAND** <code>
        WAIT -- Pause Execution.

</code> **SYNOPSIS** <code>
        WA[it] <(secs<60) | (ms>60)>

</code> **AVAILABILITY** <code>
        Sysop-only.

</code> **DESCRIPTION** <code>
        The WAIT command is intended for use only in BOOTCMDS.SYS.

        It causes execution to pause for the specified time. This
        can be used between commands that need time to execute, such
        as the setting up of tunnel interfaces.

        If the argument to WAIT is less than 60, it is treated as
        SECONDS, otherwise it is treated as milliseconds.

        The following example shows 300ms pauses betwen Linux shell
        commands when setting up a tunnel interface. The sequence
        does not work if the pauses are removed.

        # BOOTCMDS.SYS
        #
        # For setting up tunnels:
        # Assign the address 192.168.0.98 to the Linux end of tun99:
        shell ip address add 192.168.0.98 dev tun99
        #
        wait 300
        #
        # Tell Linux that 192.168.0.99 is on the other end of tun99:
        shell ifconfig tun99 dstaddr 192.168.0.99
        #
        wait 300
        #
        # Bring up the Linux end of the interface:
        shell ip link set dev tun99 up

</code> **SEE ALSO** <code>
        SHELL(1)        -- Run commands/programs in a Linux 'shell'
        BOOTCMDS.SYS(8) -- Commands to Execute at Bootup

</code>
----
==== WALL ====
<code>WALL(1)                XROUTER REFERENCE MANUAL               7/12/2023
</code> **COMMAND** <code>
        WALL -- Access Message Wall(s)

</code> **SYNOPSIS** <code>
        W[all] [nodecall | nodealias] 

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The WALL command connects the user either to this node's
        message "wall", or to the wall on another XRouter. 

        The "wall" is a public message board / guestbook where users
        can leave short text messages, comments, suggestions,
        reminders, observations etc.  Think of it as a text-only
        version of the old Facebook wall.

        Unlike a BBS, wall messages are not forwarded to other systems,
        and they do not expire. They have no "to" or "subject" fields,
        they are just a string of text, like a tweet.

        The wall may also be operated via the sysop's web interface,
        via MQTT, and via REST.

        The WALLFLAGS directive enables or disables the wall, and
        controls whether the sysop is notified (via the PMS) of new
        posts. It also controls whether postss and replies are
        published to the MQTT broker.

</code> **OPTIONS** <code>
        If no argument is supplied to the WALL commmand, the user is
        connected to the local wall.

        If the argument is the nodecall or alias of another XRouter,
        which is in the nodes table, the user is connected to the
        wall of that node instead.

        After the WALL command is issued, the user is shown the most
        recent 5 messages in reverse chronological order, plus a menu
        with the following options:

        H[elp]   Displays this help.

        L[ist]   Displays or re-displays up to 5 messages at a time.
                 Messages are displayed in reverse chronological order,
                 i.e. the most recent at the top.

        O[lder]  Displays up to 5 older messages, i.e. back in time.

        N[ewer]  Displays up to 5 newer messages, i.e. forward in time.

        W[rite]  Begins message entry. Messages can be up to 255
                 characters, and are posted upon receipt of a <CR>
                 (carriage return).

        D[elete] Deletes a message that the user has just entered.
                 The user cannot delete other people's posts. Only the
                 sysop can do that.

        Q[uit]   Returns the user to the node.

</code> **EXAMPLES** <code>
        WALL       -- Connect to the wall on this node
        WALL G8PZT -- Connect to the wall on G8PZT node.

</code> **SEE ALSO** <code>
        BLOG(1)      -- Access Sysop's Blog.
        MQTT-WALL(9) -- MQTT Interface to Message Wall.
        PMS(1)       -- Personal Message System.
        WALLFLAGS(7) -- Options For Message Wall.

</code>
----
==== WATCH ====
<code>WATCH(1)                XROUTER REFERENCE MANUAL              8/5/2024

</code> **NAME** <code>
        WATCH -- Watch Packet Traffic on Port(s).

</code> **SYNOPSIS** <code>
        WAT[ch] port[+port..] | [OFF]

</code> **DESCRIPTION** <code>
        The WATCH command, which can be abbreviated to "WAT", allows
        any user to monitor packet traffic on one or more of the
        node's ports.

        For security reasons, non-sysops are only allowed to watch
        RADIO ports. The user can not watch the port upon which they
        are uplinked to the node.

        All the normal node commands are available whilst in "watch"
        mode. If the amount of monitored traffic exceeds the capacity
        of the user's uplink, some traffic may be discarded.

</code> **OPTIONS** <code>
        To watch a single port, use WATCH <portnum>, e.g. WATCH 3.

        To watch multiple ports, either specify their numbers in a
        string separated by '+' signs, e.g. "WATCH 3+4+5", or issue
        the command more than once.

        Use "WATCH OFF" to terminate traffic monitoring.

</code> **AVAILABILITY** <code>
        All users.

</code> **SEE ALSO** <code>
        LISTEN(1) -- Listen For Incoming Connections.

</code>
----
==== WX ====
<code>WX(1)                  XROUTER REFERENCE MANUAL               6/9/2023
</code> **COMMAND** <code>
        WX -- Display Weather Information.

</code> **SYNOPSIS** <code>
        WX [callsign | LOCAL]

</code> **AVAILABILITY** <code>
        All users

</code> **DESCRIPTION** <code>
        The WX command is used to display a list of up to 5 local
        APRS weather stations, and to display a weather summary from
        specified stations.

        The information displayed includes: date and time of reading,
        distance and direction of server, pressure, wind speed and
        direction, gust speed, temperature, humidity, and rainfall.

</code> **OPTIONS** <code>
        If no argument is supplied, the callsigns of the available
        weather stations (if any) are displayed.

        If the argument is the callsign of one of the stations in the
        list, the weather summary from that station will be displayed.

        However, if [callsign] is not in the list of stations
        returned by WX", and it matches the callsign or alias of an
        XRouter in the nodes table, a connection to that node's
        weather service is attempted. If successful, the weather
        information is returned, like this:

        wx g8pzt
        G8PZT-1:MOBILE} Trying G8PZT::16...
        G8PZT-1:MOBILE} Connected to G8PZT::16

        Observed: Mon 17 May 2021 06:01:23 +0001
        Pressure: 1007.2 mB
        Temperature: 11.2 C
        Humidity: 67 %
        Wind: 23 mph
        Direction: 178 deg
        Gust: 31 mph
        Rain-24h: 24.7 mm
        Rain-Today: 19.7 mm
        Rain-1h: 3.2 mm

        G8PZT-1:MOBILE} Welcome back

        The special case "WX LOCAL" returns the local WX information,
        if available.

</code> **EXAMPLE** <code>
        WX           - Display local APRS weather stations
        WX G6GUH-3   - Display weather summary from station G6GUH-3

</code> **LIMITATIONS** <code>
        The collection of weather data requires at least one APRS RF
        port, plus a weather station within range. Failing that,
        weather data will be collected if the IGATE daemon is running
        and connected to a suitable APRS server.  Alternatively it
        can be imported every minute from a file.

</code> **SEE ALSO** <code>
        WX-SVC(9) -- NetRomX Weather Service

</code>
----
==== XLINK ====
<code>XLINK(1)                XROUTER REFERENCE MANUAL            17/10/2023
</code> **COMMAND** <code>
        XLINK -- Establish a Temporary SLIP / PPP Interlink

</code> **SYNOPSIS** <code>
        X[link] <SLIP | PPP>

</code> **DESCRIPTION** <code>
        The XLINK command switches a dialled-in connection into the 
        specified mode, allowing TCP/IP operations to be conducted 
        between the caller and XRouter.

        The temporary interlink persists until the line is 
        disconnected or, in the case of PPP, an inactivity timeout.

</code> **EXAMPLE** <code>
        XLINK PPP

</code> **FILES** <code>
        Temporary SLIP interlinks require no configuration. Temporary 
        PPP interlinks may optionally be configured by including PPP 
        commands in a PPPHOST.n file, where n is the port number.

</code> **AVAILABILITY** <code>
        The command is available to all users, but is only actioned
        on MODEM (dial-in) ports.

</code> **SEE ALSO** <code>
        PPP(1) -- PPP commands

</code>
----
==== YELL ====
<code>YELL(1)                 XROUTER REFERENCE MANUAL             29/9/2023
</code> **COMMAND** <code>
        YELL -- Yell for sysop

</code> **SYNOPSIS** <code>
        Y[ell]

</code> **AVAILABILITY** <code>
        All users.

</code> **DESCRIPTION** <code>
        The YELL command attempts to attract the attention of the
        sysop by making a distinctive sound on the console and
        displaying a message.  If the sysop is available she may then
        break in on your session for a one-to-one chat.

</code> **LIMITATIONS** <code>
        A yell may not always be successful because (a) the sound may
        be disabled during unsociable hours, (b) the sysop may be
        away from the console or busy talking to someone else, (c)
        there may not even be a loudspeaker in the computer, or (d)
        the node may be located on a remote hilltop or in someone's
        garage.

</code> **SEE ALSO** <code>
        TALK(1) -- Talk to a user

</code>
----