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 8 - Configuration  and System Files=======
=====ACCESS=====
<code>ACCESS.SYS(8)           XROUTER REFERENCE MANUAL             28/2/2025
</code> **NAME** <code>
        ACCESS.SYS -- Telnet Access Control File.

</code> **DESCRIPTION** <code>
        This optional file is read only at bootup. It specifies
        TCP/IP access requirements according to the caller's IP
        address.  If not present, the default action is for 
        logins to require a valid callsign only.

</code> **FORMAT** <code>
        The entries in ACCESS.SYS are of the form:

              <subnet>[/bits] <access_flags>

              e.g. "44.0.0.0/8 1"

        The <subnet> and [bits] parameters define a range of IP
        addresses from whom Telnet connects will be accepted, and
        <access_flags> defines  the login requirements for that
        subnet.

        The [bits] parameter specifies how many bits, from left to
        right, of the source address should be matched against the
        corresponding <subnet> address.  For example, 44.131.0.0/16
        will test the source IP address against the left-most 16
        bits of 44.131.0.0, i.e. it will match any source address
        beginning with 44.131. And 0.0.0.0/0 will match any IP
        address, which is useful for specifying the default. The 
        chosen match will be the one with the highest [bits] value.
        If [bits] is not specified, it defaults to 32, i.e. an exact
        match is required.

        The <access_flags> parameter is the sum of these flag values.

              1       Valid callsigns only
              2       Password required
              4       Guest access allowed
              8       This IP address [range] is trusted

        Typical combinations are as follows:

        0 - Any "callsign" longer than 1 character is accepted, and
            no password is required.  In this context, "callsign"
            could be a user name.  This is a zero security option,
            for use only for the sysop's convenience on physically
            secure subnets.

        1 - The user is required to enter a valid amateur radio
            callsign, i.e. a string containing alphanumeric
            characters in the  correct format, but no password is
            required.  This is a low security configuration with
            minimal inconvenience, and is suitable for use within
            amateur radio subnets which are not connected to the
             Internet. This configuration is recommended for callers
            who have 44.x.x.x source address, as they are presumed
            to have entered the network via radio, or via a
            password-protected gateway.

        2 - XRouter will accept any "username" longer than one
            character, providing a valid password is given.  This is
            a medium security configuration, suitable for use on
            private wire subnets where amateur radio callsigns are
            not used.

        3 - Both a valid amateur radio callsign and a matching
            password must be supplied. This configuration is
            recommended for use at the Internet-to-Amprnet interface,
            i.e. for all source IP addresses other than 44.x.x.x

        4 - Any "callsign" longer than 1 character is accepted, and
            no password is requested or required. All users have
            guest access, ie they cannot downlink.

        5 - The user is required to enter a valid amateur radio
            callsign, but no password is requested or required. All
            users have guest access, ie they cannot downlink.

        6 - Any "callsign" longer than 1 character is accepted.
            User is challenged to enter a password, but the option
            to use the password "guest" is available.  If the user
            gives a valid password he gets full access, but if he
            answers with "guest" he only gets guest access.

        7 - The user is required to enter a valid amateur radio
            callsign, and he is challenged to enter a password, but
            the option to use the password "guest" is available.  If
            the user gives a valid password he gets full access, but
            if he answers with "guest" he only gets guest access.
            This setting is recommended for source addresses which
            aren't either private LAN or 44.x.x.x.

        8 - The specified address [range] is to be treated in the same
            way as a "LAN" address.  Used mainly to prevent HTTP, RHP,
            AGWHOST etc from requiring authorisation when used via a
            VPN.  This flag DOES NOT affect Telnet and FTP logins.

</code> **EXAMPLE** <code>
        # Subnet[/bits]          flags
        # ==============================
        #
        # HTTP/RHP from this VPN subnet do not require authorisation
          207.221.31.0/8          8
        #
        # Amprnet users need only supply a callsign
          44.0.0.0/8              1
        #
        # LAN users need only supply a callsign
          192.168.0.0/24          1
        #
        # Everyone else must supply callsign and password, but
        # "guest" is allowed as a password, giving read-only access.
          0.0.0.0/0               7


</code> **GUEST ACCESS** <code>
       Guest access is intented to let people look around, but not
       to do anything that would cause a transmission to be made.

       Guests are prevented from using the SEND, CHAT and CONNECT
       commands, and from sending APRS messages using the APRS
       messaging shell.  For the TELNET command they are restricted
       by the rules in the file TELGUEST.ACL. If that file is not
       present, guests are denied access to the TELNET command.

       Guests are not necessarily unlicenced people. They may simply
       be hams who don't yet have a password for your system.

</code> **PASSWORDS** <code>
      If passwords are required for user access, they should be
      located in file USERPASS.SYS, which is used for "normal"
      telnet (port 23) logins.

      Do not confuse this with PASSWORD.SYS, which is used for
      sysop logins via AX25, Rlogin and FTP.

</code> **SEE ALSO** <code>
        PASSWORD.SYS(8) -- Sysop passwords file
        TELGUEST.ACL(8) -- Telnet egress control file
        USERPASS.SYS(8) -- User passwords file

</code>
----
=====BADWORDS=====
<code>BADWORDS.SYS(8)         XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        BADWORDS.SYS -- Bad Words File for Mailbox.

</code> **DESCRIPTION** <code>
        BADWORDS.SYS is an optional file, used by the mailbox to
        check new mail for inapproriate content. If present, it is
        located in the PMS subdirectory. 

        It contains a list of words or part-words, one per line,
        which are deemed unacceptable in Packet mail. If any of the
        words are matched in the text of a new message, the message
        is held for review. Held messages are not forwarded, and are
        only visible to sysops.

        Wildcards are allowed, but "*" is only allowed at the END of
        a word.

        Only single words are allowed at present, no phrases. Words
        are not case-sensitive.

        Comment lines must begin with hash (#) or semicolon (;) in
        the leftmost column.

        The supplied file dates from the 1990s, and will probably
        need updating or replacing with words appropriate to your own
        language.

        If the file is not present, mail is not checked.

</code> **NOTE** <code>
        False matches sometimes occur. For example "CUNT" appears in
        the place name Scunthorpe. This issue may be fixed in a future
        version.

</code> **SEE ALSO** <code>
        LH(4)  -- List Held Mail
        KH(4)  -- Kill Held Mail
        UH(4)  -- Un-hold Mail
        PMS(9) -- About the Mailbox
        
</code>
----
=====BOOTCMDS=====
<code>BOOTCMDS.SYS(8)         XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        BOOTCMDS.SYS -- Commands to Execute at Bootup.

</code> **DESCRIPTION** <code>
        This optional file is read by XRouter at boot time, after
        XROUTER.CFG and IPROUTE.SYS.  It is mainly used for
        configuration commands that have no keywords in XROUTER.CFG,
        such as the GNET and PPP commands.

</code> **FORMAT** <code>
        Format is exactly the same as keyboard-entered commands,
        with one command per line. Lines beginning with '#' or ';'
        are ignored, and may be used for comments.

</code> **OPTIONS** <code>
        Whilst many commands *can* be used in BOOTCMDS.SYS, there is
        often no point in doing so, because they duplicate the
        function of configuration directives. For example there's no
        point including "Paclen 3 120", when it is just as easy to
        put PACLEN=120 in the port 3's configuration block. However,
        most of the commands listed below can also be used in
        CRONTAB.SYS, where they DO have a purpose.

        Commands that can be used in BOOTCMDS.SYS are as follows:

        ACL, APPLMASK, ARP, BCAST, BELL, BLEVEL, CAPTURE, CFLAGS,
        CTEXT, CTFLAGS, CTRL, DIAL, DHCP, DIGIFLAG, DIGIPORT, DNS,
        DUN, EXCLUDE, EXIT, FEC, FRACK, FULLDUP, GNET, ID, IDPATH,
        IDS, IDTEXT, IFACE, IPADDRESS, IPLINK, LOADNODES, LOG,
        MAXFRAME, MDIR, MFROM, MHCLEAR, MHFLAGS, MHSIZE, MINQUAL,
        MINTXQUAL, MMASK, MON, MPORT, MQTT, MTO, NAT, NETMASK,
        NODESINT, NOTIFY, ODN, PACLEN, PCAP, PEERS, PERSIST, PING,
        PIPE, PIPEFLAG, PORT, PPP, QUALITY, RESPTIME, RESTART,
        RETRIES, RIP, ROUTE, SAVENODES, SEND, SHELL, SLOTTIME, START,
        STATS, STOP, TCP, TSYNC, TXDELAY, TXOK, TXPORT, TXTAIL, UDP,
        UDPLOCAL, UDPREMOTE, UNPROTO, USERS, WAIT, WX.

</code> **EXAMPLES** <code>
        # This is a comment line
        GNET ADDR 131.91.1.1
        GNET ROUTE ADD 147.38.1.1 zl2aqy

</code> **SEE ALSO** <code>
        CRONTAB.SYS(8) -- Event Control File.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
=====CRONTAB=====
<code>CRONTAB.SYS(8)          XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        CRONTAB.SYS -- Event Control File (optional).

</code> **DESCRIPTION** <code>
        This optional file allows XRouter commands to be executed at
        certain times of the day, week, month or year.

        A few of the possible uses would be:

        - Additional AX25 beacons.
        - Beaconning APRS objects, status, bulletins and
          announcements.
        - Adjusting Netrom / IP routing to account for part-time
          neighbours.
        - Enabling / disabling transmitters.
        - Controlling peripherals via the CTRL port.
        - Adjusting parameters to cope with diurnal propogation
          changes.
        - Loading updated ENCAP.TXT at intervals.
        - Enabling / disabling IGATE at certain times of day / week.
        - Automatic reboots / restarts / exits for batch file
          processing etc.

        When commands are executed, all responses from the command
        processor are discarded.

</code> **OPTIONS** <code>
        Commands that can be used in CRONTAB.SYS are as follows:

        ACL, APPLMASK, ARP, BCAST, BELL, BLEVEL, CAPTURE, CFLAGS,
        CTEXT, CTFLAGS, CTRL, DIAL, DHCP, DIGIFLAG, DIGIPORT, DNS,
        DUN, EXCLUDE, EXIT, FEC, FRACK, FULLDUP, GNET, ID, IDPATH,
        IDS, IDTEXT, IFACE, IPADDRESS, IPLINK, LOADNODES, LOG,
        MAXFRAME, MDIR, MFROM, MHCLEAR, MHFLAGS, MHSIZE, MINQUAL,
        MINTXQUAL, MMASK, MON, MPORT, MQTT, MTO, NAT, NETMASK,
        NODESINT, NOTIFY, ODN, PACLEN, PCAP, PEERS, PERSIST, PING,
        PIPE, PIPEFLAG, PORT, PPP, QUALITY, RESPTIME, RESTART,
        RETRIES, RIP, ROUTE, SAVENODES, SEND, SHELL, SLOTTIME, START,
        STATS, STOP, TCP, TSYNC, TXDELAY, TXOK, TXPORT, TXTAIL, UDP,
        UDPLOCAL, UDPREMOTE, UNPROTO, USERS, WAIT, WX.

</code> **FILE FORMAT** <code>
        Each entry is specified on a seperate line. Empty lines,
        and lines beginning with '#' or ';' are ignored.

        Entries have the following format:

            <min> <hour> <date> <month> <day> <command> [args]
            0-59   0-23   1-31   1-12    0-6 

        Fields must be seperated by one or more spaces or tabs.

        <command> is executed if <min> <hour> and <month> match
        the current time, and either the <date> (day of month)
        or <day> (of week) match. [args] specifies the command's
        argument(s).

        Dates / times may be specified as single numbers, multiple
        numbers, ranges, or a mixture thereof, e.g. "0-5,7,9,15-22". 
        Note there must be no spaces within the string of characters.

        Use '*' in any of the first 5 fields to signify "all".

</code> **EXAMPLES** <code>
        ; <min> <hour> <date> <month> <day> <command> [args]
        ; Every 20 mins, advertise the BBS using an APRS symbol
        ; on port 13
        0,20,40 * * * * send 13 APZ179 !5224.00N/00215.00WB GB7PZT

        ; Every Thursday at 03:05 save nodes table to an archive
        5 3 * * 4 SAVENODES PZTNODES.ACV

</code>
----
=====DEUTSCHE=====
<code>DEUTSCHE.SYS(8)         XROUTER REFERENCE MANUAL            22/10/2023
</code> **NAME** <code>
        DEUTSCHE.SYS -- German Language Texts for XRouter.

</code> **DESCRIPTION** <code>
        DEUTSCHE.SYS is an optional file containing german language
        texts for use within XRouter.

        If present in the same directory as the XRouter executable,
        the contents of this file are read at bootup only, adding
        German prompts, headings and responses for those who select
        the German language option.

        If this file is not present, XRouter defaults to ENGLISH.

        If you can improve on the translation, please do so, and
        please share your work.

        Be careful with modifications, because some of the texts are
        used in multiple places, and some of them are column headers
        which need to follow a strict format.

        Modifications to this file do not affect other languages.

</code> **FORMAT** <code>
        Each text is on a separate line, which begins with a number
        corresponding to that text. Following the number is some 
        whitespace, then the text itself is enclosed in quotes.  For
        example:

            12 "Syntaxfehler\r"

        Most texts end with "\r" (carriage return, ASCII 13), but not
        all of them do. "Hanging" prompts and individual words don't.

        Blank lines, and lines which begin with '#' in the leftmost
        column are ignored. The latter can be used for comments.

        Some texts contain one or more placeholders such as "%s",
        "%d" etc. You may move their position within a text, but if
        you change them, you will cause XRouter to crash.

        For example, you could safely re-word the following:

            73  "Sesión %d No encontrado\r"

        to the following:

            73  "No puedo encontrar la sesión %d\r"

        "%d" is a placeholder for an integer
        "%s" is a placehlder for a string of characters

        Changes don't take effect unless XRouter is restarted.

        Text numbers fall into the following ranges:

            1-999 General texts
            1000  PZTDOS texts
            2000  AX25/NetRom texts
            3000  Chat server texts
            4000  APRS Messaging System Texts
            5000  FTP Client texts
            6000  PMS Texts
            7000  IDS (Intrusion Detection System) texts

        If a required text is not found in the file (e.g. it has
        been deleted or commented out), the inbuilt English text is
        used instead.

</code> **SEE ALSO** <code>
        CONSOLELANG(7)  -- Console language
        DEFAULTLANG(7)  -- Specify default language
        ENGLISH.SYS(8)  -- English Language Texts
        ESPANOL.SYS(8)  -- Spanish Language Texts.
        FRANCAIS.SYS(8) -- French Language Texts
        LANGS.SYS(8)    -- Language selection file

</code>
----
=====DISTRIB=====
<code>DISTRIB.SYS(8)          XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        DISTRIB.SYS -- Mail Distribution File.

</code> **DESCRIPTION** <code>
        Optional file DISTRIB.SYS controls queuing of mail for
        delivery to neighbouring mailboxes.

        If present, it is located in XRouter's PMS subdirectory. If
        the file is absent, mail is not delivered to other mailboxes.

        The file is read "live" upon receipt of each item of
        "forwardable" mail, which means it can be edited on the fly,
        with modificatiions taking immediate effect.

</code> **FORMAT** <code>
        Lines must not exceed 127 characters. Comment lines are
        allowed. These must start with '#' or ';' in first column.

        DISTRIB.SYS contains "rules" for mail distribution. If there
        are no rules, there can be no mail forwarding

        Each "rule" consists of a minimum of 4 and a maximum of 5
        fields on a single line.  The fields, which may be separated
        by spaces or tabs, are as follows:

            <type>  <to>  <at>  <via>  [max_size]

        <type>  Message type (e.g. P, B or *)

        <to>    Message recipient or bulletin category (wildcards ok)
                If the <to> field starts with a caret '^', it REJECTS
                the message if it matches. e.g. "^EQUAKE" prevents
                distribution of EQUAKE messages.

        <at>    Distribution area, e.g. "GB7PZT", "EU" or "#24.GBR".
                This is a "sliding match", so EU matches EU and EURO,
                GBR matches .#76.GBR.EURO and so on. Wildcards are NOT
                alllowed in this field except for "*" by itself,
                meaning "match any".

        <via>   Callsign (minus SSID) of the neighbouring mailbox to
                which the item of mail should be sent.

        [max_size] is optional. If present, it specifies the maximum
                   message size in bytes. Messages whose size exceeds
                   this value are not queued.

</code> **OPERATION** <code>
        Each new message is tested against the rules, looking for a
        matching rule. If <type> <to> and <at> all match the fields
        of the message, the latter is placed on the queue for the
        mailbox specified by <via>. The queue is later processed
        according to the rules in FWD.SYS.

        Rules are processed in the sequence in which they are
        declared. Therefore "reject" entries MUST be declared before
        "accept" entries.

        Private mail is queued for the FIRST match only.
        Bulletins are distributed to ALL matching entries.

</code> **EXAMPLE** <code>
        The organisation of this file is up to you, but the following
        method is recommended.

        Firstly, route any private mail addressed TO nearby sysops
        and users. This ensures delivery even if the hierarchical
        address is wrong:

            # <type> <to>    <at>    <via>   [max_size]
            # --------------------------------------------------
                P    VA2OM   *       VE2PKT
                P    VE2PKT  *       VE2PKT
                P    MW0NXT  *       GB7NXT

        Next, handle mail explicitly addressed AT neighbour BBS's.
        Again, this guards against incorrect hierarchical addresses.

            # <type> <to>    <at>    <via>   [max_size]
            # --------------------------------------------------
                *    *       VA2OM   VE2PKT
                *    *       VE2PKT  VE2PKT
                *    *       GB7NXT  GB7NXT

        Finally, handle bulletin distribution. In this case, all
        EQUAKE bulletins are ignored. All remaining bulls go to
        VE2PKT, but only GBR, EU and WW are sent to GB7NXT.

            # <type> <to>    <at>    <via>   [max_size]
            # --------------------------------------------------
                B    ^EQUAKE *       *
                B    *       *       VE2PKT
                B    *       GBR     GB7NXT
                B    *       EU      GB7NXT
                B    *       WW      GB7NXT  5000

</code> **SEE ALSO** <code>
        FWD.SYS(8) -- Mailbox Forwarding Control File
        PMS(9)     -- About the Mailbox.

</code>
----
=====DOMAIN=====
<code>DOMAIN.SYS(8)           XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        DOMAIN.SYS -- Hostname Resolution File.

</code> **DESCRIPTION** <code>
        This optional file is used to "resolve" host names such as
        "g8jvm.ampr.org" and aliases such as "lgsbbs" into their
        corresponding IP addresses. 

        It is the first place XRouter looks when resolving a hostname.
        If the file is not present, or the hostname is not found in
        in the file, XRouter queries a DNS (Domain Name Server) to
        obtain the information (in order for this to work, either
        Windows/Linux or XRouter must have a network connection to an
        external DNS).

        If no DNS is available, and the hostname is not found in
        DOMAIN.SYS, you will have to enter the full IP address of
        the target host when using the PING, TELNET, TTY, and FINGER
        commands. 

        Name resolution using a radio-based DNS is quite slow, so if
        you are using this mode you should add entries to this file
        for frequently contacted hosts whose addresses are stable.
 
        Externally resolved names are added automatically to
        DOMAIN.SYS at regular intervals, and expired entries are
        purged.

</code> **FILE FORMAT** <code>
        Each host is listed on a separate line.  Each field must be
        separated by one or more spaces or tabs.  Comments, spaces,
        tabs and blank lines are permissible to aid clarity.  The
        records are case-insensitive, but most people use lower case
        for hostnames.  The format of each record is as follows:

             <hostname> [ttl] IN A <ip-address>

             <alias>    [ttl] IN CNAME <hostname>
             
             <hostname> [ttl] IN MX [pref] <hostname>

        The first form maps a hostname to an IP address, and the
        second and third forms map alternative hostnames to a host
        that is already defined.  

        For example, the IP address for the GB7PZT mailbox is
        44.131.91.2 so it would have an Internet Address (IN A)
        record like so:

             gb7pzt  IN   A    44.131.91.2

        But gb7pzt is also known locally as "pztbbs", and "kdrbbs". 
        There is nothing to stop you adding further "IN A" records
        for gb7pzt, one for each alias, but you could instead use
        the second form shown above, the CNAME or "Canonical Name"
        record like so:

             pztbbs. IN CNAME  gb7pzt
             kdrbbs. IN CNAME  gb7pzt

        Thus if the user types "TEL pztbbs" or "TEL kdrbbs", the
        gb7pzt record is used.  This removes the need to keep
        repeating the IP address in multiple "A" records, and makes
        it easier if the IP address is changed.

        The MX or "Mail Exchange" records are usually used for
        defining alternate names for mail servers, but as XRouter is
        not concerned with mail you can use them in the same way as
        CNAME entries, although there would be no point in doing so.
        The format of the additional records would be:

             pztbbs.   IN   MX   gb7pzt
             kdrbbs.   IN   MX   gb7pzt

        The optional "preference" field of MX records is ignored.
        
        The optional [ttl] field in all types of entry is the
        "time to live" of the entry in seconds, used to expire
        records whose addresses are liable to change.  If omitted or
        set to zero, the record has an unlimited lifetime. 

        In order to simplify the file, the ".ampr.org" is usually
        omitted from the records, and appended automatically when
        the file is read.  However, hostnames which contain or end
        with a dot will not be extended in this manner.  Thus
        "gb7pzt" would be extended to "gb7pzt.ampr.org", whereas
        "lgs." and "ns.cyberphile.co.uk" would not be modified.

</code> **NOTES** <code>
        Although DOMAIN.SYS was originally designed to be simpler
        than the more standard DOMAIN.TXT format, Xrouter is capable
        of understanding both formats, so you may use an existing
        DOMAIN.TXT simply by renaming it to DOMAIN.SYS.

</code> **FILES** <code>
        DOMAIN.SYS is located in the same directory as XRouter.EXE.

</code> **LIMITATIONS** <code>
        XRouter's DNS server currently responds only to type A
        queries.

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

</code>
----
=====DYNDNS=====
<code>DYNDNS.CFG(8)           XROUTER REFERENCE MANUAL              6/9/2023
</code> **NAME** <code>
        DYNDNS.CFG -- Dynamic DNS Update Client Configuration File.

</code> **DESCRIPTION** <code>
        This optional file is used by the Dynamic DNS Update Client,
        and contains information about your account, the address(es)
        you wish to update, and the method of update.

        If you are not using the client, you do not need this file.

</code> **EXAMPLES** <code>
        The following is an example DYNDNS.CFG file:

        ; DYNDNS.CFG:
        ; Configuration file for XRouter Dynamic DNS update client
        ; Do not delete or change the order of entries.
        ;
        ; Update server name
        members.dyndns.org
        ;
        ; IP detection server
        checkip.dyndns.org
        ;
        ; Account Name (put your own account name here)
        test
        ;
        ; Account Password (Put your password here)
        test
        ;
        ; System (dyndns, statdns or custom)
        ; (The latter two are only available on subscription.)
        dyndns
        ;
        ; Use external IP detection? (yes / no)
        ; This should be set to NO if Xrouter is directly connected
        ; to the Internet or YES if the Internet connection is via
        ; another router.
        NO
        ;
        ; Wildcard (ON / OFF)
        ; If this is set to ON, *.host.domain will be aliased to
        ; host.domain
        ON
        ;
        ; Hostname(s) to be updated, separated by commas. No spaces.
        ; (put your own hostname(s) here)
        test.ath.cx,test.dyndns.org,test.dnsalias.net
        ;

</code> **SEE ALSO** <code>
        DYNDNS(9) -- Dynamic DNS Update Client

</code> **DYNDNS.CFG(8)                  END OF DOCUMENT** <code>
</code>
----
=====ENCAP=====
<code>ENCAP.TXT(8)            XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        ENCAP.TXT -- Amprnet Encapsulated Routing File (optional).

</code> **DESCRIPTION** <code>
        This is *not* an XRouter configuration file, but XRouter
        is capable of reading it.

        ENCAP.TXT is simply a text file which contains a huge list
        of amateur IP routes and the Internet addresses of IPEncap
        gateways which handle them.

        If this file is present when XRouter boots up, it will read
        the routes into its IP routing table.

        If you are not running an amprnet "gateway", or have set up
        your own encap routes in IPROUTE.SYS, you do not need this
        file.

</code> **FORMAT** <code>
        The format of routing entries in ENCAP.TXT is as follows:

           route addprivate 44.131.91.0/24 encap 62.31.206.176

        The "addprivate" stipulates that the route should be hidden
        from users, i.e. not displayed by the IPROUTES command.

        The "44.x.x.x/xx" part specifies which amprnet route(s)
        this entry applies to.

        The "encap" part tells XRouter to use IPEncap protocol,
        i.e. it is the same as using routing mode "e".

        The final field is the Internet IP address of the gateway
        which handles the specified amprnet route(s).

</code> **FILES** <code>
        If required. ENCAP.TXT should be located in same directory
        as the XRouter executable.

</code> **NOTES** <code>
        ENCAP.TXT is subject to frequent modification, so you will
        need to obtain updated copies from time to time, and use
        IP ROUTE LOAD (or restart XRouter) to load them. A batch
        file to obtain and edit the ENCAP.TXT can be run by the
        Windows / Linux task scheduler, and IP ROUTE LOAD can then
        be called afterwards by a suitable entry in CRONTAB.SYS.

</code> **CAVEATS** <code>
        On Windows, it is NOT possible to use "encap" protocol
        without using the NDISXPKT driver. Without the driver, XR32
        is forced to use the Windows IP stack, instead of its own,
        for accessing the Internet. The problem is, Windows no longer
        allow IPEncap to pass via it's IP stack. The protocol was
        blocked for "security reasons" when Microsoft issued XP
        service pack 2. It should work on Windows 2000 and early
        versions of XP however. There are no such restrictions on
        Linux.

        If you are a gateway, you must remove your own entry from
        ENCAP.TXT before loading it, otherwise catastrophic
        looping will occur (this may have been fixed in later
        versions).

        ENCAP.TXT contains over 500 entries, and may make your IP
        routing slower, because all those routes must be searched
        recursively for every single datagram routed by your
        system.  With a fast computer or low data rate you
        probably wouldn't notice the difference however.

</code> **BACKGROUND** <code>
        IPEncap (usually called "encap", but sometimes erroneously
        called IPIP) "encapsulates" amateur IP within the payload of
        public (Internet) IP datagrams. Thus it is sometimes called
        IP-over-IP or IP-within-IP, but should not be called "IPIP",
        because that is an older version of the protocol. Encap is
        assigned IP protocol number 4, and IPIP is protocol 94. 

        Encapsulation allows amateur IP (44.x.x.x addresses) to be
        "tunnelled" or "wormholed" across the internet, between
        amprnet gateways. In order to do this, each gateway needs to
        know the Internet addresses of the other gateways, and which
        amprnet datagrams shoule be sent to which gateway.  That
        information is located in ENCAP.TXT.

        In order to keep the amprnet secure, the gateway owners need
        to prevent their IP addresses from becoming public knowledge.
        Thus the contents of ENCAP.TXT are a closely guarded secret.
        The file is obtained from an FTP server whose address is
        known only to the gateway sysops.

</code> **SEE ALSO** <code>
        IPENCAP(9)     -- IP-within-IP Encapsulation.
        IPROUTE.SYS(8) -- IP Routing and Configuration File

</code>
----
=====ENGLISH=====
<code>ENGLISH.SYS(8)          XROUTER REFERENCE MANUAL            22/10/2023
</code> **NAME** <code>
        ENGLISH.SYS -- English Language Texts for XRouter.

</code> **DESCRIPTION** <code>
        ENGLISH.SYS is an optional file containing English Language
        Texts which are used within XRouter.

        If present, the contents of this file are read at bootup
        only, replacing XRouter's inbuilt prompts, headings and
        responses.

        XRouter's inbuilt language is ENGLISH. If you wish, you may
        change the layout and/or wording of most XRouter responses by
        installing ENGLISH.SYS in the same directory as XRouter.
        XRouter will then use the texts from that file, which you may
        modify, instead of the inbuilt ones.

        Be careful with modifications, because some of the texts are
        used in multiple places, and some of them are column headers
        which need to follow a strict format. Installing and
        modifying this file is NOT recommended, but it's up to you!

        Modifications to this file do not affect other languages.

</code> **FORMAT** <code>
        Each text is on a separate line, which begins with a number
        corresponding to that text. Following the number is some 
        whitespace, then the text itself is enclosed in quotes.  For
        example:

            12  "Syntax error\r"

        Most texts end with "\r" (carriage return, ASCII 13), but not
        all of them do. "Hanging" prompts and individual words don't.

        Blank lines, and lines which begin with '#' in the leftmost
        column are ignored. The latter can be used for comments.

        Some texts contain one or more placeholders such as "%s",
        "%d" etc. You may move their position within a text, but if
        you change them, you will cause XRouter to crash.

        For example, you could safely re-word the following:

            73  "Session %d not found\r"

        to the following:

            73  "I'm sorry, I can't find session %d\r"

        "%d" is a placeholder for an integer
        "%s" is a placehlder for a string of characters

        Changes don't take effect unless XRouter is restarted.

        Text numbers fall into the following ranges:

            1-999 General texts
            1000  PZTDOS texts
            2000  AX25/NetRom texts
            3000  Chat server texts
            4000  APRS Messaging System Texts
            5000  FTP Client texts
            6000  PMS Texts
            7000  IDS (Intrusion Detection System) texts

        If a required text is not found in the file (e.g. it has
        been deleted or commented out), the inbuilt text is used
        instead.

</code> **SEE ALSO** <code>
        CONSOLELANG(7)  -- Console language.
        DEFAULTLANG(7)  -- Specify default language.
        DEUTSCHE.SYS(8) -- German Language Texts.
        ESPANOL.SYS(8)  -- Spanish Language Texts.
        FRANCAIS.SYS(8) -- French Language Texts.
        LANGS.SYS(8)    -- Language selection file.

</code>
----
=====ESPANOL=====
<code>ESPANOL.SYS(8)          XROUTER REFERENCE MANUAL            22/10/2023
</code> **NAME** <code>
        ESPANOL.SYS -- Spanish Language Texts for XRouter.

</code> **DESCRIPTION** <code>
        ESPANOL.SYS is an optional file containing Spanish language
        texts for use within XRouter.

        If present in the same directory as the XRouter executable,
        the contents of this file are read at bootup only, adding
        Spanish prompts, headings and responses for those who select
        the Spanish language option.

        If this file is not present, XRouter defaults to ENGLISH.

        If you can improve on the translation, please do so, and
        please share your work.

        Be careful with modifications, because some of the texts are
        used in multiple places, and some of them are column headers
        which need to follow a strict format.

        Modifications to this file do not affect other languages.

</code> **FORMAT** <code>
        Each text is on a separate line, which begins with a number
        corresponding to that text. Following the number is some 
        whitespace, then the text itself is enclosed in quotes.  For
        example:

            12 "Erreur se synthèse\r"

        Most texts end with "\r" (carriage return, ASCII 13), but not
        all of them do. "Hanging" prompts and individual words don't.

        Blank lines, and lines which begin with '#' in the leftmost
        column are ignored. The latter can be used for comments.

        Some texts contain one or more placeholders such as "%s",
        "%d" etc. You may move their position within a text, but if
        you change them, you will cause XRouter to crash.

        For example, you could safely re-word the following:

            73   "Sesión %d No encontrado\r"

        to the following:

            73   "No puedo encontrar la sesión %d\r"

        "%d" is a placeholder for an integer
        "%s" is a placehlder for a string of characters

        Changes don't take effect unless XRouter is restarted.

        Text numbers fall into the following ranges:

            1-999 General texts
            1000  PZTDOS texts
            2000  AX25/NetRom texts
            3000  Chat server texts
            4000  APRS Messaging System Texts
            5000  FTP Client texts
            6000  PMS Texts
            7000  IDS (Intrusion Detection System) texts

        If a required text is not found in the file (e.g. it has
        been deleted or commented out), the inbuilt English text is
        used instead.

</code> **SEE ALSO** <code>
        CONSOLELANG(7)  -- Console language.
        DEFAULTLANG(7)  -- Specify default language.
        DEUTSCHE.SYS(8) -- German Language Texts.
        ENGLISH.SYS(8)  -- English Language Texts.
        FRANCAIS.SYS(8) -- French Language Texts.
        LANGS.SYS(8)    -- Language selection file.

</code>
----
=====EXEC=====
<code>EXEC.HTM(8)             XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        EXEC.HTM -- Command Template for HTTP Server.

</code> **DESCRIPTION** <code>
        This optional file is a "template" for use with the HTTP
        server.

        When the server receives a request whose URL begins with
        "/exec?cmd=", e.g. it passes the command to XRouter for
        execution, and serves a "template" page displaying the
        response to the command.  The template serves as a wrapper
        for the text.

        If you wish to override XRouter's inbuilt HTML template, edit
        the file EXEC.HTM, which was supplied with the installation
        package, and put it in the XRouter working directory. This
        file is not placed within the HTTP directory tree because it
        is not intended to be served in the normal way.

        If EXEC.HTM exists, the server will serve it in place of the
        inbuilt template, replacing the <TEXT> tag with the result of
        the executed command.  EXEC.HTM does not currently support
        Server Side Includes.

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

</code>
----
=====EXPORT=====
<code>EXPORT.SYS(8)           XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        EXPORT.SYS -- Mail Export Control File.

</code> **DESCRIPTION** <code>
        The optional file EXPORT.SYS, which resides in the PMS
        subdirectory, controls "exporting" of messages to files.

        It is read "live" upon receipt of each new mesaage, so it can
        be edited on the fly, and any edits take effect immediately.

        Exporting can be used to archive selected messages, or to
        create files that can be imported into other mail systems.

</code> **FORMAT** <code>
        Comment lines are allowed. These must begin with a semicolon
        or hash in the first column.

        Lines beginning with '@' specify the filename to which
        messages are to be exported, and the file opening mode to use. 

        The mode is specified by a single (optional) character, which
        follows the filename, after a gap of one or more spaces:

          O = overwrite    A = Append (default)

        Overwrite mode would typically be used when only the most
        recent copy of a regular message, e.g. a weather report, was
        required

        For all other lines, the fields are:

            <format>  <type>  <to>  <from>  <at>  <mid>  <subject>

        <format> can be one or two characters. The first character
                 specifies the format of the exported message:
                 (F = as a file, M = MBL).

                 The optional second character determines routing
                 header (R: line) stripping:

                 H    = Include all routing header lines.
                 R    = Include first (originating) R: line only.
                 None = Don't include any R: lines

        <type>   specifies the type of message to be exported:

           B = Bulletin, P = Private, A = Ack, 7 = 7plus, * = Any

        The remaining fields specify which messages are to be
        exported, depending on any combination of TO, FROM, AT, MID
        or subject.

        All fields are case-independent, and wildcards are allowed.
        However, the <subject> field behaves slightly differently to
        the others. The supplied <subject>, which may contain more
        than one word, is tested against all parts of the message
        subject, in a "sliding match". For example "news" will match
        both "RSGB Main News" and "DX News". The only wildcard allowed
        in the subject field is a single "*" (match any subject)

</code> **EXAMPLES** <code>
        The following example exports TECH bulletins sent by G8MNY,
        to the file PMS/TECH.SAV in "append" mode, using "MBL" format,
        and omitting all R: lines except the one generated by the
        original sender's mailbox:

        @PMS/TECH.SAV
        # <format>  <type>  <to>  <from>  <at>  <mid>  <subject>
        #-------------------------------------------------------
           MR         B     TECH   G8MNY    *     *       *


        The next example appends retro computing bulletins to the
        file "retro.txt" in "MBL" mode, omitting all routing headers:

        @/home/pi/retro/retro.txt
        # <format>  <type>  <to>  <from>  <at>  <mid>  <subject>
        #-------------------------------------------------------
           MR         B     CBM      *      *     *       *
           MR         B     ATARI    *      *     *       *
           MR         B       *      *      *     *       VIC20


        The final example shows the use of "overwrite" mode, to store
        a copy of the latest DX News in the BBS files area as a file
        without any MBL headers or R: lines:

        @FILES/DXNEWS.TXT O
        # <format>  <type>  <to>  <from>  <at>  <mid>  <subject>
        #-------------------------------------------------------
           F          B     DXNEWS   *      *     *     Latest

</code> **SEE ALSO** <code>
        EXPORT(4) -- Export Message to File.
        IMPORT(4) -- Import Message(s) From File.
        PMS(9)    -- About the Mailbox.
        
</code>
----
=====FILES=====
<code>FILES(8)             XROUTER REFERENCE MANUAL               30/10/2023
</code> **NAME** <code>
        FILES -- Files And Directories Used By XRouter.

</code> **DESCRIPTION** <code>
        All files and directories required by the system are located
        within a single directory which can be located anywhere and
        have any name.  For the purposes of this document it will be
        called the "root" or "working" directory.  All other
        directories used by XRouter are sub-directories of the
        working directory.

        The working directory should contain at least the XRouter
        program and XROUTER.CFG.  All other files are optional and
        the system will run without them.

        If you want to grant access to remote sysops you will need to
        add a suitably configured PASSWORD.SYS.  If you want to route
        IP, you will need IPROUTE.SYS.  If you want to control TCP/IP
        access, add ACCESS.SYS and USERPASS.SYS.  If you need to
        specify hostnames for fast domain lookup, add DOMAIN.SYS.

        If you add any of the above, you must edit them to suit your
        requirements.  They should be self-documenting, but there is
        also a MAN file for each one.

        If you want the full HELP system (recommended), create a
        sub-directory called HELP and place all the .HLP files into
        it.  Note that the help for the CHAT server goes in
        sub-directory HELP/CHAT, FTP server help goes in HELP/FTP and
        the APRS messaging help goes in HELP/AMSG.

        If you want an INFO system, create the INFO directory and
        populate it with .INF files.  There are some sample .INF
        files included in the distribution package to give you some
        ideas.

        If you want the online manual (recommended), create the MAN
        directory and put the *.MAN files into it.


        Directory Tree
        ~~~~~~~~~~~~~~

          /             - XRouter "root", e.g. C:\XRouter
          /FINGER/      - FINGER files
          /HELP         - English HELP files
          /HELP/AMSG/   - Help for APRS messaging
          /HELP/CHAT/   - Help for chat server
          /HELP/FTP/    - Help for FTP server
          /HELP/FR/     - French HELP files
          /HELP/NL/     - Dutch HELP files
          /HTTP/        - Root for HTTP server (see below)
          /INFO/        - INFO files
          /LOG/         - Activity log files
          /MAN/         - Sysop manual files

        The LOG directory is created automatically when XRouter runs.

        If logging is enabled, daily log files are created within the
        LOG directory.  If IDS logging is enabled, the IDS log files
        are also written to thr LOG directory.

        The HTTP root directory may be relocated (using the HTTPROOT
        directive in XROUTER.CFG).  This allows the HTML files to be
        located somewhere more convenient, even on another drive if
        required.


        Files in XRouter "root" Directory (* = mandatory)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          ACCESS.SYS    - TCP/IP access control.
          BOOTCMDS.SYS  - Boot up config commands.
          CRONTAB.SYS   - Event control.
          DEUTSCH.SYS   - German language file.
          DOMAIN.SYS    - TCP/IP hostname resolution.
          ENCAP.TXT     - IPENCAP routes.
          ESPANOL.SYS   - Spanish language file.
          FRANCAIS.SYS  - French language file
          HTTP.ACL      - HTTP Proxy Egress Control.
          HTTP.SYS      - HTTP Rewrite / Proxy Control.
          HTTPBAN.SYS   - HTTP URL block list.
          IGATE.CFG     - APRS IGATE configuration.
          IPROUTE.SYS   - IP routes / configuration.
          LANGS.SYS     - Languages control file.
          NEDERLANDS.SYS - Dutch language file.
          PASSWORD.SYS  - Sysop passwords.
          PPPHOST.n     - PPP configuration files.  
          PPPLOG.TXT    - PPP activity log.
          SOCKS.ACL     - SOCKS proxy egress control.
          TELGUEST.ACL  - Telnet "guest" mode egress control.
          TELPROXY.ACL  - Telnet proxy egress control.
          TELPROXY.MSG  - Telnet proxy welcome message.
          USERPASS.SYS  - User passwords.
        * (XRouter)     - Executable (xrouter / xr32 / xrpi /xrlin)
          XRNODES       - NetRom nodes / routes recovery file.
        * XROUTER.CFG   - XRouter Main Configuration File.

        There are detailed MAN pages for each of the above files in
        section 8 of the manual.

</code> **SEE ALSO** <code>
        XROUTER.CFG(8) -- Main Configuration File.
        IPROUTE.SYS(8) -- IP routes / configuration File.
        BOOTCMDS.SYS(8) -- Boot up configuraion Commands.

</code>
----
=====FRANCAIS=====
<code>FRANCAIS.SYS(8)         XROUTER REFERENCE MANUAL            22/10/2023
</code> **NAME** <code>
        FRANCAIS.SYS -- French Language Texts for XRouter.

</code> **DESCRIPTION** <code>
        FRANCAIS.SYS is an optional file containing French language
        texts for use within XRouter.

        If present in the same directory as the XRouter executable,
        the contents of this file are read at bootup only, adding
        French prompts, headings and responses for those who select
        the French language option.

        If this file is not present, XRouter defaults to ENGLISH.

        If you can improve on the translation, please do so, and
        please share your work.

        Be careful with modifications, because some of the texts are
        used in multiple places, and some of them are column headers
        which need to follow a strict format.

        Modifications to this file do not affect other languages.

</code> **FORMAT** <code>
        Each text is on a separate line, which begins with a number
        corresponding to that text. Following the number is some 
        whitespace, then the text itself is enclosed in quotes.  For
        example:

            12 "Erreur se synthèse\r"

        Most texts end with "\r" (carriage return, ASCII 13), but not
        all of them do. "Hanging" prompts and individual words don't.

        Blank lines, and lines which begin with '#' in the leftmost
        column are ignored. The latter can be used for comments.

        Some texts contain one or more placeholders such as "%s",
        "%d" etc. You may move their position within a text, but if
        you change them, you will cause XRouter to crash.

        For example, you could safely re-word the following:

            73  "Session %d pas trouvé\r"

        to the following:

            73  "Je ne trouve pas la session %d\r"

        "%d" is a placeholder for an integer
        "%s" is a placehlder for a string of characters

        Changes don't take effect unless XRouter is restarted.

        Text numbers fall into the following ranges:

            1-999 General texts
            1000  PZTDOS texts
            2000  AX25/NetRom texts
            3000  Chat server texts
            4000  APRS Messaging System Texts
            5000  FTP Client texts
            6000  PMS Texts
            7000  IDS (Intrusion Detection System) texts

        If a required text is not found in the file (e.g. it has
        been deleted or commented out), the inbuilt English text is
        used instead.

</code> **SEE ALSO** <code>
        CONSOLELANG(7)  -- Console language.
        DEFAULTLANG(7)  -- Specify default language.
        DEUTSCHE.SYS(8) -- German Language Texts.
        ENGLISH.SYS(8)  -- English Language Texts.
        ESPANOL.SYS(8)  -- Spanish Language Texts.
        LANGS.SYS(8)    -- Language selection file.

</code>
----
=====FTPCLI=====
<code>FTPCLI.SYS(8)           XROUTER REFERENCE MANUAL              8/9/2023
</code> **NAME** <code>
        FTPCLI.SYS -- FTP Client Account File.

</code> **DESCRIPTION** <code>
        The FTPCLI.SYS file contains account and connection info
        used for automating logins to FTP servers.

</code> **FORMAT** <code>
        The entries in ACCESS.SYS are of the form:

        <name> <host>[:port] [username [passwd [account [timeout]]]]

            <name> is a short "handle" for the connection.

            <host> is the hostname or IP address of the server.

            [port] is the TCP port number of the server. Default 21.

            [username] is the the one required by the server. If not
                       specified here, the server will ask for it.

            [passwd] is the password associated with [username]. If
                     not specified, the server will ask for it.

            [account] may be required by some servers.

            [timeout] is the maximum number of seconds to wait for a
                      response to a command. Default is 20.

        Use asterisk (*) as a placeholder for empty fields

</code> **EXAMPLES** <code>
        stest  speedtest.tele2.net anonymous anon
        gb3kc  gb3kc.dyndns.org  g8pzt  password  * 10
        xrpi   192.168.1.221:31   g8pzt  myverylongpassword

</code> **SEE ALSO** <code>
        FTP(1) -- Invoke Fie Transfer Protocol Client.

</code>
----
=====FWD=====
<code>FWD.SYS(8)              XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        FWD.SYS -- Mailbox Forwarding Control File.

</code> **DESCRIPTION** <code>
        The optional file FWD.SYS, which resides in the PMS folder,
        controls when & how queued mail is delivered to neighbours.

        It is read "live" during each forwarding run, so it can be
        edited on the fly, and any edits take effect immediately.

</code> **FORMAT** <code>
        Comment lines are allowed. They must begin with hash (#) or
        semicolon (;) in the leftmost column.

        There is one "block" of lines controlling the forwarding for
        each neighbour BBS.

        Each block starts with: "@<bbs> <options>"

            <bbs>      is the callsign (without SSID) of the target
                       mailbox. This must exactly match a <send_via>
                       in DISTRIB.SYS.

            <options>  are as follows:

                       F = Forward mail, if we have any to send
                       P = Poll for mail even if we have none to send

        The second line of each block specifies the days of the week
        (0=Sunday) on which forwarding to this neighbour is allowed.

            For example: "0,3-4,6" (no whitespace)

        The third line of each block specifies the hours of the day
        during which forwarding to this neighbour is allowed

            For example: "4-12,14,17-21" (no whitespace)

        Subsequent lines in the block are the "connection script" as
        follows:

            T <secs>   specifies a timeout for the connection
            C <call>   initiates connection (waits for "Connected to")
            S <text>   sends <text>
            W <text>   waits for <text> in the received data

        Each "block" must end with a short line of dashes: "-------"

</code> **EXAMPLES** <code>
        # Forward and poll VE2PKT midnight to 8am, weekends only:
        #
        @VE2PKT FP
        0,6
        0-8
        C KIDDER
        C PKTXRP
        C VE2PKT
        ----------

        # Forward to GB7NXT any day, any time, but don't poll

        @GB7NXT F
        0-6
        0-23
        C KIDDER
        C GB7NXT
        W NXTNOD:GB7NXT}
        S BBS
        ------
        ; Forward and poll VA2OM any day, mornings & evenings only:
        ;
        @VA2OM FP
        0-6
        8-11,17-20
        C KIDDER
        C VA2OM-14
        S PMS
        ----------

</code> **SEE ALSO** <code>
         FF(4)          -- Force Forwarding.
         FP(4)          -- Force Polling.
         SF(4)          -- Stop Forwarding.
         VF(4)          -- View Forwarding.
         DISTRIB.SYS(8) -- Mail Distribution Control File.
         PMS(9)         -- About the Mailbox.

</code>
----
=====HOLD=====
<code>HOLD.SYS(8)             XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        HOLD.SYS -- Control File for Mail Holding.

</code> **DESCRIPTION** <code>
        The optional file HOLD.SYS, which resides in the PMS
        subdirectory, controls the "holding" of messages.

        It is read "live" upon receipt of each new mesaage, so it can
        be edited on the fly, and any edits take effect immediately.

        Entries in this file allow messages to be automatically held
        for review depending on the contents of its TO, FROM, or AT
        fields, and whether or not it was entered locally.

        Held messages are not forwarded, and are only visible to
        sysops.

</code> **FORMAT** <code>
        Comment lines are allowed. They must begin with a hash (#) or
        a semicolon (;) in the leftmost column.

        Each "active" line must have exactly 5 fields as follows:

            <source> <type> <to>  <from>  <at>

        <source> can be 'L' for "locally entered", or '*'.

        <type>   is the message type, e.g. 'P'", 'B', 'A', 'T' etc.

        <to>     is the addressee of a private message or the
                 "category" of a bulletin.

        <from>   is the callsign of the message creator.
 
        <at>     is the callsign of the destination mailbox (personal
                 mail and "targeted" bulletins), or the "distribution
                 area for a bulletin, e.g. "GBR".

</code> **OPERATION** <code>
        Rules are processed in the sequence in which they are
        declared in the file.

        If all 5 fields of any rule match characteristics of a
        message, that message is held.

</code> **EXAMPLES** <code>
        The first example holds all bulletins addressed to PORN, and
        all locally-entered mail of any type:

            # Source Type To    From  At
            # ==========================
                *    B    PORN  *     *
                L    *    *     *     *

        The next example holds locally entered bulletins, except those
        with a blank AT field. This allows users to post bulletins
        which stay on this bbs with no interference:

            # Source Type To    From  At
            # ==========================
               L      B    *    *     ?*

        The next example holds all bulls from LU9DCE, and demomstrates
        the use of semicolons instead of hashes for comment lines:

            ; Source   Type  To      From     At
            ; ==================================
                 *       B    *      LU9DCE   *

        Finally, hold all private mail addresed to "g9pzt":

            ; Source   Type  To      From     At
            ; ==================================
                 *       P    G9PZT  *        *

</code> **SEE ALSO** <code>
        HOLD(4) -- Hold a Message.
        KH(4)   -- Kill Held Mail.
        LH(4)   -- List Held Mail.
        UH(4)   -- Un-hold Messages.
        PMS(9)  -- Avout the Mailbox.

</code>
----
=====HTTP=====
<code>HTTP.ACL(8)             XROUTER REFERENCE MANUAL            16/10/2023
</code> **NAME** <code>
        HTTP.ACL -- HTTP Proxy Egress Control File (Optional).

</code> **DESCRIPTION** <code>
        The HTTP.ACL file contains "rules" to control which
        destinations are allowed to be accessed via the HTTP
        proxy/tunnel.

        The rules allow you to specify which destination IP
        addresses and TCP ports may be accessed by specified
        source IP ranges.

        If the file is not present, or contains no valid rules,
        all destinations are blocked, and the "403 Forbidden"
        error page is returned to anyone who tries to use the
        proxy or tunnel.

        Egress control is vital to prevent miscreants using your
        HTTP server as a proxy to hide their IP address.

</code> **FORMAT** <code>
        The format of the entries in HTTP.ACL is the same as
        other .ACL (Access Control List) files.

        Each "rule" is specified on a separate line. Blank lines,
        or lines beginning with ';' or '#' are ignored. The
        maximum line length is 255 characters.

        Within each rule, fields must be separated by one or
        more spaces or tabs. The fields are as follows:

        <action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>

        The fields have the following meaning:

        <action>   PERMIT  Allow egress
                   DENY    Prevent egress

        <src_ip>   Source IP address (uplinked user).

        <dst_ip>   Destination IP address (target system).

        [mask]     Optional field.
                   Either: No. of bits (0-32) of address to
                           match from left to right,
                   Or:     Subnet mask in form n.n.n.n

        <port(s)>  One or more TCP service numbers (0-65535) on
                   the target system.  Allowed formats are "n",
                   "n,n,n", "n-n" or combination thereof.


        In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
        "all addresses".

</code> **NOTE** <code>
        Rule testing stops at the *first* matching "permit" or
        "deny" statement, so it is vital that the list is ordered
        correctly.  For instance, to allow Internet users to
        access all LAN ports except 513 it would be ok to use:

            deny     0.0.0.0/0  192.168.0.0/24  513
            permit   0.0.0.0/0  192.168.0.0/24  1-65535

        but if the entries were reversed, the "permit" rule would
        match every case and the "deny" rule wouldn't be actioned.

</code> **EXAMPLES** <code>
        ; Allow LAN users to tunnel to anyone:
        PERMIT 192.168.0.0/24  0.0.0.0/0  0-65535
        ;
        ; Allow Internet users to tunnel only to certain
        ; ports on the node machine:
        PERMIT 0.0.0.0/0  192.168.0.245  23,87,1448,3600
        ;
        ; Allow Internet users to tunnel only to ports 23
        ; and 80 on the BBS machine:
        PERMIT 0.0.0.0/0  192.168.0.4  80,23
        ;
        ; Allow Amprnet users to access any Amprnet destination
        PERMIT 44.0.0.0/8  44.0.0.0/8  0-65535

</code> **FILES** <code>
       If required, HTTP.ACL must be located in the same
       directory as the XRouter executable.

</code> **SEE ALSO** <code>
       HTTP.SYS(8)     -- HTTP Rewrite / Proxy Control File
       SOCKS.ACL(8)    -- SOCKS Proxy Egress Control File
       TELPROXY.ACL(8) -- Telnet Proxy Egress Control File

</code>
----
=====HTTPBAN=====
<code>HTTPBAN.SYS(8)          XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        HTTPBAN.SYS -- Blocks Malicious HTTP Requests (Optional).

</code> **DESCRIPTION** <code>
        XRouter's HTTP server doesn't suffer from the usual Windows
        vulnerabilites, so malicious HTTP requests designed to
        exploit them are simply a bandwidth-wasting nuisance
        rather than a real threat. You can frustrate the hackers
        by deploying this optional file.

        The HTTPBAN.SYS file contains "signatures" or "templates"
        of typical malicious request URL's. For example a request
        for "default.ida" is part of a Code Red Worm attack, whilst
        requests for "cmd.exe" are an attempt to locate vulnerable
        Windows servers.

        Each template is specified on a seperate line, can be up
        to 127 characters long, and must start in the leftmost
        column. The templates are compared in a sliding match with
        each requested URL.  

        If any part of the first 256 bytes of the URL matches a
        template, the sender's IP address is entered into a ban
        list and all further IP datagrams from that host are
        ignored until XRouter is restarted.
	
        Up to 20 hosts can be banned simultaneously.
        
</code> **OPTIONS** <code>
        The file may contain comments, which must begin with
        '#' or ';' in the left-most column.

        If a template is preceded by the word ANYCASE, a case
        independent match is performed, otherwise the match is
        case-sensitive. There must be one or more spaces between
        the word ANYCASE and the template.

</code> **EXAMPLES** <code>
        default.ida
        ANYCASE cmd.exe
        /contac.php

</code> **FILES** <code>
       If required, HTTPBAN.SYS must be located in the same
       directory as the XRouter executable.

</code> **SEE ALSO** <code>
        HTTP.ACL(8) -- Egress Control for HTTP Proxy / Tunnel
        HTTP.SYS(8) -- HTTP Rewrite / Proxy rules

</code>
----
=====HTTP=====
<code>HTTP.SYS(8)             XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        HTTP.SYS -- HTTP Rewrite / Proxy Control File (Optional).

</code> **DESCRIPTION** <code>
        HTTP.SYS is an optional file. If present, it contains
        REWRITE rules for the HTTP server, and settings for the
        HTTP proxy server.

        URL rewriting modifies the URL's of incoming requests,
        according to a set of REWRITE rules. This can be used to
        organise widely-dispersed resources into a logical
        directory tree.

        The resources may be located on the same PC or even on
        different servers, but can be made to look as if they are
        all in the same tree on your server.  This is done by
        replacing parts of the requested URL with alternative
        strings of characters. 

        The PROXY commands configure XRouter's HTTP proxy to use a
        "downstream" proxy to reach certain IP address ranges.

</code> **FORMAT** <code>
        Each command or rule must be on a separate line, and may be
        up to 255 characters long. Lines beginning with ';' or '#'
        are ignored, and may be used for comments. Commands and
        rules are not case sensitive, and their fields must be
        separated by one or more spaces or tabs. Blank lines are
        ignored.

        The commands and rules are as follows:

            REWRITE <old_string> <new_string>
            PROXY <ipaddr> <port> <subnet_mask>
            PROXYTIMEOUT <secs>
 
        These are discussed in more detail below...

</code> **REWRITE** <code>
        The REWRITE rules have the following syntax:

            REWRITE <old_string> <new_string>

        <old_string> is a template which is compared with an equal
                     number of characters from the start of the
                     requested URL when an HTTP request is received.
                     The comparison is case-insensitive.

        <new string> is the character sequence which replaces
                     <old_string> if there is a match.  

        Example: REWRITE /bbs /systems/gb7pzt

        This would replace "/bbs" at the start of the URL with
        "/systems/gb7pzt". Thus a request for "/bbs/msgs.htm" would
        be rewritten to "/systems/gb7pzt/msgs.htm".

        There are no validity checks, so you must be careful not to
        inadvertently remove / characters from the rewritten string.
        e.g. the entry "rewrite /bbs/ http://192.168.0.4" would cause
        "/bbs/index.htm" to rewrite as "http://192.168.0.4index.htm",
        which will clearly fail.

        You can use rewriting to organise your resources into a neat,
        logical and compact directory tree, regardless of where they
        are actually located.

        <new_string> may also contain a URL, which invisibly invokes
        the HTTP proxy. For example:

            REWRITE  /bbs  http://192.168.0.4:85 

        This would replace "/bbs" at the start of the URL with
        "http://192.168.0.4:85", so that a URL like:
        /bbs/cgi-bin/menu.pz becomes:
        http://192.168.0.4:85/cgi-bin/menu.pz

        The resulting URL then treated as if it was a proxy request.

        When rewriting to proxy another system, the new URL must
        begin with "http://<address>[:port]" where <address> can be
        either a hostname or IP address.

        rewrite http://g8pzt.ath.cx/bbs   http://192.168.0.4 

</code> **PROXY** <code>
        The PROXY command allows XRouter's HTTP proxy to pass certain
        traffic to a downstream proxy. The format of the command is:

            PROXY <ipaddr> <port> <subnet_mask>

            e.g. "proxy 44.131.91.245  80  255.0.0.0"

        <ipaddr> is the IP address of the downstream proxy.

        <port> is the TCP port number of the downstream proxy.

        <subnet_mask> when combined with the proxy address specifies
                      the range of addresses which are on the same
                      subnet as the proxy.  These addressess will
                      bypass the proxy, i.e. XRouter's proxy will
                      connect directly to them instead of via the
                      next proxy.

        This kludge allows 44-net systems to use a further proxy to
        gain a public (Internet) IP address when connecting non-44
        websites. This is necessary because 44-net routing is
        unreliable at best, i.e. if a 44-net browser tries to
        connect directly to Google, the reply probably won't get
        routed back.

        For example, imagine a mobile station, consisting of a web
        browser and XRouter, with an IP/AX25 link to a nearby gateway,
        but no Internet connection. The IP address used over the
        radio link is 44.131.91.3.  The browser has been configured
        to use XRouter's HTTP proxy, which means the IP source address
        for all HTTP traffic from this station is 44.131.91.3.

        Via the nearby gateway, whose IP address is 44.131.91.245,
        the mobile station can happily browse 44-net (amprnet)
        websites. But when it tries to use Google, the replies
        aren't routed back.

        However, if the local gateway has been set up with the
        above PROXY command, the 44.x.x.x sites will be connected
        directly by the mobile XRouter's proxy, whilst the non-44
        sites will be passed to the gateway's HTTP proxy, where they
        will gain a 62.31.206.176 source address, which is reliably
        routable and doesn't rely on the co-operation of others in
        the amprnet.

        The PROXYTIMEOUT command specifies the maximum time in
        seconds to wait for a proxied connection.  If a connection
        takes longer than this to establish, an error is returned.

        The default is 30 secs, but may need to be longer on a
        slow radio channel.

</code> **FILES** <code>
       If required, HTTP.SYS must be located in the same
       directory as XRouter.EXE.

</code> **SEE ALSO** <code>
        HTTP.ACL(8) -- HTTP Proxy Egress Control File
        HTTPBAN.SYS(8) -- Blocks Malicious HTTP Requests

</code>
----
=====IGATE=====
<code>IGATE.CFG(8)            XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        IGATE.CFG -- IGATE Configuration File.

</code> **DESCRIPTION** <code>
        IGATE.CFG is the configuration file for the APRS IGATE daemon,
        therefore you do not need it if you are not using IGATE.  It
        is a plain text file read each time the daemon is started. 

</code> **FORMAT** <code>
        IGATE.CFG is a plain text file.  Each configuration keyword
        is specified on a separate line. Blank lines, or lines
        beginning with ';' or '#' are ignored. The maximum line
        length is 80 characters.

        Within each directive, fields must be separated by one or
        more spaces or tabs. The fields are as follows:

        The following keywords are accepted:

           IFILTER  <from> <to> <text>  Internet->Packet filter rules 
           LOG      <0-255>             Activity logging level
           MAXTRIES <n>                 Max. server connect attempts.
           PAUSE    <seconds>           Interval between retries.
           PFILTER  <from> <to> <text>  Packet->Internet filter rules
           SERVER   <ipaddr:port>       Internet server to use
           SKIP     <seconds>           Blacklist time after failure
           WAIT     <seconds>           Time to wait for connection

      These are fully documented in the section relating to IGATE.

</code> **EXAMPLE** <code>
      Abbreviated example file:

      ; APRS IGATE Configuration file for XRPi
      ;
      ; You can list as many servers as you like.
      ; They are tried in rotation.
      SERVER 213.180.75.122:2023
      ;
      ; Wait up to 60 secs for connection before trying next server
      WAIT 60
      ;
      ; Wait 60 secs between successive attempts to same server
      PAUSE 60
      ;
      ; Max connect attempts before blacklisting the server
      MAXTRIES 10
      ;
      ; If blacklisted, don't try the server for 1 hour
      SKIP 3600
      ;
      ; IFILTER controls gating from internet to packet:
      ;
      ; IFILTER       From    To      Text
      ; -------------------------------------
        IFILTER       G#*     *       *
      ;
      ; PFILTER statements control gating from packet to internet:
      ;
      ; PFILTER       From    To      Text
      ; ------------------------------------
        PFILTER       G*      AP*     *
        PFILTER       MB7*    AP*     *
      ;
      ; Radius of Interest
      ;
      RADIUS 150
      ;
      ; Activity logging
      ;
      LOG     255


</code> **FILES** <code>
        If required, IGATE.CFG should be located in the same
        directory as the XRouter executable.

</code> **SEE ALSO** <code>
        IGATE(9)  -- APRS Internet Gateway.

</code>
----
=====IPBAN=====
<code>IPBAN.SYS(8)           XROUTER REFERENCE MANUAL              13/6/2019
</code> **NAME** <code>
        IPBAN.SYS -- Banned IP addresses file.

</code> **DESCRIPTION** <code>
        This optional file is read at bootup. It stores the list of
        "banned" IP addresses, plus "honeypot" ports.

        If the file doesn't exist, it is created at closedown or by
        the "IP BAN SAVE" command, if there are any entries to save.
        That comand may also be used in CRONTAB.SYS to save the list
        ar regular intervals.

        The ban and honeypot lists can be viewed and edited during
        run-time using the "IP BAN" command and its sub-commands.

        IP Banning
        ~~~~~~~~~~
        If XRouter's IDS (Intrusion Detection System) detects
        malicious activity on its own TCP/IP stack, it will "ban" the
        originator's IP address. Any further packets from that IP
        address are be ignored, as long as the ban lasts.

        If malicious activity is detected on any Linux TCP or UDP
        port that is currently "owned" by XRouter, that also causes
        a ban. In this case, TCP connections are terminated, and any
        further connections of UDP frames are ignored.

        There is no time limit on IP bans. Up to 200 IP addresses can
        be banned at once. A larger table would become unwieldy. When
        a new address is added, the oldest one is dropped. In
        practice this isn't usually a problem because the oldest
        aggressor has usually given up long ago, and is unlikely to
        come back.

        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> **FORMAT** <code>
        IPBAN.SYS is a text file, so it can be viewed and edited with
        any text editor, although there should be no need to do so.

        Each "entry" in the file is on a separate line.

        There are TWO types of entry in IPBAN.SYS, one for banned IP
        addresses, and the other for honeypot definitions. The
        banned IP entries are of the form:

            <ipaddr> <netmask> <type> <hits> <last-hit>

        Where:

            <ipaddr>   is the IP address being banned.
            <netmask>  specifies how much of the IP address to match
            <type>     is the type of ban: A=automatic, M=manual
            <hits>     is the number of times the IP has been seen
            <last-hit> is the date/time of the last "hit".

        "Automatic" bans are the ones added automatically by XRouter
        when it detects malicious activity. "Manual" bans are those
        added by the sysop using the "IP BAN" command.

        Honeypot entries have the form:

            <start> <end> <protocols> <hits> <last-hit>

        Where:

            <start>     is the first TCP/UDP port in the trap range
            <end>       is the last TCP/UDP port in the trap range
            <protocols> are the protocols to trap:
                        (1=TCP, 2=UDP, 3=both)
            <hits>      is the number of times the trap was sprung
            <last-hit>  is the date/time iof the last activation

        Date/time is a decimal number representing the number of
        seconds since 1/1/1970.

</code> **EXAMPLES** <code>
        ; Manual ban for 22.33.44.55 with 123 hits
        22.33.44.55  255.255.255.255  M  123  456789012

        ; Manual ban for 33.22.0.0/16 with no hits yet
        33.22.33.11  255.255.0.0      M  0    0

        ; Automatic ban for 80.193.161.2, seen 789 times
        80.193.161.2 255.255.255.255  A  789  324565789

        ; Honeypot on UDP port 211, no hits yet
        211  211   2  0  0

        ; Honeypot on VNC ports 5900-5999, both TCP and UDP
        5900 5999  3  0  0

</code> **SEE ALSO** <code>
        IP(1)          -- IP related commands
        CRONTAB.SYS(8) -- Time dependent comands

</code>
----
=====IPROUTE=====
<code>IPROUTE.SYS(8)          XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        IPROUTE.SYS -- IP Router Configuration File (optional).

</code> **DESCRIPTION** <code>
        This optional file is only required if you wish to route IP
        traffic, or use any of XRouter's IP facilities such as Telnet,
        Ping, Traceroute, HTTP server etc. I.e. it is not required
        if you are operating a pure AX25 / Netrom system, although
        you are urged to route amateur IP if possible.

        The file is read only at boot-up, or by an "IP ROUTE LOAD"
        command so if you make changes to it, they won't take
        effect until you reboot or use that command.  XRouter does
        not write to this file.

        If IPROUTE.SYS is present, it saves you having to enter
        the IP routing manually.  To reduce the number of
        configuration files, this file also contains the permanent
        ARP (Address Resolution Protocol), NAT (Network Address
        Translation), RIP (Routing Information Protocol) entries,
        and IP filtering rules.

</code> **FILE FORMAT** <code>
        IPROUTE.SYS is a text file. Within the file, each entry
        must be on a separate line, and there must be one or more
        spaces or tabs between each field.  Entries are not case
        sensitive.  Comments are allowed, providing they are on a
        line beginning with a semicolon ';' or hash '#'. Blank
        lines are ignored and lines may be up to 255 characters
        long.

        Commands accepted in this file are as follows:
       
            ACL <PERMIT | DENY>
            ARP <ADD | PUBLISH>
            DUN <ADD | LOG>
            IP <CMD | ROUTE ADD | ROUTE DEFAULT | QUIET | TTL>
            NAT <ADD>
            RIP <ADD | LEARN | REFUSE | TIMEOUT>

        ACL commands control the Access Control List, which
            specifies the IP addresses which are allowed to access
            and be accessed by XRouter.

        ARP commands are used to add "static" entries to the ARP
            table. These are mainly used for slow RF links.

        DUN commands are used to configure "dial-up" routing.

        IP  commands are used to add routes to the IP routing table
            and to configure the TTL, stealth level, and
            availability of the IPROUTE command.

        NAT commands add Network Address Translation entries to the
            NAT table.

        RIP commands control the RIP98 and RIP2 automatic route
            learning system.

        All of these commands are described in more detail in their
        own section 1 MAN pages (see below).

</code> **FILES** <code>
        If present, IPROUTE.SYS must be located in the same
        directory as the XRouter executable.

</code> **SEE ALSO** <code>
        ACL(1)       -- IP Access Control List Commands.
        ARP(1)       -- Address Resolution Protocol Commands.
        DUN(1)       -- Dial-up Networking Commands.
        IP(1)        -- IP Routing / Configuration Commands.
        IP-PRIMER(9) -- IP Addressing / Routing Primer.
        IPROUTE(1)   -- Display IP Routes
        NAT(1)       -- Network Address Translation Commands.
        RIP(1)       -- Routing Interface Protocol Commands.

</code>
----
=====LANGS=====
<code>LANGS.SYS(8)           XROUTER REFERENCE MANUAL               10/9/2023
</code> **NAME** <code>
        LANGS.SYS -- Language Control File.

</code> **DESCRIPTION** <code>
        This optional file is read only at bootup. It controls which
        language is used for a caller's session, based on their
        callsign.

        By default, XRouter uses ENGLISH. If you want to support
        additional languages, install the relevant language file(s)
        as follows:

            French   - FRANCAIS.SYS
            Spanish  - ESPANOL.SYS
            German   - DEUTSCH.SYS
            Dutch    - NEDERLANDS.SYS

        Language files are read only at bootup.

        All sessions use ENGLISH by default, UNLESS you install
        LANGS.SYS, which tells XRouter which language to use for a
        given callsign.

</code> **FORMAT** <code>
        The entries in LANGS.SYS are of the form:

            <callsign_mask> <language_number>

        The <callsign_mask> field specifies which callsign(s) will
        use the <language_number>. It can be a single callsign e.g.
        "F1OTJ" or a wildcard match, e.g. "F*".

        <language_number> is a pre-defined index number for the
        language to be used. These numbers are fixed, no matter how
        many language files are installed: English is always number
        0, French is always number 1 and so on.

        Comment lines beginning with "#" or ";" in the leftmost
        column are allowed.

        If you refer to a language nuber, you MUST install that
        language file.

</code> **EXAMPLE** <code>
        # LANGS.SYS
        #
        # Language selection file for XRouter v502
        #
        # Line format: <callsign_mask> <language_number>
        #
        # Language numbers:
        #
        # 0     English
        # 1     Francais
        # 2     Espanol
        # 3     Deutsche
        # 4     Nederlandse
        #
        # The default language for any callsign prefix not in the
        # list below is set by DEFAULTLANG in XROUTER.CFG.
        #
        2*      0
        3A*     1
        EA*     2
        F*      1
        G*      0
        H*      1
        M*      0
        ON1K*   1
        ON4*    1
        ON5*    1
        ON6*    1
        ON7*    1
        ON8*    1
        ON9*    1
        PA*     4
        PB*     4
        PC*     4
        PD*     4
        PE*     4
        PF*     4
        PH*     4
        PH*     4
        PI*     4
        TK*     1
        TU*     1
        VA2*    1
        VE2*    1

</code> **CAVEAT** <code>
        When BBS software is making connections for forwarding, it
        expects to see the English  words "CONNECTED TO". If this is a
        problem, e.g. the BBS is French you have two options. The first
        option is to "comment out" text no. 94 in FRANCAIS.SYS,
        allowing it to revert to English for that text only. The second
        option is to add an exception for that BBS into this file,
        assigning its language to English, e.g. "F1BBS 0". The
        exception should be added BEFORE any wildcard entries for that
        group pf caallgigns.

</code> **NOTES** <code>
        XRouter's inbuilt language is ENGLISH. If you wish, you may
        change the layout and/or wording of most XRouter responses by
        installing ENGLISH.SYS in the same directory as XRouter.
        XRouter will then use the texts from that file, which you may
        modify, instead of the inbuilt ones.

        Be careful with modifications, because some of the texts are
        used in multiple places, and some of them are column headers
        which need to follow a strict format. Installing and modifying
        this file is NOT recommended, but it's up to you!

        Similar comments apply to the other language files. If you can
        improve on them, please do so, and share the results.

        If your language is not (yet) one of the supported ones, and
        you don't need English, translate ENGLISH.SYS into your own
        language. That will become the default language.

</code> **SEE ALSO** <code>
        LANG(1)        -- Display / Set Session Language
        CONSOLELANG(7) -- Console language
        DEFAULTLANG(7) -- Specify default language
        XROUTER.CFG(8) -- Main configuration file

</code>
----
=====PASSWORD=====
<code>PASSWORD.SYS(8)         XROUTER REFERENCE MANUAL            18/10/2023
</code> **NAME** <code>
        PASSWORD.SYS -- Sysop Password File (Optional).

</code> **DESCRIPTION** <code>
        This optional file contains the sysop passwords for AX25
        remote access, RLOGIN and FTP.  If the file is not present,
        these forms of access will not be possible.

        These passwords are for SYSOPS only (passwords for users
        are stored in USERPASS.SYS).

</code> **FORMAT** <code>
        There should be one entry for each sysop, and each entry
        must be on a separate line, Blank lines, or lines beginning
        with ';' or '#' are ignored. The maximum line length is 80
        characters.

        Entries must consist of two fields separated by one or more
        spaces or tabs as follows:

                <callsign> <password>  

       <callsign> is the remote sysop's callsign without SSID.

       <password> is the password string. Must not contain spaces.

       For example: G8PZT   thisispaulaspassword
                    G1LOA   thisisrobertspassword

       Fields are not case sensitive.

</code> **NOTE** <code>
       You should try to choose a password that you can easily 
       remember, but others would find hard to guess.  It should 
       preferably be longer than 5 characters, to reduce the
       chances of someone guessing it by observing the password
       grid and your responses.

       The longer you make the password, the more secure it will
       be.  Try to avoid using well known words or names, because
       these are the favourite weapons of attack-bots. If you
       can't resist the urge to use the names of your family or
       pets, string them together to make a composite word.

       A random string is the most secure, because even if
       someone works out part of it, they won't be able to guess
       the remainder. However you must strike a balance between
       security and convenience, because while the password itself
       is never sent over the air for AX25 logins, it must be
       entered in full for an RLOGIN session.

       You may have a different password for each sysop, or you
       might choose to give all sysops the same password.
       Obviously the former is the most secure, but it's
       completely up to you.

</code> **FILES** <code>
        If present, PASSWORD.SYS must be located in the same
        directory as the XRouter executable.

</code> **SEE ALSO** <code>
        AXSCTRL(9)      -- TCP/IP Access Control.
        USERPASS.SYS(8) -- User Passwords File.

</code>
----
=====PMS=====
<code>PMS.CFG(8)              XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        PMS.CFG -- PMS / BBS Configuration File.

</code> **DESCRIPTION** <code>
        PMS.CFG is an optional configuration file for the inbuilt
        mailbox. If present, it is located in the PMS folder. It is
        read only when the program starts.

        It is a text file containing directives of the general form
        <keyword>=<value>, each on a separate line.  Keywords are
        not case sensitive, and they may be specified in any order. 

        Blank lines and comment lines are allowed. The latter must
        begin with a semicolon (;) or hash (#) in the leftmost
        column.  Lines must not exceed 255 characters.

        If PMS.CFG is not present, the mailbox uses default values.

</code> **OPTIONS** <code>
        The options currently recognised are as follows:

        SysopCallsign
            Sysop's callsign (defaults to PMSCALL without SSID)
  
        HousekeepInterval
            Hours between "housekeeping" sessions (default 24).
            Housekeeping removes old messages, optionally re-numbers
            the messages to remove gaps, and generates WP updates.

        ForwardInterval
            Seconds between Forwarding "runs" (default 900)
            If set to 0, forwarding is triggered only upon receipt of
            mail

        FwdKickOnRcv
            If set to 1 (default) a forwarding "run" is triggered
            immediately upon receipt of new mail. If set to 0,
            forwarding is deferred until next "run" is due

        AutoRenumber
            Controls re-numbering of messages at housekeep time.
            If it is non-zero, messages are renumbered if the highest
            message number exceeds the specified value. e.g. a value
            of 5000 means that messages are not renumbered until the
            highest number is equal to, or greater than 5000.
            After renumbering, message numbers start at 1 with no
            gaps. Default is 0 = no renumbering.

        MaxAgeB
            Maximum lifefime in days for a bulletin (default 30)

        MaxAgePR
            Maximum lifetime for private mail that has been read.
            (default 180)

        MaxAgeMid=30
            Maximum lifetime for message identifiers (default 30)

        WpUpdateTo
            Callsign (without SSID) of neighbour BBS to whom WP
            updates are to be sent. Can be used multiple times, to
            specify more than one BBS. The default is none, i.e.
            don't send WP updates.

</code> **EXAMPLES** <code>
        ForwardInterval=3600
        FwdKickOnRcv=0
        WpUpdateTo=GB7PZT

</code> **SEE ALSO** <code>
        PMS(1)         -- Access Personal Message System(s).
        PMS(9)         -- About the PMS.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
=====PPPHOST=====
<code>PPPHOST.n(8)            XROUTER REFERENCE MANUAL            18/10/2023
</code> **NAME** <code>
        PPPHOST.n -- PPP Configuration File(s) (Optional).

</code> **DESCRIPTION** <code>
        This optional file is required only if a PSTN modem is
        connected to XRouter and auto-answer is enabled.

        It is read only when a modem caller issues the command
        "XLINK PPP", and may contain PPP commands to override the
        default PPP configuration for the duration of the call. It
        may also contain NAT commands.

        The default configuration is probably OK for most purposes,
        but you may for example wish to change the inactivity
        timeout or the IP address.

        There may be several of these files, one for each modem
        port. The "n" represents the port number on which the
        caller has accessed XRouter.

</code> **FORMAT** <code>
        Each command must be on a separate line, Blank lines, or
        lines beginning with ';' or '#' are ignored. The maximum
        line length is 127 characters.

        See the PPP MAN page for details of the PPP commands.

</code> **FILES** <code>
        If required, this file must be located in the same
        directory as the XRouter executable.

</code> **SEE ALSO** <code>
        NAT(1)  -- Network Address Translation Commands.
        PPP(1)  -- PPP Configuration Commands.
        PSTN(9) -- PSTN Modem Support.

</code>
----
=====REJECT=====
<code>REJECT.SYS(8)           XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        REJECT.SYS -- Mail Rejection Control File.

</code> **DESCRIPTION** <code>
        The optional file REJECT.SYS, which resides in the PMS
        subdirectory, controls the "rejecting" of messages. It is
        used to reject unwanted types or categories of mail when they
        are offered (proposed) by other mailboxes. 

        The file is read "live" upon receipt of each proposal, so it
        can be edited on the fly, and changes take effect immediately.

</code> **FORMAT** <code>
        REJECT.SYS contains "rules" which control rejection of mail.
        Each rule must occupy a separate line. Blank lines and comment
        lines are allowed. The latter must begin with '#' or ';' in
        the leftmost column.

        Each rule consists of exactly 5 fields as follows:

            <type>  <to>  <from>  <at>  <size> 

            <type> is the message type, i.e. P, B, A, E, T, * etc.
            <to>   is the destination callsign or bulletin category.
            <from> is the sender's callsign.
            <at>   is the destination BBS or distribution area
            <size> is the maximum message size in bytes.

        Rules are case-independent, and wildcards are allowed.

        The exception is the <size> field where 0 = "don't care".
        If <size> is non-zero and the proposed message size is smaller
        than <size>, the message is allowed even if all the other
        fields match.

        Note that only FBB proposals include size, MBL ones don't.

        If the <at> field starts with a caret '^', it inverts the
        meaning of that field. e.g. "^GBR" rejects all "at" fields
        EXCEPT GBR.

</code> **OPERATION** <code>
        Incoming message proposals are tested against each rule in
        turn. If a rule matches all the message fields, the message is
        rejected.

</code> **EXAMPLE** <code>
        # Reject earthquake bulls of any size, from anyone: 
        # type  to      from   at     size
        # --------------------------------
          B     EQUAKE  *      *      0

</code> **SEE ALSO** <code>
        HOLD.SYS(8) -- Message Holding Control File.
        PMS(9)      -- About the Mailbox.

</code>
----
=====SOCKS=====
<code>SOCKS.ACL(8)            XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        SOCKS.ACL -- SOCKS Proxy Egress Control File (Optional).

</code> **DESCRIPTION** <code>
        The SOCKS.ACL file contains "rules" to control which
        destinations are allowed to be accessed via the SOCKS
        proxy.

        The rules allow you to specify which destination IP
        addresses and TCP ports may be accessed by specified
        source IP ranges.

        If the file is not present, or contains no valid rules,
        all destinations are blocked. Attempting to access
        a blocked destination causes the proxy to return an
        "access denied" code.

</code> **FORMAT** <code>
        The format of the entries in SOCKS.ACL is the same as
        other .ACL (Access Control List) files.

        Each "rule" is specified on a separate line. Blank lines,
        or lines beginning with ';' or '#' are ignored. The
        maximum line length is 255 characters.

        Within each rule, fields must be separated by one or
        more spaces or tabs. The fields are as follows:

        <action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>

        The fields have the following meaning:

        <action>   PERMIT  Allow egress
                   DENY    Prevent egress

        <src_ip>   Source IP address (uplinked user).

        <dst_ip>   Destination IP address (target system).

        [mask]     Optional field.
                   Either: No. of bits (0-32) of address to
                           match from left to right,
                   Or:     Subnet mask in form n.n.n.n

        <port(s)>  One or more TCP service numbers (0-65535) on
                   the target system.  Allowed formats are "n",
                   "n,n,n", "n-n" or combination thereof.


        In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
        "all addresses".

</code> **NOTE** <code>
        Rule testing stops at the *first* matching "permit" or
        "deny" statement, so it is vital that the list is ordered
        correctly.  For instance, to allow Internet users to
        access all LAN ports except 513 it would be ok to use:

                deny    0.0.0.0/0  192.168.0.0/24  513
                permit  0.0.0.0/0  192.168.0.0/24  1-65535

        but if the entries were reversed, the "permit" rule would
        match every case and the "deny" rule wouldn't be actioned.

</code> **EXAMPLES** <code>
        ; Allow LAN users to tunnel to anyone:
        PERMIT 192.168.0.0/24  0.0.0.0/0  0-65535
        ;
        ; Allow Internet users to tunnel only to certain
        ; ports on the node machine:
        PERMIT 0.0.0.0/0  192.168.0.245  23,87,1448,3600
        ;
        ; Allow Internet users to tunnel only to ports 23
        ; and 80 on the BBS machine:
        PERMIT 0.0.0.0/0  192.168.0.4  80,23
        ;
        ; Allow Amprnet users to access any Amprnet destination
        PERMIT 44.0.0.0/8  44.0.0.0/8  0-65535

</code> **FILES** <code>
       If required, SOCKS.ACL must be located in the same
       directory as the XRouter executable.

</code> **SEE ALSO       ** <code>
       TELGUEST.ACL(8) -- Telnet Egress Control for Guest Users.
       TELPROXY.ACL(8) -- Telnet Proxy Egress Control File
       HTTP.ACL(8) -- HTTP Proxy Egress Control File

</code>
----
=====TELGUEST=====
<code>TELGUEST.ACL(8)         XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        TELGUEST.ACL -- TELNET Guest Egress Control File (Optional).

</code> **DESCRIPTION** <code>
        The TELGUEST.ACL file contains "rules" to control which
        destinations are allowed to be accessed by "guest" users
        using the TELNET command.

        The rules allow you to specify which destination IP
        addresses and TCP ports may be accessed by specified
        source IP ranges.

        If the file is not present, or contains no valid rules,
        all destinations are blocked. Attempting to access
        a blocked destination causes the "Access Denied" response.

        If the facility is enabled by suitable entries in
        ACCESS.SYS, "Guest" users are those who access XRouter via
        Telnet, using the password "guest". As it is not known if
        they are genuine Radio Hams, they are prevented from
        downlinking to any AX25 or NetRom destination, but the
        sysop may choose to allow them to access certain other
        destinations using this file. 

</code> **FORMAT** <code>
        The format of the entries in TELGUEST.ACL is the same as
        other .ACL (Access Control List) files.

        Each "rule" is specified on a separate line. Blank lines,
        or lines beginning with ';' or '#' are ignored. The
        maximum line length is 255 characters.

        Within each rule, fields must be separated by one or
        more spaces or tabs. The fields are as follows:

        <action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>

        The fields have the following meaning:

        <action>   PERMIT  Allow egress
                   DENY    Prevent egress

        <src_ip>   Source IP address (uplinked user).

        <dst_ip>   Destination IP address (target system).

        [mask]     Optional field.
                   Either: No. of bits (0-32) of address to
                           match from left to right,
                   Or:     Subnet mask in form n.n.n.n

        <port(s)>  One or more TCP service numbers (0-65535) on
                   the target system.  Allowed formats are "n",
                   "n,n,n", "n-n" or combination thereof.


        In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
        "all addresses".

</code> **NOTE** <code>
        Rule testing stops at the *first* matching "permit" or
        "deny" statement, so it is vital that the list is ordered
        correctly.  For instance, to allow Internet users to
        access all LAN ports except 513 it would be ok to use:

                deny    0.0.0.0/0  192.168.0.0/24  513
                permit  0.0.0.0/0  192.168.0.0/24  1-65535

        but if the entries were reversed, the "permit" rule would
        match every case and the "deny" rule wouldn't be actioned.

</code> **EXAMPLES** <code>
        ; Allow LAN users to telnet to anyone:
        PERMIT 192.168.0.0/24  0.0.0.0/0  0-65535
        ;
        ; Allow Internet users to telnet only to ports 23
        ; and 80 on the BBS machine:
        PERMIT 0.0.0.0/0  192.168.0.4  80,23
        ;
        ; Allow Amprnet users to access any Amprnet destination
        PERMIT 44.0.0.0/8  44.0.0.0/8  0-65535

</code> **FILES** <code>
       If required, TELGUEST.ACL must be located in the same
       directory as the XRouter executable.

</code> **SEE ALSO** <code>
       ACCESS.SYS(8)   -- Telnet Access Control File.
       HTTP.ACL(8)     -- HTTP Proxy Egress Control File
       SOCKS.ACL(8)    -- SOCKS Proxy Egress Control File
       TELPROXY.ACL(8) -- Telnet Proxy Egress Control file.

</code>
----
=====TELPROXY=====
<code>TELPROXY.ACL(8)         XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        TELPROXY.ACL -- TELNET Proxy Egress Control File (Optional).

</code> **DESCRIPTION** <code>
        The TELPROXY.ACL file contains "rules" to control which
        destinations are allowed to be accessed via the Telnet
        proxy.

        The rules allow you to specify which destination IP
        addresses and TCP ports may be accessed by specified
        source IP ranges.

        If the file is not present, or contains no valid rules,
        all destinations are blocked. Attempting to access
        a blocked destination causes the proxy session to
        disconnect.

        If the rules in ACCESS.SYS are such that your Telnet proxy
        is accessible without password, then egress control is vital,
        to prevent miscreants using your telnet proxy to access other
        systems while hiding their IP address.

</code> **FORMAT** <code>
        The format of the entries in TELPROXY.ACL is the same as
        other .ACL (Access Control List) files.

        Each "rule" is specified on a separate line. Blank lines,
        or lines beginning with ';' or '#' are ignored. The
        maximum line length is 255 characters.

        Within each rule, fields must be separated by one or
        more spaces or tabs. The fields are as follows:

        <action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>

        The fields have the following meaning:

        <action>   PERMIT  Allow egress
                   DENY    Prevent egress

        <src_ip>   Source IP address (uplinked user).

        <dst_ip>   Destination IP address (target system).

        [mask]     Optional field.
                   Either: No. of bits (0-32) of address to
                           match from left to right,
                   Or:     Subnet mask in form n.n.n.n

        <port(s)>  One or more TCP service numbers (0-65535) on
                   the target system.  Allowed formats are "n",
                   "n,n,n", "n-n" or combination thereof.


        In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
        "all addresses".

</code> **NOTE** <code>
        Rule testing stops at the *first* matching "permit" or
        "deny" statement, so it is vital that the list is ordered
        correctly.  For instance, to allow Internet users to
        access all LAN ports except 513 it would be ok to use:

                deny    0.0.0.0/0  192.168.0.0/24  513
                permit  0.0.0.0/0  192.168.0.0/24  1-65535

        but if the entries were reversed, the "permit" rule would
        match every case and the "deny" rule wouldn't be actioned.

</code> **EXAMPLES** <code>
        ; Allow LAN users to tunnel to anyone:
        PERMIT 192.168.0.0/24  0.0.0.0/0  0-65535
        ;
        ; Allow Internet users to tunnel only to certain
        ; ports on the node machine:
        PERMIT 0.0.0.0/0  192.168.0.245  23,87,1448,3600
        ;
        ; Allow Internet users to tunnel only to ports 23
        ; and 80 on the BBS machine:
        PERMIT 0.0.0.0/0  192.168.0.4  80,23
        ;
        ; Allow Amprnet users to access any Amprnet destination
        PERMIT 44.0.0.0/8  44.0.0.0/8  0-65535

</code> **FILES** <code>
       If required, TELPROXY.ACL must be located in the same
       directory as the XRouter executable

</code> **SEE ALSO** <code>
       SOCKS.ACL(8)    -- SOCKS Proxy Egress Control File
       TELGUEST.ACL(8) -- Telnet Egress Control for Guest Users.
       HTTP.ACL(8)     -- HTTP Proxy Egress Control File

</code>
----
=====TELPROXY=====
<code>TELPROXY.MSG(8)         XROUTER REFERENCE MANUAL            17/10/2023
</code> **NAME** <code>
        TELPROXY.MSG -- Telnet Proxy Logon Message File (Optional).

</code> **DESCRIPTION** <code>
        This optional file is only required if you are using the
        Telnet Proxy feature.  It contains text which is sent to
        the user upon uplink connection to the proxy.

        If the file is NOT present, the following default text is
        displayed:

           Use: Tel[net] <ipaddr> [port] 
           Ready
           >

        If the TELPROXY.MSG file is present, its contents are sent
        to the user in place of the default text. Therefore you may
        customise the logon text to suit your clientele.

</code> **EXAMPLE** <code>
        This is an example of what the TELPROXY.MSG file might
        contain:

        --------------------- example starts --------------

        To connect to another system, use "TEL[net] <ipaddr> [port]"

        e.g. Tel 44.131.91.2 7777

        Type HELP for any other help

        ---------------------- example ends -----------------

</code> **NOTES** <code>
        By default, the telnet proxy listens on TCP port 2323. This
        may be reassigned or disabled using the TELPROXYPORT
        directive in XROUTER.CFG.

</code> **FILES** <code>
        If present, TELPROXY.MSG must be located in the same
        directory as the XRouter program.

        The associated TELPROXY.ACL file controls which
        destinations are available to users, based on their source
        IP addresses.

</code> **SEE ALSO** <code>
        TELPROXY.ACL(8) -- Telnet Proxy Egress Control Rules.

</code>
----
=====USERPASS=====
<code>USERPASS.SYS(8)         XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        USERPASS.SYS -- User Passwords File (Optional).

</code> **DESCRIPTION** <code>
        The entries in this optional file are used, if dictated
        by entries in ACCESS.SYS, to control normal Telnet
        (port 23) logins, Telnet Proxy (port 2323), and APRS
        server (port 1448) logins. They are not used for sysop
        logins, RLOGIN or FTP.

        Passwords are not required for normal AX25 / NetRom access.

</code> **FORMAT** <code>
        There should be one entry for each user, and each entry
        must be on a separate line, Blank lines, or lines beginning
        with ';' or '#' are ignored. The maximum line length is 80
        characters.

        Entries must consist of two fields separated by one or more
        spaces or tabs as follows:

                <callsign> <password>  

       <callsign> is the user's callsign without SSID.

       <password> is the password string. Must not contain spaces.

       Fields are not case-sensitive.

</code> **EXAMPLE** <code>
        ; USERPASS.SYS for Xrouter
        ;
        ; This file contains passwords for Telnet and Modem logins.
        ;
        ; Fields are: <callsign> <password>
        ; Callsigns should not include SSID
        ;
        G8PZT amazon
        G7CXZ drvxcdfre
        ;

</code> **NOTE** <code>
        For extra security, it is advisable for sysops to use
        different passwords for telnet and RLOGIN.

</code> **FILES** <code>
        If present, USERPASS.SYS must be located in the same
        directory as XRouter itself.

</code> **SEE ALSO** <code>
        PASSWORD.SYS(8) -- Sysop Password File.

</code>
----
=====XENCAP=====
<code>XENCAP.TXT(8)           XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        XENCAP.TXT -- Amprnet Encapsulated Routing File (optional).

</code> **DESCRIPTION** <code>
        This experimental file is similar to ENCAP.TXT, except that it
        allows encapsulation modes other than "encap" to be specified.

        It is thus an e(X)tended version of ENCAP.TXT. Its purpose is
        to allow those XRouter sysops who are unable to handle IPEncap
        (protocol number 4) to act as amprnet gateways by means of
        other protocols, such as IPIP (protocol 94) or IPUDP.

        If this file is present when XRouter boots up, it will read
        the routes into its IP routing table.

        If you are not running an amprnet "gateway", or have set up
        your own encap routes in IPROUTE.SYS, you do not need this
        file.

</code> **FORMAT** <code>
        The format of routing entries in XENCAP.TXT is almost
        identical to those in ENCAP.TXT, with the exception that the
        word "encap" may be replaced by other modes:

           route addprivate 44.131.91.0/24 <mode> 62.31.206.176

        The "addprivate" stipulates that the route should be hidden
        from users, i.e. not displayed by the IPROUTES command.

        The "44.x.x.x/xx" part specifies which amprnet route(s)
        this entry applies to.

        The "<mode>" part tells XRouter which encapsulation mode to
        use as follows:

                encap   - IP-over-IP protocol 4
                ipip    - IP-over IP protocol 94
                ipudp   - IP-over-UDP

        The final field is the Internet IP address of the gateway
        which handles the specified amprnet route(s).

</code> **FILES** <code>
        If required. XENCAP.TXT should be located in same directory
        as the XRouter executable.

</code> **CAVEATS** <code>
        This file is experimental, and the format is likely to change
        to accommodate more features in the future.

</code> **SEE ALSO** <code>
        ENCAP.TXT(8)   -- Encapsulated Routing File.
        IPROUTE.SYS(8) -- IP Routing and Configuration File

</code>
----
=====XRNODES=====
<code>XRNODES(8)              XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        XRNODES -- Routes / Nodes Recovery File.

</code> **DESCRIPTION** <code>
        The XRNODES file contains a list of the known NetRom
        routes and nodes, and is used to populate the nodes table
        when XRouter boots.  This allows XRouter to be stopped and
        restarted without losing the nodes table. Without this
        file, it would take several hours to rebuild the nodes
        table from received broadcasts.

        The nodes and routes tables are saved to this file every 
        NODESINTERVAL, at close-down, and whenever the SAVENODES
        command is used (unless a different filename is specified).

        The file is created by XRouter, but may be edited by the
        sysop. Apart from the lack of .TXT extension, it is an
        ordinary plain text file.

</code> **FORMAT** <code>
        The ROUTE entries are specified first, and have the
        following format:

        ROUTE ADD <call> <port> <qual> [!] [VIA call ...] [options]

        <call> is the callsign of the neighbour node.

        <port> is the port on which the neighbour is reached.

        <qual> is a "quality" between 0 and 255 indicating how
               "good" the route is.

        [!] indicates a locked route (i.e. one which will not expire).

        [VIA] indicates that the neighbour is reached via
              digipeater(s). Digipeater callsigns are separated by
              exactly ONE space, with the end of the list marked by
              exactly TWO spaces.

        [options] are "non-standard" parameters which can override
                  the port defaults for that route as follows:

           [maxframe [frack [paclen [maxtt [maxhops]]]]]

        For example:

            ROUTE ADD W7XCV 1 100
            ROUTE ADD G8UYL 2 240 ! 5 7000 120
            ROUTE ADD G7DIG 5 ! VIA M7FRT M3RED  2 

            The first line shows unlocked neighbour W7XCV on port 1
            with quality of 100.  The second line shows neighbour
            G8UYL locked in on port 2 with a quality of 240,
            maxframe of 3, frack of 7000, and paclen 120.  The
            third line shows neighbour G7DIG locked in using a
            digipeated path via M7FRT and M3RED, with maxframe of 2.


        Following the ROUTE entries, the remainder of the file
        consists of NODE entries, one per line. The format is as
        follows:

        NODE ADD <alias:call> <r1> <p1> <q1> [!] [<r2> ...]

        <alias:call> is the alias and callsign of the distant node.
 
        <r1> is the callsign of the primary route to that node,
                 for which there must exist a ROUTE entry.

        <p1> is the port used to reach the neighbour.

        <q1> is the quality of the route to the node via that
                neighbour.

        [!] indicates a locked entry.

        There can be up to 3 different routes listed for each node.
        For example:

            NODE ADD #TLFRD:GB7IPT-7 G8PZT 1 142 ! G8UYL 2 139
            NODE ADD BRUM:GB7BM G8PZT 1 94 G8UYL 2 92
            NODE ADD BUXTON:GB7DAD-8 G8PZT 1 22 G8UYL 2 21

</code> **FILES** <code>
        XRNODES is located in the same directory as XRouter.

</code> **CAVEATS** <code>
        If XRouter is closed down for more than a few hours, the
        network may change, and the XRNODES file will become out
        of date. This could re-introduce expired nodes back into
        the tables when XRouter is started. In this case it would be
        better to delete XRNODES before booting up, and let XRouter
        rebuild the tables from broadcasts.

</code> **SEE ALSO** <code>
        LOADNODES(1) -- Load the nodes and routes tables.
        SAVENODES(1) -- Save the nodes and routes tables.

</code>
----
=====XROUTER=====
<code>XROUTER.CFG(8)          XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        XROUTER.CFG -- Main Configuration File (Mandatory).

</code> **DESCRIPTION** <code>
        This file is mandatory, and contains most of the
        configuration info for XRouter.  It is read only when the
        program starts.

        It is a text file containing directives of the general form
        <keyword>=<value>, each on a separate line.  Keywords are
        not case sensitive, and in general they may be specified
        in any order, but interfaces MUST be defined before the
        ports that reference them.
  
        Blank lines are allowed, and comment lines must begin with
        a semicolon (;) or hash (#) in the leftmost column.  Lines
        must not exceed 255 characters.

        The sections of the file outside the INTERFACE, PORT, RADIO,
        CONSOLE, APPL and ROUTES blocks, are considered "global",
        i.e. this is where the keywords with global action can be
        used. E.g. this is where the node callsign and alias are
        specified.

        Some of the keywords, e.g. IPADDRESS and PACLEN may be
        used globally (to set defaults) and within PORT definition
        blocks (to set port-specific overrides).
       
        In the following sections, '*' indicates the mandatory
        parameters. Additional parameters (e.g. IPADDRESS) may need
        to be specified to enable full operation. Remaining
        parameters have sensible defaults built into the program.
        Defaults are indicated in brackets ().

</code> **GLOBAL KEYWORDS** <code>
        The following keywords are accepted in the GLOBAL section:

        ACTIONCOLOR    Text colour for pending actions (yellow)
        AGWPORT        TCP port for AGWPE emulator (8000)
        ALTITUDE       Site altitude above mean sea level (0)
        APPL           Begins an application definition block
        APPLQUAL       Default NetRom quality for applications (150)
        APRSCALL       Callsign used by Igate
        APRSPORT       TCP port for APRS server (1448)
        AUDIODEVICE    Audio output device name
        BELL           Allowed times for console bells (0800-2200)
        BLEVEL         Netrom Budlist de-rate level.
        BOOTWIN        Window to display after bootup (6)
        CHATALIAS      Chat server alias
        CHATCALL       Chat server callsign
        CHATLINKS      Callsigns of linked chat servers
        CHATLOG        Controls logging of chat server activity (0)
        CHATPORT       TCP port for Chat server (3600)
        CHATQUAL       Chat server Netrom quality to bcast (150)
        COMMAND        Creates a custom command.
        CONSOLE        Begins a CONSOLE definition block.
        CONTACT        Sysop's contact details.
        CTEXT          Text sent to a users upon connection
        CTFLAGS        Flags which control sending of CTEXT (9)
        CTRLADDR       Hex address of hardware control port (378)
        DEFAULTLANG    Default language number (0)
        DCACHE         Size of domain cache (10)
        DISCARDPORT    TCP port for Discard server (9)
        DNS            Domain Name Server to use (internal)
        DOMAIN         Domain suffix (ampr.org.)
        DXFLAGS        Controls the DX heard display (0)
        ECHOPORT       TCP port of Echo server (7)
        ENABLE_LINKED  Controls who may use "*** LINKED AS"
        EXCLUDE        AX25 L2 callsign Blacklist
        FINGERPORT     TCP port of Finger server (79)
        FTPPORT        TCP port for FTP server (21)
        HAAT           Antenna Height Above Average Terrain (0)
        HAMLIBPORT     TCP Port for Hamlib emulation server
        HIDENODES      Controls visibility of '#' nodes (0)
        HOSTNAME       Host name for TCP/IP operations
        HTTPPORT       TCP port for HTTP server (80)
        HTTPROOT       HTTP server's root directory (HTTP)
        IDINTERVAL     Minutes between IDTEXT broadcasts (15)
        IDLETIME       Idle link shutdown time in secs (900)
        IDTEXT         ID beacon sent every IDINTERVAL
        IGATE          Controls whether Igate starts at boot up (0)
        INFOTEXT       Text sent in response to "I" command
        INPBCINTERVAL  Secs between scheduled INP3 unicasts (600)
        INTERFACE    * Begins Interface definition block
        IPADDRESS      Main (amprnet) IP address (0.0.0.0)
        IPENCAP        Enable/disable IPENCAP protcol 4 (0)
        IPIP           Enable/disable IPIP protocol 94 (0)
        IPTTL          IP Time to live (255)
        IPUDPPORT      UDP port for rcving IPUDP traffic (94)
        KILONFWD       Kill PMS message after forwarding (0)
        L3BUDLEVEL     Leakage level (0-255) for L3EXCLUDE (0)
        L3EXCLUDE      Callsigns whose L3 traffic is disrupted
        L3RTTINTERVAL  Secs between L3RTT checks (300)
        L3TTL          NetRom layer 3 Time To Live (25)
        L4DELAY        NetRom layer 4 delay in secs (3)
        L4RETRIES      NetRom layer 4 retries (3)
        L4T3           L4 link check interval in secs (840)
        L4TIMEOUT      NetRom layer 4 timeout in secs (120)
        L4WINDOW       NetRom layer 4 window (10)
        LATITUDE       Latitude in decimal degrees (999)
        LOCATOR        Maidenhead QTH locator (empty)
        LOG            Controls activity logging level (0)
        LONGITUDE      Longitude in decimal degrees (999)
        MAPCOMMENT     Short text to display on nodes map
        MAPSERVADDR    Hostname / IP address of nodes map server
        MAPSERVPORT    TCP port of nodes map server (80)
        MAXARP         Max size of ARP table (20)
        MAXCIRCUITS    Max concurrent NetRom L4 circuits (20)
        MAXHOPS        Max acceptable hop count (30)
        MAXLINKS       Max simultaneous AX25 L2 connections (30)
        MAXNODES       Max size of NetRom nodes table (200)
        MAXROUTES      Max NetRom neighbour routes (30)
        MAXSESSIONS    Max simultaneous sessions (20)
        MAXTCP         Max simultaneous TCP connections (20)
        MAXTT          Maximum Trip Time in secs (500)
        MINQUAL        Minimum NetRom quality in nodes table (10)
        MQTTSERVADDR   Hostname / IP addr of external MQTT broker
        MQTTSERVPORT   TCP port of external MQTT broker (1883)
        NFTPROOT       Root directory for Netrom FTP
        NODEALIAS    * AX25/NetRom alias of this node
        NODECALL     * AX25/NetRom callsign of this node
        NODESINTERVAL  Mins between nodes broadcasts (60)
        NUMCONOLES     Number of consoles (3)
        OBSINIT        NetRom obsolescence initial value (5)
        OBSMIN         NetRom obsolescence min to broadcast (3)
        PACLEN         AX25 default / NetRom packet length (120)
        PMSALIAS       AX25/NetRom alias of integral PMS
        PMSCALL        AX25/NetRom callsign of integral PMS
        PMSHADDR       PMS hierarchical address
        PMSQUAL        PMS NetRom quality to broadcast (0)
        PORT         * Begins a port definition block
        PROMPTCOLOR    Text colour for normal prompts (cyan)
        PROXY          Defines a NetRom proxy
        QUALADJUST     Derates NetRom quality by callsign (255)
        QTH            Location of this node (empty)
        RADIO          Begins a RADIO definition block
        RHPPORT        Remote Host Protocol server TCP port (9000)
        RIGSRVPORT     TCP port for radio server
        RLOGINPORT     TCP port for Rlogin server (513)
        ROUTES         Specifies locked-in NetRom routes
        ROWS           Vertical size of display in rows (25)
        SESSLIMIT      Max sessions per user (10)
        SOCKSPORT      TCP port for SOCKS proxy server (1080)
        SORTBYCALL     Sort nodes table by callsign not alias (0)
        SYNCACHELIFE   Lifetime in seconds of a cached TCP SYN (10)
        SYNCACHESIZE   Number of SYN cache slots (1000)
        T3             AX25 link check timer in secs (180)
        TELNETPORT     TCP port for Telnet server (23)
        TELPROXYPORT   TCP port for Telnet Proxy server (2323)
        TEXTCOLOR      Text colour for normal text (white)
        TTYLINKPORT    TCP port for TTYLINK server (87)
        UIFLOOD        APRS N-n digipeating (WIDE)
        UITRACE        APRS N-n digipeating (TRACE)
        WARNCOLOR      Text colour for warnings & errors (cerise)
        WXFILE         Weather import file name


</code> **APPL KEYWORDS** <code>
        The following keywords are accepted in the APPL blocks:

        APPLALIAS      Aplication alias
        APPLCALL       Application callsign
        APPLFLAGS      Flags which control application
        APPLNAME       Application name
        APPLQUAL       Application NetRom qulity to broadcast
        APPLTYPE       Type of application (for TCP only)
        ENDAPPL      * Ends application definition block


</code> **CONSOLE KEYWORDS** <code>
        The following keywords are accepted in CONSOLE blocks:

        ACTIONCOLOR     Text colour for confirming actions (yellow)
        BOTWINBGCOLOR   Background for menu bar (cyan)
        BOTWINTXTCOLOR  Text colour for menu bar (white)
        CAPTIONCOLOR    Text colour for captions (lime)
        CMDWINBGCOLOR   Background color for command line (navy)
        CMDWINTXTCOLOR  Text colour for command line (yellow)
        CONSOLECALL     Callsign for console operations
        CONSOLELANG     Language number for console ops (0=English)
        ECHOCOLOR       Colour for text echoed from cmd line (yellow)
        ENDCONSOLE    * Ends console definition block
        MIDWINBGCOLOR   Background for central window (black)
        MIDWINTXTCOLOR  Text colour for central window (white)
        MMASK           Flags specifying protocols to trace (3f8)
        MPORTS          Ports to monitor by default (all)
        PROMPTCOLOR     Text colour for prompts (cyan)
        REVIEW          No. of lines of scrollback (400)
        RXCOLOR         Text color for RX tracing (lime)
        TOPWINBGCOLOR   Status line background colour (cyan)
        TOPWINTXTCOLOR  Status line text colour (white)
        TXCOLOR         Text colour for TX tracing (pink)
        WARNCOLOR       Text colour for warning/error msgs (cerise)

</code> **INTERFACE KEYWORDS** <code>
        The following keywords are accepted in INTERFACE blocks:

        APPLNUM         Application number (DEDHOST only)
        CHANNEL         Channel on multi-channel hardware
        CHANNELS        No. of TNC channels (DEDHOST only)
        COM             COM number
        CONFIG          Hardware-specfic coonfig options
        ENDINTERFACE  * Ends interface definition block
        ETHADDR         Ethernet address (NdisXpkt only)
        FLOW            Flow control options (async only)
        ID              Interface identification string
        INTNUM          Was interrupt number, now multi-purpose
        IOADDR          Was I/O address, now multi-purpose
        KISSOPTIONS     Options for KISS interfaces only
        MTU           * Maximum Transmission Unit
        PROTOCOL        Protocol used on this interface
        RADIO           Radio number associated with interface
        SPEED           Serial (async) or RF (SCC) baud rate
        TYPE          * Type of hardware

</code> **PORT KEYWORDS** <code>
        The following keywords are accepted in PORT blocks:

        APPLMASK        Controls which applications are visible
        APRSPATH        Default digipeater path for APRS
        BCAST           List of destinations for "broadcasting"
        BCFROM          Callsigns who may broadcast
        CFLAGS          Controls AX25 up/downlinking
        CHANNEL         Channel to use on interface (A)
        CHATALIAS       Port override for global chatalias
        CHATCALL        Port override for global chatcall
        CTEXT           Port override for global ctext
        CTFLAGS         Port override for global ctflags
        CWID            Text to send in CW every 30' (SCC only)
        DHCP            Enables / disables DHCP client (0)
        DIGIFLAG        Controls digipeating
        DIGIPORT        Port to digipeat on (this port)
        DYNDNS          Enable / disable Dynamic DNS update client
        ENDPORT       * Ends port definition block
        EXCLUDE         List of callsigns not allowed to connect
        FEC             Enable / disable Forward Error Correction (0)
        FRACK           AX25 Frame Acknowledgement time ms (7000)
        FREQUENCY       Radio frequency in Hz (0)
        FULLDUP         Allow simultaneous TX/RX (SCC only)
        ID            * Text to identify port on ports display
        IDPATH          Dest & digi path for ID beacons ("ID")
        IDTEXT          Port override for global IDTEXT
        INITSTR         Modem initialisation string (modem only)
        INTERFACENUM  * Interface number this port is bound to
        INTERLOCK       Prevents simultaneous TX on SCC cards
        IPADDRESS       Port override for global IP address
        IPLINK          IP address / hostname of AXIP/AXUDP peer
        MAXFRAME        Max outstanding AX25 L2 frames (3)
        MAXHOPS         Port override for global MAXHOPS
        MAXTT           Port override for global MAXTT
        MHEARD          Enable / disable MHeard on this port
        MHFLAGS         Controls contents of MHeard list (255)
        MINQUAL         Port override for global MINQUAL
        MINTXQUAL       Min NetRom quality to broadcast
        NETMASK         Subnet mask used with IPADDRESS
        NODESINTERVAL   Port override for global NODESINTERVAL
        PACLEN          Port override for global PACLEN
        PERSIST         Probability to transmit 0-255 (64)
        PIPE            Creates a "frame pipe" to another port
        PIPEFLAG        Controls frame piping (3)
        PMSALIAS        Port override for global PMSALIAS
        PMSCALL         Port override for global PMSCALL
        PORTALIAS       Port override for global NODEALIAS
        PORTALIAS2      Secondary alias for digipeating only.
        PORTCALL        Port override for global NODECALL
        PROXY           NetRom systems to tunnel AX25 to
        QUALITY         Default NetRom neighbour quality (10)
        RESPTIME        AX25 delayed ack timer in ms (2000)
        RETRIES         Max connect/disconnect/resent attempts (10)
        RFBAUDS         RF baud rate (1200)
        SESSLIMIT       Max simultaneous connections per user (255)
        SLOTTIME        CSMA interval timer (millisecs) (100)
        SOFTDCD         Use software DCD (SCC only) (0)
        SYSOP           If 1, all users on this port are sysops (0)
        TXDELAY         Delay (ms) between PTT and start of data (300)
        TXPORT          Port on which to TX if not this one (0)
        TXTAIL          Delay (ms) between data end and PTT drop (100)
        UDPLOCAL        RX UDP port for AXUDP operations (93)
        UDPREMOTE       TX UDP port / Partners AXUDP RX port (93)
        UNPROTO         Dest & digi calls for unproto broadcasts
        USERS           Max simultaneous users on this port (255)
        VALIDCALLS      Only these callsigns allowed to connect.

</code> **RADIO KEYWORDS** <code>
        The following keywords are accepted in RADIO blocks:

        BAUDS           Baud rate for the TTY (not for Hamlib).
        COM             TTY device name / IP address:port
        ENDRADIO        End RADIO definition block.
        FREQUENCY       Initial receive frequency in Hz.
        MODE            Initial modulation mode.
        NAME            Name / Description for the radio
        OFFSET          Radio's frequency error in PPM
        PTTMETHOD       How the PTT is controlled
        RXAUDIODEV      Device for receiving audio from radio
        SQUELCH         Initial squuelch level
        STOPBITS        Number of "stop" bits on the serial data
        TXFREQ          Initial TX frequency (if different to RX)
        TYPE            Type number of radio
        VOLUME          Initial volume level

</code> **FILES** <code>
        XROUTER.CFG must be located in the same directory as the
        XRouter executable.

</code> **SEE ALSO** <code>
        APPLS(9)  -- Application Support.
        IFACES(6) -- Interfaces in XRouter.
        PORTS(6)  -- PORTS in XRouter.
        RADIO(7)  -- Radio Control Definition Block.

</code>
----
=====XWEB=====
<code>XWEB.CLASS(8)           XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        XWEB.CLASS -- Java Applet.

</code> **DESCRIPTION** <code>
        (The following is also in the HTTP-SRV manual page)

        The Java applet XWEB.CLASS can be used to connect to XRouter
        with a web browser.

        The distribution archive contains the applet file, plus 3
        rudimentary .HTM pages for you to examine or experiment with. 

        CONNECT.HTM is the menu page for 3 types of connection, and
        would typically be accessed via a "connect" link on the main
        page.  You may however wish to put the 3 connect options
        directly on the main page - it's up to you.

        CONN23.HTM uses the Java applet to perform a normal telnet
        connect to port 23.  The port number is configurable (see
        below), so you could clone the page for use with your chat
        server.

        CONN80.HTM uses the Java applet to perform a "tunnelled"
        connection, which can be used via corporate firewalls which
        block normal Telnet.

        If you wish to the above files and the applet, they must be
        located within the HTTP tree.

        You can change the applet colours and font, the number of
        rows and columns displayed, and the connection mode (normal
        TELNET, or HTTP tunnel), using <PARAM> tags in the HTML file.
        For example: <PARAM NAME="font" VALUE="Courier">.

        The parameters which can be specified are as follows:

        Param name     Default    Description
        rows           22         No. of rows in text window
        cols           80         No. of columns in text window
        bgcolour       Dark grey  Applet background colour.
        borderColour   Light grey Applet framework colour.
        textBackground Black      Background for text/cmd windows.
        textColour     White      Colour of sent / rcvd text.
        font           Times      Font style for sent / rcvd text
        port           9999       TCP port number for connections.
        mode           Normal     Connection mode (normal / proxy).

        The only mandatory parameter is "port". This should normally
        be 23 for a normal telnet connect or 80 for an http-tunnelled
        connect, but you may use other values if you have moved or
        translated your Telnet or HTTP ports.

        Colours should be specified as a 24 bit hexadecimal number in
        'C' style, e.g. 0xEECCFF, where the first 2 digits represent
        the RED value, the second two digits represent the GREEN
        value and the last two digits represent the BLUE value. Some
        browsers can only display 216 discrete colours, so you should
        preferably use the "browser-safe" values, which are all
        formed from combinations of 00, 33, 66, 99, CC and FF.

        The default font is quite small, and the characters are not
        of a constant width, which means tables sent by XRouter will
        not line up correctly.  You may use the "font" parameter to
        override the default.  The recommended font is "Courier",
        which is slightly larger and uses constant width characters.
        Note: if the chosen font is not found on the client's device,
        their default font will be used, so stick to the common ones.

        You may need to reduce the number of rows or columns
        displayed by the applet if you find it won't fit on a 640*480
        screen. It fits nicely on 800*600, but you may wish to
        optimise it for another screen size, or even offer users the
        choice.

        If you change the font, rows or cols, you may need to tweak
        the WIDTH and HEIGHT attributes in the APPLET tag to prevent
        parts of the applet from being obscured.

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

</code>
----