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 7 - Configuration Directives======
==== ACTIONCOLOR ====
<code>ACTIONCOLOR(7)          XROUTER REFERENCE MANUAL            26/10/2023
</code> **NAME** <code>
        ACTIONCOLOR -- Colour For XRouter Actions and Events.

</code> **SYNOPSIS** <code>
        ACTIONCOLOR=<colour>

</code> **DESCRIPTION** <code>
        ACTIONCOLOR is an optional directive that can be used both
        in the "global" section of XROUTER.CFG, and within CONSOLE
        definition blocks.

        It specifies the colour used by XRouter for reporting
        "actions" such as "Pinging 8.9.8.9", and "events" such as
        "G9YAK is yelling".

        If used in the "global" section of XROUTER.CFG, the setting
        is inherited by all CONSOLEs subsequently defined.

        If used within a CONSOLE definition block, it applies only
        to that console, overriding any inherited setting.

        The default ACTIONCOLOR is YELLOW.  Default colours have
        been carefully chosen for good visibility against a BLACK
        background.

</code> **OPTIONS** <code>
        <colour> should be one of the 16 colour names described in
        COLOURS(6), but please note that some colour combinations
        have very poor visibility.

        In general, the lighter the background colour, the smaller
        the choice of foreground colours that will work with it.

</code> **EXAMPLE** <code>
        ACTIONCOLOR=PINK

</code> **SEE ALSO** <code>
        ANSI(1)         -- Enquire/set ANSI colour mode
        COLOURS(6)      -- XRouter Display Colours.
        CONSOLES(6)     -- About XRouter Consoles.
        CAPTIONCOLOR(7) -- Colour For Captions and Headings.
        PROMPTCOLOR(7)  -- Colour For XRouter Prompts.
        WARNCOLOR(7)    -- Colour For warnings and Errors.
        XROUTER.CFG(8)  -- Main Configuration File.

</code>
----
==== AGWPORT ====
<code>AGWPORT(7)              XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        AGWPORT -- TCP Port for AGW Emulator.

</code> **SYNOPSIS** <code>
        AGWPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        AGWPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the AGW emulator. If not present, the default is 8000.

        The AGW emulator enables suitable AGW clients, such as
        UI-View, to use XRouter instead of AGW Packet Engine.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "AGWPORT=8000", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "AGWPORT=8000 9000", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting AGWPORT to zero on a stack prevents TCP connections
        to the AGW emulator via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        AGWHOST(6)     -- AGW Emulator.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== ALTITUDE ====
<code>ALTITUDE(7)            XROUTER REFERENCE MANUAL              20/9/2023

</code> **NAME** <code>
        ALTITUDE -- Site altitude above mean sea level.

</code> **SYNOPSIS** <code>
        ALTITUDE=<metres>

</code> **DESCRIPTION** <code>
        ALTITUDE is an optional directive that may be used anywhere
        in the "global" section of XROUTER.CFG. If present, it
        specifies the height of the node site in metres above mean
        sea level.

        At present ALTITUDE is reported on the INFO pages for
        interest purposes only, but may be used for node mapping or
        APRS in future.

</code> **EXAMPLE** <code>
        ALTITUDE=46  -- Site is 46 metres above mean sea level. 

</code> **SEE ALSO** <code>
        HAAT(7)        -- Antenna Height Above Average Terrain.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== APPLMASK ====
<code>APPLMASK(7)            XROUTER REFERENCE MANUAL                4/9/2023
</code> **NAME** <code>
        APPLMASK -- Application Connectivity Mask.

</code> **DESCRIPTION** <code>
        APPLMASK is an optional PORT configuration keyword, whose
        purpose is to control which applications are connectible at
        AX25 L2 on the port.

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

        APPLMASK is used only if XRouter is hosting applications,
        e.g. via the DEDHOST interface.

        If you want an application to be directly connectible on a
        particular port, the application must have an APPLCALL, an
        APPLALIAS or both, and the corresponding bit in that port's
        APPLMASK must be set.

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

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

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

</code> **SEE ALSO** <code>
        APPLMASK(1)    -- APPLMASK Command
        PORTS(6)       -- Ports in XRouter.
        APPLS(9)       -- Application Support.
        XROUTER.CFG(8) -- Main Configuration File.
        
</code>
----
==== APRSPATH ====
<code>APRSPATH(7)            XROUTER REFERENCE MANUAL              23/9/2023

</code> **NAME** <code>
        APRSPATH -- Default Digipeater Path for APRS.

</code> **SYNOPSIS** <code>
        APRSPATH=<digipeater>[,digipeater[,digipeater...]]

</code> **DESCRIPTION** <code>
        APRSPATH is an optional directive, used in PORT configuration
        blocks within XROUTER.CFG.

        If present, it specifies the default digipeater path for APRS
        frames originated by the APRS messaging shell and IGATE. If
        you omit this, the frames will be sent without digipeaters.

        APRS messaging shell users may override this path during
        run-time.

</code> **EXAMPLE** <code>
        APRSPATH=RELAY,WIDE

</code> **SEE ALSO** <code>
        AMSG(1)        -- APRS Mesaging Mode.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== APRSPORT ====
<code>APRSPORT(7)             XROUTER REFERENCE MANUAL             27/9/2023
</code> **NAME** <code>
        APRSPORT -- TCP Port for APRS Server.

</code> **SYNOPSIS** <code>
        APRSPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        APRSPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the APRS server. If not present, the default is 1448.

        The APRS server, enables suitable APRS clients, such as
        UI-View, to connect to it on the LAN and exchange APRS
        traffic with each other, with RF and via the IGATE.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "APRSPORT=1234", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "APRSPORT=1234 5678", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting APRSPORT to zero on a stack prevents TCP connections
        to the server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

        The APRS server is also available as NetRomX service 14.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        APRS-SRV(9)    -- APRS server.
        APRS-SVC(9)    -- NetRomX APRS Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== AUDIODEVICE ====
<code>AUDIODEVICE(7)            XROUTER REFERENCE MANUAL            4/9/2023
</code> **NAME** <code>
        AUDIODEVICE -- Specify audio device name.

</code> **SYNOPSIS** <code>
        AUDIODEVICE=<devicename>

</code> **AVAILABILITY** <code>
        Used only in XROUTER.CFG.

</code> **DESCRIPTION** <code>
        AUDIODEVICE is a global configuration keyword used in
        XROUTER.CFG to specify the audio device to use for console
        sounds such as warning bells.

        If AUDIODEVICE is not specified, sound output is via the PC
        speaker, if one is fitted.

        XRouter uses OSS (Open Sound System) (a) because OSS has been
        found to work much better than ALSA, and (b) because ALSA
        requires the host machine to have the "libasound" library
        installed. The XRouter philosophy is to avoid dependencies
        where possible.

        Having said that, XRouter can be supplied in "with-ALSA"
        versions if required.

</code> **EXAMPLE** <code>
        # Audio device for sound output:
        # Default OSS device is /dev/dsp (/dev/audio on Rasp pi)
        #
        AUDIODEVICE=/dev/dsp
        #

</code> **CAVEATS** <code>
        Linux has been gradually trying to force the use of ALSA by
        making it more difficult to access OSS. In this case XRouter
        can be run inside a "wrapper" progream such as AOSS as
        follows:

               "aoss /home/pi/xrouter/xrpi"

</code> **SEE ALSO** <code>
        AUDIO(9)       -- Audio on XRouter
        BELL(1)        -- Set acceptable hours for console sounds.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BCAST ====
<code>BCAST(7)              XROUTER REFERENCE MANUAL               23/9/2023

</code> **NAME** <code>
        BCAST -- Destinations for UI Broadcasting.

</code> **SYNOPSIS** <code>
        BCAST=<dest>[,dest]...

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

</code> **DESCRIPTION** <code>
        BCAST is an optional PORT configuration directive. It
        specifies a list of AX25 L2 destination addresses for
        "UI broadcasting".

        Received non-digipeater UI frames, addressed to one of these
        destinations, will be re-broadcasted on all ports which have
        a matching address in their BCAST list.

        If no matching ports are found, the frame is broadcast only
        on the port upon which it is received.

        This would be used for example to broadcast mail-for beacons
        or unproto headers from a BBS on one port, onto several
        other ports.

        Note: There is also a BCAST *command*, which has a completely
        different function!
        
</code> **OPTIONS** <code>
        The destination addresses must be separated by commas and
        there must be no spaces in the list.

</code> **EXAMPLE** <code>
        BCAST=MAIL,ALL

</code> **SEE ALSO** <code>
        BCAST(1)       -- Trigger a Nodes Broadcast.
        BCFROM(7)      -- Approved UI Broadcasters.
        BCAST(9)       -- About UI Broadcasting.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BCFROM ====
<code>BCFROM(7)             XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        BCFROM -- Approved UI Broadcasters.

</code> **SYNOPSIS** <code>
         BCFROM=<callsign>[,callsign..]

</code> **DESCRIPTION** <code>
        BCFROM is an optional PORT configuration directive.

        If present, it specifies a callsign or list of callsigns who
        are allowed to use the "UI broadcast" facility (see BCAST).

        If BCFROM is NOT present, the BCAST facility is unrestricted.

        BCFROM applies only to frames *directly* received on the port
        for which it is specified (i.e. not via digipeaters).

</code> **OPTIONS** <code>
        The argument to BCFROM is a single callsign, or a comma
        separated list of callsigns. There must be no spaces in the
        list.

</code> **EXAMPLE** <code>
        BCFROM=GB7PZT,GB7MAX

</code> **SEE ALSO** <code>
        BCAST(7)       -- Destinations for UI Broadcasting.
        BCAST(9)       -- About UI Broadcasting.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

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

</code> **SYNOPSIS** <code>
         BLEVEL=n  (where n is berween 0 and 255)

</code> **DESCRIPTION** <code>
        BLEVEL is an optional global XROUTER.CFG directive. It sets
        the L3 "budlist level". This is the leakage level (0-255) for
        L3EXCLUDE. The default is 0 (allow no packets).

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

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

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

</code> **NOTE** <code>
        A command of the same name can be used at runtime.

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

</code>
----
==== BLOGFLAGS ====
<code>BLOGFLAGS(7)            XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        BLOGFLAGS -- Options For Sysop's Blog.

</code> **SYNOPSIS** <code>
        BLOGFLAGS=n (where 0 <= n <= 15)

</code> **DESCRIPTION** <code>
        BLOGFLAGS is an optional directive used only in XROUTER.CFG.

        It controls whether or not the sysop's blog is enabled,
        whether or not the sysop is notified of new "likes" and
        replies, and whether or not the activity is published via the
        MQTT broker.

        If BLOGFLAGS is omitted, the blog is disabled.

</code> **OPTIONS** <code>
        The argument to BLOGFLAGS is a decimal number, which is the
        sum of the desired options from the following list:

            1 - Enable blog
            2 - Notify sysop (via PMS) of new replies
            4 - Notify sysop (via PMS) of new "likes"
            8 - Publish new posts / replies via MQTT

</code> **SEE ALSO** <code>
        BLOG(1)        -- Access Sysop's Blog.
        MQTT-SRV(9)    -- MQTT Server / Broker
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== BOOTWIN ====
<code>BOOTWIN(7)            XROUTER REFERENCE MANUAL               21/9/2023

</code> **NAME** <code>
        BOOTWIN -- Window to display after bootup.

</code> **SYNOPSIS** <code>
        BOOTWIN=n (where n is 1 to 12 inclusive)

</code> **DESCRIPTION** <code>
        BOOTWIN is an optional directive that can be used anywhere in
        the "global" section of XROUTER.CFG. If present, BOOTWIN
        specifies the window number to be displayed immediately after
        bootup. If not specified, or the number is out of range, it
        defaults to window 6, the "overview" window.

        Even if BOOTWIN is specified, if MON ON is used in
        BOOTCMDS.SYS, the first console is displayed instead.
        
        The window numbers in v503 are as follows. Note that the
        "consoles" are optional, and the number of consoles present
        is specified at bootup:

        1   Sysop chat
        2   Chat monitor
        3   Session monitor
        4   Nodes monitor
        5   Routes monitor
        6   Status overview
        7   Security monitor
        8   Console 1 (if present)
        9   Console 2 (if present)
        10  Console 3 (if present)
        11  Console 4 (if present)
        12  Console 5 (if present)

</code> **SEE ALSO** <code>
        BOOTCMDS.SYS(8) -- Commands executed at boot up
        XROUTER.CFG(8)  -- Main configuration file

</code>
----
==== CAPTIONCOLOR ====
<code>CAPTIONCOLOR(7)         XROUTER REFERENCE MANUAL            26/10/2023
</code> **NAME** <code>
        CAPTIONCOLOR -- Colour For Captions and Headings.

</code> **SYNOPSIS** <code>
        CAPTIONCOLOR=<colour>

</code> **DESCRIPTION** <code>
        CAPTIONCOLOR is an optional directive that can be used both
        in the "global" section of XROUTER.CFG, and within CONSOLE
        definition blocks.

        It specifies the colour used by XRouter for displaying
        captions, such as those in PING progress reports, and table
        headings, such as those in session lists.

        If used in the "global" section of XROUTER.CFG, the setting
        is inherited by all CONSOLEs subsequently defined.

        If used within a CONSOLE definition block, it applies only
        to that console, overriding any inherited setting.

        The default CAPTIONCOLOR is LIME.  Default colours have
        been carefully chosen for good visibility against a BLACK
        background.

</code> **OPTIONS** <code>
        <colour> should be one of the 16 colour names described in
        COLOURS(6), but please note that some colour combinations
        have very poor visibility.

        In general, the lighter the background colour, the smaller
        the choice of foreground colours that will work with it.

</code> **EXAMPLE** <code>
        CAPTIONCOLOR=CYAN

</code> **SEE ALSO** <code>
        ANSI(1)         -- Enquire/set ANSI colour mode
        COLOURS(6)      -- XRouter Display Colours.
        CONSOLES(6)     -- About XRouter Consoles.
        ACTIONCOLOR(7)  -- Colour For XRouter Actions and Events.
        PROMPTCOLOR(7)  -- Colour For XRouter Prompts.
        WARNCOLOR(7)    -- Colour For warnings and Errors.
        XROUTER.CFG(8)  -- Main Configuration File.

</code>
----
==== CFLAGS ====
<code>CFLAGS(7)               XROUTER REFERENCE MANUAL              4/9/2023
</code> **NAME** <code>
        CFLAGS -- Connection Control Flags.

</code> **SYNOPSIS** <code>
        CFLAGS=n (n = 0 - 255)

</code> **AVAILABILITY** <code>
        Used in PORT configuration blocks within XROUTER.CFG.

</code> **DESCRIPTION** <code>
        CFLAGS is a port configuration keyword, whose primary function
        is to control whether or not AX25 level 2 uplinking and/or
        downlinking is allowed on the port. A command of the same
        name allows the value to be changed on the fly.

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

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

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

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

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

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

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

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

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

</code> **EXAMPLES** <code>
                CFLAGS=2  - Allow downlinking only
                CFLAGS=5  - Allow only sysops and apps to downlink.
  
</code> **FILES** <code>
        xrouter.cfg

</code> **SEE ALSO** <code>
        CFLAGS(1)      -- Display / Set Connection Flags
        L2FRAG(9)      -- AX25 Layer 2 Fragmentation.
        L3RTT(9)       -- Layer 3 Round Trip Time.
        FEC(1)         -- Forward Error Correction.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CHANNEL ====
<code>CHANNEL(7)            XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        CHANNEL -- Channel to Use on Interface.

</code> **SYNOPSIS** <code>
        CHANNEL=<letter A to P>

</code> **DESCRIPTION** <code>
        CHANNEL is an optional PORT configuration directive.

        If present, it specifies the "channel" to use on a multi-
        channel interface.

        It is required only on certain types of interface, e.g.
        KISS. Not required on AXIP, AXUDP, or AXTCP interfaces.

</code> **OPTIONS** <code>
       The argument to CHANNEL is a letter between A and P
       inclusive. The default is channel A. 

</code> **EXAMPLE** <code>
       CHANNEL=C   ; 3rd channel

</code> **SEE ALSO** <code>
        IFACES(6)      -- Interfaces in XRouter.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CHATALIAS ====
<code>CHATALIAS(7)           XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        CHATALIAS -- Alias for Chat Server.

</code> **SYNOPSIS** <code>
        CHATALIAS=<alias>

</code> **DESCRIPTION** <code>
        CHATALIAS is a directive that can be used in XROUTER.CFG,
        both "globally" and within PORT definition blocks.

        It specifies an "alias", i.e. a sort of memorable alternative
        "callsign" for the chat server, e.g. "IOWCHT" (Isle of Wight
        Chat). This can be used interchangeably with the CHATCALL;
        i.e. the chat server will respond to either.

        The <alias> is a string of up to 6 uppercase ASCII characters
        and numbers. It is suggested that it should end with "CHT",
        and begin with something geographically relevant, e.g. BHMCHT
        for Birmingham, LDSCHT for Leeds etc., so it can be easily
        identified in node tables.

        If used "globally", it specifies the "primary" chat alias,
        used for AX25, NetRom and TCP operations. This is also the
        chat server's "identity", as displayed on chat messages.

        Any PORTs declared further down XROUTER.CFG "inherit" this
        alias for AX25 Layer 2 chat server operation on that port,
        UNLESS overridden by the use of CHATALIAS within that PORT's
        definition block.

        If CHATALIAS is used within a PORT definition block, it
        replaces the "global" chat alias for that port only.

</code> **EXAMPLE** <code>
        CHATALIAS=IOWCHT

</code> **CAVEATS** <code>
        Omitting the global CHATALIAS, or setting it IDENTICAL to
        NODEALIAS disables chat server connectivity, but the server
        can still be used "standalone" via the CHAT command.

</code> **SEE ALSO** <code>
        CHAT(1)        -- Start Chat Session.
        CHAT-SRV(9)    -- Chat Server.
        CHATCALL(7)    -- Chat Server Callsign.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CHATCALL ====
<code>CHATCALL(7)            XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        CHATCALL -- Callsign for Chat Server.

</code> **SYNOPSIS** <code>
        CHATCALL=<callsign>

</code> **DESCRIPTION** <code>
        CHATCALL is a directive that can be used in XROUTER.CFG,
        both "globally" and within PORT definition blocks.

        It specifies the AX25/NetRom callsign for the chat server.
        This can be used interchangeably with the CHATALIAS; i.e. the
        chat server will respond to either.

        If used "globally", it specifies the "primary" chat callsign,
        used for AX25 and NetRom operations. This can be the same as
        NODECALL, but must use a different SSID. A SSID of -8 is the
        de-facto standard for XRchat systems.

        Any PORTs declared further down XROUTER.CFG "inherit" this
        callsign for AX25 Layer 2 chat server operation on that port,
        UNLESS overridden by the use of CHATCALL within that PORT's
        definition block.

        If CHATCALL is used within a PORT definition block, it
        replaces the "global" chat callsign for that port only.

</code> **EXAMPLE** <code>
        CHATCALL=G8PZT-8

</code> **CAVEATS** <code>
        Omitting the global CHATCALL, or setting it IDENTICAL to
        NODECALL (including the SSID) disables chat server
        connectivity, but the server can still be used "standalone"
        via the CHAT command.

</code> **SEE ALSO** <code>
        CHAT(1)        -- Start Chat Session.
        CHAT-SRV(9)    -- Chat Server.
        CHATALIAS(7)   -- Chat Server Alias.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CHATPORT ====
<code>CHATPORT(7)             XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        CHATPORT -- TCP Port for CHAT Server.

</code> **SYNOPSIS** <code>
        CHATPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        CHATPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the CHAT server. If not present, the default is 3600.

        The CHAT server, allows groups of users to hold live
        multi-way conversations without having to manage several TNC
        streams at once.

        The CHAT server is also available as NetRomX service 8, plus
        via CHATCALL/CHATALIAS and the CHAT command.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "CHATPORT=3600", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "CHATPORT=3600 3601", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting CHATPORT to zero on a stack prevents TCP connections
        to the chat server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        CHAT-SRV(9)    -- CHAT Server.
        CHAT-SVC(9)    -- NetRomX CHAT Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== COLS ====
<code>COLS(7)                 XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        COLS -- Set Display Width (deprecated).

</code> **SYNOPSIS** <code>
        COLS=n (n = 40-120)

</code> **DESCRIPTION** <code>
        COLS is an optional configuration directive, used only in the
        "global" section of XROUTER.CFG. It sets the display width
        in columns or characters of text.

        The default display width for XRouter is 80 columns, which is
        a legacy from the 80x25 DOS days. With XR32 running in a
        Windows "command" window, this setting allows the use of
        retro "full screen" mode, using the ALT-RETURN key
        combination.

        As XRouter, like most packet systems, is intended for a
        display width of 80 columns, all its responses are designed
        to fit within that width. The only thing that might exceed 80
        columns is monitored traffic, which simply wraps.

        So increasing the display width merely reduces the amount of
        wrapping on monitored data, whilst reducing the width may
        cause wrapping and corruption of displays such as the status
        bar, nodes tables, table headings and so on.

        Whereas Windows resizes the containing window to fit the
        dimensions specified by XRouter, Linux does not. On Linux,
        the width of the containing terminal window must be equal to
        of greater than COLS, otherwise the display is corrupted

        *** Therefore the use of COLS is strongly deprecated ***

        If you really *must* fiddle, use the COLS directive near the
        start of XROUTER.CFG, before any CONSOLE definitions.  As an
        example, for a 90-column display use COLS=90.

</code> **CAVEATS** <code>
        If you set COLS less than 80, the bottom menu bar will be
        corrupt or blank. If you set it less than 79, fields on the
        Route monitor window will wrap. If you set it less than 76,
        the top status bar disappears. If you set it less than 30,
        XRouter will segfault when you exit.

        If you set COLS more than 80, you cannot use "full screen"
        mode on Windows.

</code> **SEE ALSO** <code>
        ROWS(7)        -- Set Display Height.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CONSOLELANG ====
<code>CONSOLELANG(7)          XROUTER REFERENCE MANUAL            29/10/2023
</code> **NAME** <code>
        CONSOLELANG -- Default Language.

</code> **SYNOPSIS** <code>
         CONSOLELANG=<language number>

</code> **DESCRIPTION** <code>
        CONSOLELANG is an optional directive used in XROUTER.CFG.
        
        It can be used globally, and/or in each CONSOLE definition
        block.

        If present, it specifies the default language for console
        operations.

        If not present, the console inherits DEFAULTLANG.

        The language for any session can changed at any time using
        the LANG command.

        If the relevant language file is not present, it has no effect

        <language_number> is as follows:

            0 - English
            1 - French
            2 - Spanish
            3 - German
            4 - Dutch

        You may set each CONSOLE to a different language if you wish,
        but please be aware that the language of the FIRST console is
        the one that is used for all the other windows (chat, nodes,
        routes...) and their help menus etc..

</code> **EXAMPLE** <code>
        CONSOLELANG=2 -- Sets console language to SPANISH

</code> **SEE ALSO** <code>
        CONSOLES(6)    -- About XRouter Consoles.
        DEFAULTLANG(7) -- Default language
        LANGS.SYS(8)   -- Language selection file
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== CONTACT ====
<code>CONTACT(7)             XROUTER REFERENCE MANUAL              20/9/2023

</code> **NAME** <code>
        CONTACT -- Sysop's contact details.

</code> **SYNOPSIS** <code>
        CONTACT=<email / website / packet / phone etc>

</code> **DESCRIPTION** <code>
        CONTACT is an optional directive, used in XROUTER.CFG. If
        present, it specifies an email or packet address, phone
        number, or web site etc, to be sent to the mapping server.

        Although not currently displayed on the map, this data may
        eventually be used to allow sysops to contact each other,
        or for the map server owner to contact you in the event of
        problem.

        Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's
        association between callsigns and IP addresses. The mapping
        server displays nodes and links on a MAP.

        CONTACT may be used (once only) anywhere in the "global"
        section of XROUTER.CFG.

</code> **EXAMPLES** <code>
        CONTACT=g9dum@wmpkt.org
        CONTACT=www.wmpkt.org/contacts
        CONTACT=PO Box 43, Dudley,West Midlands

</code> **SEE ALSO** <code>
        MAPCOMMENT(7)  -- Short text to display on map.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CTEXT ====
<code>CTEXT(7)               XROUTER REFERENCE MANUAL               4/9/2023
</code> **NAME** <code>
        CTEXT -- Set "Connect Text".

</code> **SYNOPSIS** <code>
        CTEXT
        <text>
        ***
        CTEXT=<text>

</code> **DESCRIPTION** <code>
        The CTEXT directive, used in XROUTER.CFG, specifies a
        "connect text", which is a single or multi-line text that
        can be sent to a caller when they connect to XRouter.

        The directive has two possible forms, one for specifying the
        "global" CTEXT, the other for specifying a port-specific one. 

        The companion directive CTFLAGS controls which callers
        receive the text.

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

        The GLOBAL connect text is specified in a multi-line block
        which starts with CTEXT and ends with a line containing only
        "***", like this:

             CTEXT
             This is the first line if the connection text
             This is the second line
             And so on
             ***

        A PORT connection text is specified *differently*. The
        following form is used within a PORT definition block:

             CTEXT=Single line of text, or a filename

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

        In PORT blocks only, if <text> specifies a filename, the
        contents of that file are read "live" every time someone
        connects, which may be of use in EMCOMM scenarios. The
        specified file could for instance be updated by another
        program, such as an extreme weather detector.

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

            CTEXT ctext-news.txt
            CTEXT /etc/weather/latest.txt

        The CTEXT *command* allows the texts to be changed "on the
        fly".

</code> **SEE ALSO** <code>
        CTEXT(1)       -- Display / Set Connection Text.
        CTFLAGS(1)     -- Display / Set Connection Text Flags
        CTFLAGS(7)     -- Connection Text Control Flags.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== CTFLAGS ====
<code>CTFLAGS(7)             XROUTER REFERENCE MANUAL               4/9/2023
</code> **NAME** <code>
        CTFLAGS -- Connection Text Control Flags.

</code> **SYNOPSIS** <code>
        CTFLAGS=n (where n is 0-15)

</code> **DESCRIPTION** <code>
        The CTFLAGS directive, used in XROUTER.CFG, controls which
        callers are sent a "connect text" when they connect to
        XRouter.

        If CTFLAGS is used in the GLOBAL section of XROUTER.CFG, its
        value is "inherited" by any PORTs that are subsequently
        defined.

        If used within a PORT block, the value overrides the global
        value, for that port only.

        The argument is the sum of the desired options from the
        following list (only options 1 and 2 are valid in a PORT):

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

        The default value is 9 (Alias and Telnet only).

</code> **NOTE** <code>
        The CTFLAGS *command* allows the texts to be changed "on the
        fly".

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

</code>
----
==== CWID ====
<code>CWID(7)               XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        CWID -- Morse Code Identification.

</code> **SYNOPSIS** <code>
        CWID=<callsign>

</code> **DESCRIPTION** <code>
        CWID is an optional PORT configuration directive, which is
        valid only for SCC ports at present. 

        It specifies a callsign to be sent every 30 minutes using
        Morse code. If omitted, no cwid is sent.

</code> **OPTIONS** <code>
        The <callsign> consists of up to 8 characters. Only upper
        case alphanumeric characters and forward slash (/) are
        acceptable.

</code> **EXAMPLES** <code>
        CWID=GB7PZT
        CWID=G8PZT/M

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DEFAULTLANG ====
<code>DEFAULTLANG(7)           XROUTER REFERENCE MANUAL             4/9/2023
</code> **NAME** <code>
        DEFAULTLANG -- Default Language.

</code> **SYNOPSIS** <code>
         DEFAULTLANG=<language number>

</code> **DESCRIPTION** <code>
        DEFAULTLANG is an optional directive used in XROUTER.CFG.

        If present, it specifies the default language for all
        sessions that are NOT assigned a language by entries in
        LANGS.SYS.

        If DEFAULTLANG is not present, the default language is
        English.

        The setting is inherited by all CONSOLES, but it can be
        overridden by CONSOLELANG, either globally or in each CONSOLE
        definition block.

        The language for any session can changed at any time using
        the LANG command.

        If the relevant language file is not present, it has no effect

        <language_number> is as follows:

            0 - English
            1 - French
            2 - Spanish
            3 - German
            4 - Dutch

</code> **EXAMPLE** <code>
        DEFAULTLANG=1 -- Sets default language to FRENCH

</code> **SEE ALSO** <code>
        CONSOLELANG(7) -- Console language
        LANGS.SYS(8)   -- Language selection file
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== DHCP ====
<code>DHCP(7)              XROUTER REFERENCE MANUAL                24/9/2023

</code> **NAME** <code>
        DHCP -- Obtain Port IP Using DHCP.

</code> **SYNOPSIS** <code>
        DHCP=n (where n is 0 or 1)

</code> **DESCRIPTION** <code>
        DHCP is an optional PORT configuration directive.

        If present, it specifies whether or not the port IP address
        should be obtained dynamically using DHCP (DHCP=1) or
        specified statically (DHCP=0). The default is 0. 

</code> **SEE ALSO** <code>
        DHCP(1)        -- Display DHCP-obtained IP configuration.
        DHCP(9)        -- Dynamic Host Configuration Protocol.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DIGIFLAG ====
<code>DIGIFLAG(7)            XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        DIGIFLAG -- Digipeating Options.

</code> **SYNOPSIS** <code>
        DIGIFLAG=n (where n is a number from 0 to 1023)

</code> **DESCRIPTION** <code>
        DIGIFLAG is an optional PORT configuraton directive which
        controls digipeating on that port. (0=none, default=7).

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

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

</code> **EXAMPLE** <code>
        DIGIFLAG=5      ; Digipeat UI + RELAY generic.

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

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

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

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

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

        Not everyone agrees with the "New Paradigm, so the choice of
        which features to enable is left you you.
 
</code> **SEE ALSO** <code>
        DIGIFLAG(1)    -- Display / Set digipeat options.
        DIGIPORT(7)    -- Destination Port for Digipeating.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DIGIPORT ====
<code>DIGIPORT(7)            XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        DIGIPORT -- Destination Port for Digipeated Frames.

</code> **SYNOPSIS** <code>
        DIGIPORT=<port_number>

</code> **DESCRIPTION** <code>
        DIGIPORT is an optional directive used in PORT configuration
        blocks within XROUTER.CFG.

        It specifies the port number on which digipeated frames are
        transmitted. The default is 0, i.e. the current port.

</code> **EXAMPLE** <code>
        DIGIPORT=3   ; Digipeat from this port onto port 3 

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

</code> **SEE ALSO** <code>
        BCAST(9)       -- One to many digipeating
        DIGIPORT(1)    -- Display / Set port to digipeat on.
        DIGIFLAG(7)    -- Digipeating Options.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DISCARDPORT ====
<code>DISCARDPORT(7)         XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        DISCARDPORT -- TCP Port for DISCARD Server.

</code> **SYNPOSIS** <code>
        DISCARDPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        DISCARDPORT is an optional GLOBAL configuration directive
        used in XROUTER.CFG.

        If present, it specifies the TCP "service port" number for
        the DISCARD server. If not present, the default is 9.
 
        The DISCARD server is a "sink" session, whereby XRouter
        ignores (discards) everything sent to it.  This is a useful
        tool for testing connections, throughput etc.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "DISCARDPORT=99", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "DISCARDPORT=99 9999",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting DISCARDPORT to zero on a stack prevents TCP
        connections to the server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        DISC-SRV(9)    -- Discard Server.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DXFLAGS ====
<code>DXFLAGS(7)              XROUTER REFERENCE MANUAL              6/9/2023
</code> **NAME** <code>
        DXFLAGS -- DX List Control Flags.

</code> **SYNOPSIS** <code>
        DXFLAGS=n (where n is a decimal number)

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

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

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

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

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

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

</code> **CAVEATS** <code>
        If XRouter's position has not been defined, the program will
        not start.
        
</code> **SEE ALSO** <code>
        DX(1)          -- Show Distant Stations
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== DYNDNS ====
<code>DYNDNS(7)             XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        DYNDNS -- Enable / Disable Dynamic DNS Update Client.

</code> **SYNOPSIS** <code>
        DYNDNS=<0|1>

</code> **DESCRIPTION** <code>
        DYNDNS is an optional PORT configuration directive, used in
        XROUTER.CFG.

        It specifies whether or not the dynamic DNS update client is
        active on that port (1=active 0=not active).

        This is a relic from XR16 (DOS XRouter), when almost no-one
        had domestic Internet routers. It may be of little use now
        most home routerc havetheir own dynamic DNS client.

</code> **CAVEATS** <code>
        This directive most only be used on ONE port. It may crash
        XRouter if you try to use it on more than one.

</code> **SEE ALSO** <code>
        DYNDNS(9) -- Dynamic DNS Update Client
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== ECHOPORT ====
<code>ECHOPORT(7)             XROUTER REFERENCE MANUAL              6/9/2023
</code> **NAME** <code>
        ECHOPORT -- TCP Port for ECHO Server.

</code> **SYNOPSIS** <code>
        ECHOPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        ECHOPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the ECHO server. If not present, the default is 7.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "ECHOPORT=7777", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "ECHOPORT=7777 8888", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting ECHOPORT to zero on a stack prevents TCP connections
        to the server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        ECHO(1)        -- Start an Echo session.
        ECHO-SRV(9)    -- Echo server.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== EXCLUDE ====
<code>EXCLUDE(7)            XROUTER REFERENCE MANUAL               24/9/2023

</code> **COMMAND** <code>
        EXCLUDE -- AX25 Blacklist.

</code> **SYNOPSIS** <code>
        EXCLUDE=<callsign>[,<callsign>...]

</code> **DESCRIPTION** <code>
        EXCLUDE is an optional directive used in XROUTER.CFG.

        It specifies a list of one or more callsigns from whom AX25
        frames are ignored, and is this the opposite of VALIDCALLS.

.       It would typically be used on a user-access port to prevent
        connections from trouble-makers, pirates or other nodes,
        e.g. for preventing CB nodes from interconnecting with ham
        radio nodes and vice versa.

        If used within the "global" section of XROUTER.CFG, the
        exclusion is "inherited" by any PORTs subsequently defined.

        If used within a PORT definition block, the exclusion applies
        to that port only.

        Multiple callsigns must be separated by commas, and the list
        must not include any spaces.

        Exclusions can be changed during run-time using the EXCLUDE
        command.

</code> **EXAMPLE** <code>
        EXCLUDE=NOCALL,P1RAT ; Ignore these users 

</code> **SEE ALSO** <code>
        EXCLUDE(1)     -- AX25 L2 exclusion command
        L3EXCLUDE(7)   -- NetRom Layer 3 exclusions
        PORTS(6)       -- Ports in XRouter.
        VALIDCALLS(7)  -- AX25 Whitelist.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FEC ====
<code>FEC(7)                XROUTER REFERENCE MANUAL               24/9/2023
</code> **NAME** <code>
        FEC -- Enable / disable Forward Error Correction.

</code> **SYNOPSIS** <code>
        FEC=<0|1>

</code> **DESCRIPTION** <code>
        FEC is an optional PORT configuration directive, used in
        XROUTER.CFG.

        It controls whether or not Reed-Solomon Forward Error
        Correction is enabled on that port.

        In order to make use of FEC, the port needs to be using a
        KISS TNC with the CRC check disabled (PASSALL ON), an SCC
        card or YAM modem. The default is 0, i.e. disabled. 

        Forward error correction is useful on links with high BER
        (bit-error-rates). Up to 8 erroneous bytes per frame may be
        automatically corrected, at the expense slightly larger
        frames. FEC is not required on links with very low BER.
        FEC is normally disabled by default, and is enabled by
        including the FEC=1 directive in the appropriate PORT
        configuration block in XROUTER.CFG. It can then be turned
        on and off at will from the command line.

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

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

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

</code> **SEE ALSO** <code>
        FEC(1)         -- Control Forward Error Correction.
        CFLAGS(7)      -- Connection Control Flags.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FINGERPORT ====
<code>FINGERPORT(7)           XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        FINGERPORT -- TCP Port for FINGER Server.

</code> **SYNOPSIS** <code>
        FINGERPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        FINGERPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the FINGER server. If not present, the default is 79.

        The FINGER server allows users to "put a finger on" (i.e.
        find information about) other users. 

        The server is also available on NetRomX service 79.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "FINGERPORT=79", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "FINGERPORT=79 89", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting FINGERPORT to zero on a stack prevents TCP connections
        to the finger server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

        FINGER is expected to be on port 79. If you "move" the finger
        port, other people's finger clients will not be able to
        connect to your server. This directive is provided ONLY for
        controlling availablity on each stack.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        FING-SRV(9)  -- FINGER server.
        FING-SVC(9)  -- NetRomX FINGER Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FRACK ====
<code>FRACK(7)              XROUTER REFERENCE MANUAL               26/9/2023
 
</code> **NAME** <code>
        FRACK -- AX25 Frame Acknowledgement Time.

</code> **SYNOPSIS** <code>
        FRACK=<milliseconds>

</code> **DESCRIPTION** <code>
        FRACK is an optional PORT configuration directive, used in
        XROUTER.CFG.

        If present, it specified the AX25 "T1" timeout, i.e. FRame
        ACKnowledgement time in milliseconds. If not present, the
        default FRACK is 7000. The value can be changed during run-
        time using the FRACK command.

        After sending an AX25 packet, FRACK is the amount of time
        XRouter will wait for an "ack" before considering the packet
        to be lost.

        The T1 timer starts when the link layer dispatches the packet
        to the MAC (Media Access Control) layer, so you must allow at
        least enough time for (MAXFRAME * PACLEN) packets to be sent,
        plus an ack packet to be received, plus the other end's
        RESPTIME, plus both end's TXDELAYs, plus a generous allowance
        for channel congestion.

        A frack no less than 7000 millisecs is recommended for
        average 1200 baud simplex RF links. Setting this figure too
        low is antisocial, achieves nothing, wastes airtime, and
        could result in the link retrying out.

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

</code> **EXAMPLE** <code>
        FRACK=7000 ; 7 seconds

</code> **SEE ALSO** <code>
        FRACK(1)       -- Display / Set FRACK for a port.
        MAXFRAME(7)    -- Maximum Unacked Frames.
        PACLEN(7)      -- Maximum Packet Length.
        PORTS(6)       -- Ports in XRouter.
        RESPTIME(7)    -- AX25 Delayed Ack Time.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FREQUENCY ====
<code>FREQUENCY(7)           XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        FREQUENCY -- Radio frequency used by RF port.

</code> **SYNOPSIS** <code>
        FREQUENCY=<radio frequency in Hz>

</code> **DESCRIPTION** <code>
        FREQUENCY is an optional directive that may be used anywhere
        in a PORT block within XROUTER.CFG. If present, it specifies
        the radio frequency in Hz.

        If the port is a radio port, this value is reported to the
        node mapping server, if reporting is enabled.

        There are some port types (e.g. AXUDP) where this directive
        is meaningless. 

        In a RADIO control block, this specifies the transmit and
        receive frequency if simplex, or the receive frequency if
        duplex.

</code> **EXAMPLE** <code>
        FREQUENCY=144925000 -- 144.925 MHz

</code> **SEE ALSO** <code>
        RADIO(7)       -- Rig control block
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FTPPORT ====
<code>FTPPORT(7)              XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        FTPPORT -- TCP Port for FTP Server.

</code> **SYNOPSIS** <code>
        FTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        FTPPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the FTP server. If not present, the default is 21.

        The FTP server is mainly intended for use by sysops.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "FTPPORT=21", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "FTPPORT=21 31", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting FTPPORT to zero on a stack prevents TCP connections
        to the server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        FTP-SRV(9)     -- FTP server.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== FULLDUP ====
<code>FULLDUP(7)            XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        FULLDUP -- Full Duplex.

</code> **SYNOPSIS** <code>
        FULLDUP=<0|1>

</code> **DESCRIPTION** <code>
        FULLDUP is an optional PORT directive, used in XROUTER.CFG.

        If FULLDUP=1, it allows simultaneous TX/RX, the DCD is
        ignored and the hardware will transmit whenever it has
        anything to send, without waiting for the other end to stop.

        The default is 0 (simplex / half duplex).

        Used only by hardware which is capable of simultaneous
        transmission and reception, such as full duplex radio or
        wire links, KISS TNCs, SCC cards, and YAM modems.. 

</code> **EXAMPLE** <code>
        FULLDUP=1    ; Full duplex 

</code> **SEE ALSO** <code>
        FULLDUP(1)     -- Display / Set full duplex mode.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== HAAT ====
<code>HAAT(7)                XROUTER REFERENCE MANUAL              20/9/2023

</code> **NAME** <code>
        HAAT -- Antenna Height Above Average Terrain.

</code> **SYNOPSIS** <code>
        HAAT=<metres>

</code> **DESCRIPTION** <code>
        HAAT is an optional directive that may be used anywhere in
        the "global" section of XROUTER.CFG. If present, it
        specifies the height of the antenna in metres above
        "average terrain". This is a value widely used in APRS to
        estimate the radio range.

        The value is obtained by calculating the average terrain
        heights along a series of typically 10 or 20 "radials" from
        the site, then averaging those values. If there are
        surrounding hills, it is not uncommon for the HAAT to be
        negative.

        There is a calculator on the FCC website that allows you to
        easily calculate your HAAT.

        At present the HAAT is only displayed on the HTML "info"
        page, but it might eventually be sent to the mapping server.

</code> **EXAMPLES** <code>
        HAAT=-15 -- Antenna is 15 metres BELOW averaged terrain.
        HAAT=12  -- Antenna is 12 metres ABOVE avareaged terrain. 
</code> **NOTE** <code>
        Although HAAT is currently a "global" parameter, it is
        acknowledged that some PORTS may have antennas at different
        heights. Therefore a per-port override will be added in a
        future version.

</code> **SEE ALSO** <code>
        ALTITUDE(7)    -- Base height of site.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== HTTPPORT ====
<code>HTTPPORT(7)             XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        HTTPPORT -- TCP Port for HTTP Server.

</code> **SYNOPSIS** <code>
        HTTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        HTTPPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the HTTP server. If not present, the default is 80.

        The HTTP server serves HTML files and provides a browser-
        -based user/sysop interface to XRouter.

        The server is also available via NetRomX service 80.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "HTTPPORT=80", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "HTTPPORT=80 8080", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting HTTPPORT to zero on a stack prevents TCP connections
        to the HTTP server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        HTTP-SRV(9)    -- HTTP server.
        HTTP-SVC(9)    -- NetRomX HTTP Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== ID ====
<code>ID(7)                XROUTER REFERENCE MANUAL                24/9/2023

</code> **NAME** <code>
        ID -- Text to Identify Port.

</code> **SYNOPSIS** <code>
        ID=<descriptive text>

</code> **DESCRIPTION** <code>
        ID is a *mandatory* PORT directive used in XROUTER.CFG.

        It specifies a text to identify the port on the "PORTS"
        display. It may contain spaces. Please make it informative.

</code> **EXAMPLE** <code>
        ID=144.825 MHz 9k6 TCP/IP users 

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IDINTERVAL ====
<code>IDINTERVAL(7)           XROUTER REFERENCE MANUAL            22/10/2023
</code> **NAME** <code>
        IDINTERVAL -- Identification Beacon Interval.

</code> **SYNOPSIS** <code>
        IDINTERVAL=<minutes>

</code> **DESCRIPTION** <code>
        IDINTERVAL is an optional GLOBAL configuration directive
        used in XROUTER.CFG.

        If present, it specifies the interval in minutes between
        broadcasts of IDTEXT (the ID beacon) on each port.

        The default is 15 (minutes).

        A setting of 0 disables ID beacons.

</code> **SEE ALSO** <code>
        IDPATH(7)      -- Identification Beacon Path
        IDTEXT(7)      -- Identification Beacon Text.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IDPATH ====
<code>IDPATH(7)             XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        IDPATH -- Destination and Digipeater Path for ID beacons.

</code> **SYNOPSIS** <code>
        IDPATH=<destination>[,digipeater,digipeater...]

</code> **DESCRIPTION** <code>
        IDPATH is an optional PORT configuraton directive, used in
        XROUTER.CFG.

        If present, it specifies the AX25 destination and optional
        digipeater path for routine "ID" (identification) beacons.

        The default AX25 destination and path is "ID" with no
        digipeaters. You may wish to modify this, for example on
        APRS ports, to digipeat your beacon.

        The part can be changed during run-time using the IDPATH
        command.

</code> **EXAMPLE** <code>
        IDPATH=APRS,RELAY,WIDE 

</code> **SEE ALSO** <code>
        IDINTERVAL(7)  -- Identification Beacon Interval
        IDPATH(1)      -- Display / Set ID Path
        IDTEXT(7)      -- Identification Beacon
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IDTEXT ====
<code>IDTEXT(7)             XROUTER REFERENCE MANUAL               24/9/2023

</code> **NAME** <code>
        IDTEXT -- Identification Text.

</code> **SYNOPSIS** <code>
        IDTEXT        }
        <text>        } "global" idtext
        ***           }
        IDTEXT=<text>    <-- "port" idtext

</code> **DESCRIPTION** <code>
        IDTEXT is a configuration directive that can be used both
        "globally" and within PORT definition blocks in XROUTER.CFG.

        It specifies a single line of text to be broadcast via AX25
        every IDINTERVAL, to a destination path specified by IDPATH.

        If used within the "global" section of XROUTER.CFG, the value
        is "inherited" by any PORTs defined further down, UNLESS
        there is an IDTEXT in that PORT block.

        If used in a PORT block, IDTEXT overrides the "global" value,
        on that port only. 

        The <text> is specified differently for the global and port
        cases. In the global case, IDTEXT begins a 3 line block,
        with <text> on the second line and "***" on the third line,
        which is a BPQ legacy. In a PORT block, <text> is specified
        using a single line.

        Only one line of text (248 characters max.) may be specified.

        The text may be changed during run-time using the IDTEXT
        command.

</code> **NOTE** <code>
        If the global <text> includes and APRS-format static position
        code, starting within the first 40 characters, XRouter will
        be visible on APRS maps and the MHeard function will record
        distances to heard stations, if they are broadcasting their
        positions. The position code format is "!ddmm.mmN/dddmm.mmE"
        where dd represents degrees of latitude or longitude and
        mm.mm represents minutes to two decimal places. "N" and "E"
        may be replaced by "S" and "W" as appropriate. It is highly
        recommended that you include your position,

</code> **EXAMPLE** <code>
        IDTEXT=!5224.00N/00215.00W# (Kidder)

</code> **SEE ALSO** <code>
        IDINTERVAL(7)  -- Identification Beacon Interval
        IDPATH(7)      -- Identification Beacon Path
        IDTEXT(1)      -- Display / Set Identification Beacon
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== INITSTR ====
<code>INITSTR(7)            XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        INITSTR -- Modem Initialisation String.

</code> **SYNOPSIS** <code>
        INITSTR=<string of text>

</code> **DESCRIPTION** <code>
        INITSTR is an optional PORT configuration directive used in
        XROUTER.CFG.

        It specifies a "modem initialisation string", which is a
        string of characters sent to the modem when Xrouter is
        started  (modem ports only).

</code> **EXAMPLE** <code>
        INITSTR=ATM0 

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== INTERFACENUM ====
<code>INTERFACENUM(7)          XROUTER REFERENCE MANUAL            25/9/2023

</code> **NAME** <code>
        INTERFACENUM -- Interface Number.

</code> **SYNOPSIS** <code>
        INTERFACENUM=<interface_number>

</code> **DESCRIPTION** <code>
        INTERFACENUM is a *mandatory* PORT configuration directive,
        used in XROUTER.CFG.

        It specifies the number of the INTERFACE that the port is
        bound (attached) to.

</code> **EXAMPLE** <code>
        PORT=7
          INTERFACENUM=5     ; Port is attached to interface 5
          MTU=256
        ENDPORT

</code> **SEE ALSO** <code>
        IFACES(6)      -- Interfaces in XRouter.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== INTERLOCK ====
<code>INTERLOCK(7)            XROUTER REFERENCE MANUAL             25/9/2023

</code> **NAME** <code>
        INTERLOCK -- Transmitter Interlock.

</code> **SYNOPSIS** <code>
        INTERLOCK=<number>

</code> **DESCRIPTION** <code>
        INTERLOCK is an optional PORT configuration directive, used
        in XROUTER.CFG.

        If a non-zero INTERLOCK value is specified, no two ports with
        the same interlock number will transmit at the same time.

        Note that this is not necessarily a port number (although it
        could be), it is just a number that is common to a group of
        ports that are not allowed to transmit at the same time, for
        example because they all share one power supply.

        If not specified, the default is 0.

        Used only by SCC cards, because KISS TNC's make their own
        decisions about when to transmit, and XRouter has no control
        over that process.

</code> **EXAMPLE** <code>
        INTERLOCK=4

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IPADDRESS ====
<code>IPADDRESS(7)          XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        IPADDRESS -- Main or Port IP Address.

</code> **SYNOPSIS** <code>
        IPADDRESS=<ip_address>

</code> **DESCRIPTION** <code>
        IPADDRESS is a directive used in XROUTER.CFG. It can be used
        both "globally" and within a PORT configuration block.

        If used in the "global" section, it specifies the "core" IP
        address, inherited by all ports. If used within a PORT
        definition block, it specifies an additional IP address that
        is used instead of the global IP address for all TCP/IP
        operations on that port.

        The "core" IP address is used as the "inner" address for
        tunneled IP, e.g. for IPIP, IPENCAP, IPUDP etc. If you have
        an AMPRNET address, it is therefore important that you use
        that as the CORE address, and use your private LAN address
        in the approriate PORT block. It doesn't have to be amprnet
        of course - you may wish to establish a private network on
        another address range. 

</code> **EXAMPLE** <code>
        IPADDRESS=44.131.91.5 

</code> **CAVEATS** <code>
        If you set the global IPADDRESS to 0.0.0.0 or leave it
        undefined, *all* IP activity is disabled, including AXUDP,
        AXTCP, AXIP, HTTP, FTP etc on BOTH stacks! This is a
        deliberate security feature (it may be changed in future).

        Therefore at present, if you don't have an amprnet address,
        and you want to use any IP services, it is suggested that you
        set a non-zero dummy IP address such as 10.1.1.1 for the core.

        A common mistake is to use a LAN address for the core IP, and
        amprnet addresses for AXUDP operations. This is very bad
        practice, because it forces the packets to traverse the IP
        stack several times, which is not only ineffficient, but can
        lead to death-loops.

</code> **SEE ALSO** <code>
        IP-STACKS(6)   -- IP Stacks in XRouter.
        IP-PRIMER(9)   -- IP Primer.
        NETMASK(7)     -- Port Subnet Mask.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== IPLINK ====
<code>IPLINK(7)             XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        IPLINK -- Peer Address of a Link.

</code> **SYNOPSIS** <code>
        IPLINK=<ip_address_or_hostname>

</code> **DESCRIPTION** <code>
        IPLINK is a PORT configuration directive used in XROUTER.CFG,
        which is mandatory for AXIP and AXUDP ports. for other types
        of port it has no meaning, and is ignored.

        IPLINK specifies the IP address or hostname of an AXIP or
        AXUDP link partner.

        If the partner has a static IP address, it is more efficient
        to specify the IP address here, otherwise it may be necessary
        to use the hostname.

        A special case, "IPLINK=0.0.0.0" allows the PORT to be used
        in "Multiple-Links-Per-Port" mode, whereby one PORT supports
        several links. In this mode, formal links are specified using
        PEER commands, instead of the usual IPLINK/UDPREMOTE.

        The IPLINK address can be changed during run-time using the
        IPLINK *command*, but a run-time change to or from "0.0.0.0"
        is not allowed.

</code> **EXAMPLES** <code>
        IPLINK=62.51.67.21
        IPLINK=gb7pzt.dyndns.org

</code> **SEE ALSO** <code>
        AXIP(9)        -- AX25-over-IP Tunnelling.
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        IPLINK(1)      -- Display / Set Port IPLINK Address.
        PEER(7)        -- Specify AXIP / AXUDP Link Partner
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== KEEPALIVE ====
<code>KEEPALIVE(7)            XROUTER REFERENCE MANUAL             22/3/2024

</code> **NAME** <code>
        KEEPALIVE -- AXUDP / AXIP Keepalive interval.

</code> **SYNOPSIS** <code>
        KEEPALIVE=<secs>

</code> **DESCRIPTION** <code>
        KEEPALIVE is an optional PORT configuration directive used in
        XROUTER.CFG. It is only used by AXIP and AXUDP ports, and is
        ignored for other types of port.

        If present, KEEPALIVE specifies the interval in seconds
        between the sending of "keep alive" packets to the link
        partner.

        The purpose of keepalive packets is to maintain dynamic NAT
        entries in intermediate routers (including CGNAT), when
        traffic is light. They are not required when static NAT (aka
        "port forwarding") is used, provided the ISP doesn't use
        CGNAT.

        If KEEPALIVE is not specified, or is zero, no keep alive
        packets are sent.

</code> **EXAMPLE** <code>
        KEEPALIVE=120 	; 2 minutes between keepalives 
        
</code> **SEE ALSO** <code>
        AXIP(9)        -- AX25-over-IP Tunnelling.
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        KEEPALIVE(1)   -- Display / Change Keepalive Interval.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== L3EXCLUDE ====
<code>L3EXCLUDE(7)           XROUTER REFERENCE MANUAL             4/9/2023
</code> **NAME** <code>
        L3EXCLUDE -- Level 3 Exclusion List.

</code> **SYNOPSIS** <code>
         L3EXCLUDE=callsign[,callsign,callsign...]

</code> **DESCRIPTION** <code>
        L3EXCLUDE is an optional global XROUTER.CFG directive. If
        present, it specifies a list of callsigns from whom NetRom
        level 3 traffic is blocked or restricted.

        The callsigns to be blocked are the "user" part of the L3
        "user@node" source address.

        In combination with BLEVEL, this can be used to control
        troublesome users. It should only be used in exceptional
        circumstances!

        Depending on the BLEVEL setting, traffic can be disrupted
        by randomly dropping packets to cause L4 retries, or
        blocked altogether.

</code> **EXAMPLE** <code>
        L3EXCLUDE=N3UOO-5,G9ABC

</code> **SEE ALSO** <code>
        BLEVEL(1)      -- L3 Budlist de-rate level command.
        EXCLUDE(1)     -- AX25 L2 exclusion command
        BLEVEL(7)      -- L3 Budlist de-rate level directive.
        EXCLUDE(7)     -- AX25 L2 exclusion directive.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== L4T3 ====
<code>L4T3(7)                XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        L4T3 -- NetRom Layer 4 link check interval.

</code> **SYNOPSIS** <code>
        L4T3=<seconds>

</code> **DESCRIPTION** <code>
        L4T3 is an optional directive, used in XROUTER.CFG. If
        present, it specifies the number of seconds between NetRom
        layer 4 "link check" frames. If not specified, the default
        is (IDLETIME-60) (usually 840 seconds = 14 minutes).

        Setting this to 0 disables the link check.
        
        The purpose of the link check is to detect "failed" links,
        i.e. those where one end has switched off or rebooted, or
        where the routing is no longer viable. Most sessions have
        an inactivity timeout (IDLETIME), but some, such as chat do
        not. Without a link check, those sessions would persist
        forever in the absence of any activity, hogging resources.

</code> **EXAMPLE** <code>
        L4T3=600 -- Set link check interval to 10 minutes

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

</code>
----
==== LATITUDE ====
<code>LATITUDE(7)            XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        LATITUDE -- Set XRouter's geographic latitude

</code> **SYNOPSIS** <code>
        LATITUDE=n  (where n is between -90.0 and 90.0)

</code> **DESCRIPTION** <code>
        LATITUDE is an optional directive, used in XROUTER.CFG. If
        present, it specifies XRouter's geographic latitude.

        LATITUDE is not needed if (a) LOCATOR is specified, or (b) a
        valid APRS position string is present at the start of IDTEXT.
        In either case, LATITUDE is deduced from the supplied values.

        However if LATITUDE and LONGITUDE are supplied and LOCATOR
        isn't, the latter is calculated.
        
        XRouter uses position information to calculate distances and
        directions to other nodes, as displayed in the MHeard and DX
        lists, and to calculate sunrise and sunset times etc. Whilst
        not vital, these things make node-hopping more interesting.
        Therefore XRouter will not run unless some form of position
        is supplied.

        Unless disabled by the sysop, position information is also
        reported to a mapping server, in an attempt to draw a near
        real-time network map.

        Positional precision is left to the sysop. There is rarely a
        need to know EXACTLY where a node is, its approximate
        location being sufficient for most purposes. Latitude is
        currently stored with a MAXIMUM precision of a hundredth of a
        minute, ie around 22 metres, so there is no point trying to
        supply a LATITUDE of greater precision.

        Within reason, a false location may be supplied, but if the
        position is an obvious mismatch for the nodecall, XRouter
        won't run.

</code> **OPTIONS** <code>
        The argument to LATITUDE is a decimal number of degrees
        between -90.0 (South Pole) and 90.0 (North Pole). Note that
        this is DECIMAL DEGREES, not degrees, minutes and seconds.

        Southern latitudes are specified using NEGATIVE numbers. You
        should not append N or S after the number.

</code> **EXAMPLE** <code>
        LATITUDE=52.4     -- An imprecise northern latitude
        LATITUDE=-77.6342 -- A more precise southern latitude 

</code> **SEE ALSO** <code>
        IDTEXT(1)      -- Display / Set ID beacon text
        LOCATOR(7)     -- Maidenhead QTH locator
        LONGITUDE(7)   -- Geographic longitude
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== LEARN ====
<code>LEARN(7)                XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        LEARN -- Learn Unsolicited AX*P Peer Details.

</code> **SYNOPSIS** <code>
        LEARN=1

</code> **DESCRIPTION** <code>
        LEARN is an optional directive that is used only in one type
        of PORT block within XROUTER.CFG.  It enables "learning" of
        AXIP / AXUDP routing information for unsolicited peers, i.e.
        those for whom no PEER statement exists.

        This allows return packets to be routed to the caller for a
        limited time. If the connection is not used for 10 minutes,
        the details are purged. As the normal AX25 T3 "link check"
        interval is 5 minutes, purging only happens after the link
        has been dead for a while.

        LEARN is only valid if the PORT has "IPLINK=0.0.0.0" and is
        attached to an INTERFACE which has "TYPE="AXUDP". Only one
        such PORT can exist, but it can co-exist with "normal" AXIP
        and AXUDP ports, i.e. those which have IPLINK that is not
        "0.0.0.0".

</code> **OPTIONS** <code>
        The argument for LEARN can be either zero or non-zero. The
        former is the default condition if the directive is not
        present. Any non-zero argument enables learning.

</code> **SEE ALSO** <code>
        AD-HOC(9)      -- Ad-Hoc Networking.
        AXIP(9)        -- AX25 over IP
        AXUDP(9)       -- AX25 over UDP
        PEER(7)        -- Specify AXIP / AXUDP Link Partner
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== LOCATOR ====
<code>LOCATOR(7)             XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        LOCATOR -- Maidenhead QTH locator

</code> **SYNOPSIS** <code>
        LOCATOR=LLddLL[dd] (where L is a letter and d is a digit)

</code> **DESCRIPTION** <code>
        LOCATOR is an optional directive, used in XROUTER.CFG. If
        present, it specifies XRouter's Maidenhead QTH locator.

        LOCATOR is not needed if (a) LATITUDE and LONGITUDE are
        specified, or (b) a valid APRS position string is present
        at the start of IDTEXT. In either case, LOCATOR is deduced
        from the supplied values.

        However if LOCATOR is supplied, but LATITUDE and LONGITUDE
        are not, the latter are calculated.
        
        XRouter uses position information to calculate distances and
        directions to other nodes, as displayed in the MHeard and DX
        lists, and to calculate sunrise and sunset times etc. Whilst
        not vital, these things make node-hopping more interesting.
        Therefore XRouter will not run unless some form of position
        is supplied.

        Unless disabled by the sysop, position information is also
        reported to a mapping server, in an attempt to draw a near
        real-time network map.

        Positional precision is left to the sysop. There is rarely a
        need to know EXACTLY where a node is, its approximate
        location being sufficient for most purposes.

        A 6-character LOCATOR puts the node in the middle of a 1KM
        square. An 8 character locator defines a square of 15 secs
        of latitude by 30 secs of longitude.

        Within reason, a false location may be supplied, but if the
        position is an obvious mismatch for the nodecall, XRouter
        won't run.

</code> **OPTIONS** <code>
        The argument to LOCATOR is a 6 or 8 character "Maidenhead"
        locator, e.g. "IO82VJ" or "IO75GH65"

</code> **EXAMPLE** <code>
        LOCATOR=IO82VJ    -- Kidderminster UK

</code> **SEE ALSO** <code>
        IDTEXT(1)      -- Display / Set ID beacon text
        LATITUDE(7)    -- Geographic latitude
        LONGITUDE(7)   -- Geographic longitude
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== LOG ====
<code>LOG(7)                XROUTER REFERENCE MANUAL                6/9/2023
</code> **NAME** <code>
        LOG -- Activity logging options

</code> **SYNOPSIS** <code>
        LOG=n (where n is between 0 and 16383)

</code> **DESCRIPTION** <code>
        The optional LOG directive, used in XROUTER.CFG, controls
        the logging of XRouter activity, such as connections,
        disconnections, errors, user commands etc. If the directive
        is omitted, or is set to 0, no logging is done.

</code> **OPTIONS** <code>
        The argument to LOG is a decimal value between 0 and 16383
        formed by summing the values of the desired options from the
        table below:

          Value    Function
          ---------------------------------------------------
              1    Enable logging to disk
              2    Use CRLF instead of LF line endings
              4    Log session activity
              8    Log TCP/UDP events
             16    Log Netrom layer 4 events
             32    Log IP/ICMP layer events
             64    Log Netrom layer 3/inp3
            128    Log ODN activity.
            256    Log IDS activity to IDS log
            512    Generate PCAP file (use with caution)
           1024    Log daemon process events
           2048    Log AX25 over TCP
           4096    Log AX25 connections etc
           8192    Log interface layer events

</code> **EXAMPLES** <code>
        LOG=7  -- Log session activity, using CRLF line endings
        LOG=65 -- Log Netrom L3 only, using LF line endings
    
</code> **SEE ALSO** <code>
        LOG(1)         -- Activity logging control command
        XROUTER.CFG(8) -- Main configuration file

</code> **LOG(7)                   END OF DOCUMENT** <code>
</code>
----
==== LONGITUDE ====
<code>LONGITUDE(7)           XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        LONGITUDE -- Set XRouter's geographic longitude

</code> **SYNOPSIS** <code>
        LONGITUDE=n  (where n is between -180.0 and 180.0)

</code> **DESCRIPTION** <code>
        LONGITUDE is an optional directive, used in XROUTER.CFG. If
        present, it specifies XRouter's geographic longitude.

        LONGITUDE is not needed if (a) LOCATOR is specified, or (b) a
        valid APRS position string is present at the start of IDTEXT.
        In either case, LONGITUDE is deduced from the supplied values.

        However if LATITUDE and LONGITUDE are supplied, and LOCATOR
        isn't, the latter is calculated.
        
        XRouter uses position information to calculate distances and
        directions to other nodes, as displayed in the MHeard and DX
        lists, and to calculate sunrise and sunset times etc. Whilst
        not vital, these things make node-hopping more interesting.
        Therefore XRouter will not run unless some form of position
        is supplied.

        Unless disabled by the sysop, position information is also
        reported to a mapping server, in an attempt to draw a near
        real-time network map.

        Positional precision is left to the sysop. There is rarely a
        need to know EXACTLY where a node is, its approximate
        location being sufficient for most purposes. Longitude is
        currently stored with a MAXIMUM precision of a hundredth of a
        minute, ie around 22 metres, so there is no point trying to
        supply a LONGITUDE of greater precision.

        Within reason, a false location may be supplied, but if the
        position is an obvious mismatch for the nodecall, XRouter
        won't run.

</code> **OPTIONS** <code>
        The argument to LONGITUDE is a decimal number of degrees
        between -180.0 (far West) and 180.0 (far East). Note that
        this is DECIMAL DEGREES, not degrees, minutes and seconds.

        Western longitudes are specified using NEGATIVE numbers. You
        should not append E or W after the number.

</code> **EXAMPLE** <code>
        LONGITUDE=2.5    -- An imprecise eastern longitude
        LONGITUDE=-5.205 -- A more precise western longitude 

</code> **SEE ALSO** <code>
        IDTEXT(1)      -- Display / Set ID beacon text
        LATITUDE(7)    -- Geographic latitude
        LOCATOR(7)     -- Maidenhead QTH locator
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== MAPCOMMENT ====
<code>MAPCOMMENT(7)          XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        MAPCOMMENT -- Short text to display on map.

</code> **SYNOPSIS** <code>
        MAPCOMMENT=<text string which may contain spaces>

</code> **DESCRIPTION** <code>
        MAPCOMMENT is an optional directive, used in XROUTER.CFG.
        If present, it specifies a short single line of text which
        pops up when someone clicks on the node on the network map.

        The text should be descriptive, but not too long. The
        maximum length accepted by XRouter is around 244 characters,
        but it cannot be guaranteed that the mapping server will
        display a test of that length.

        MAPCOMMENT can be used, once only, anywhere in the "global"
        section of XROUTER.CFG.

</code> **EXAMPLES** <code>
        MAPCOMMENT=XRLin (XRouter for x86 Linux) alpha test node
        MAPCOMMENT=Beacon Hill, Trunking Only

</code> **SEE ALSO** <code>
        CONTACT(7)     -- Sysop's contact details.
        XROUTER.CFG(8) -- Main Configuration File

</code> **MAPCOMMENT(7)               END OF DOCUMENT** <code>
</code>
----
==== MAPSERVADDR ====
<code>MAPSERVADDR(7)          XROUTER REFERENCE MANUAL              6/9/2023

</code> **NAME** <code>
        MAPSERVADDR -- Hostname / IP address of mapping server.

</code> **SYNOPSIS** <code>
        MAPSERVADDR=<ip_address_or_hostname_of_mapping_server>

</code> **DESCRIPTION** <code>
        MAPSERVADDR is an optional directive used in XROUTER.CFG.
        If present, it specifies an alternative address for the
        mapping server, overriding the inbuilt one. It is provided
        only in case the server address changes in future.

        Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's
        association between callsigns and IP addresses. The mapping
        server displays nodes and links on a MAP.

</code> **SEE ALSO** <code>
        MAPCOMMENT(7)  -- Short text to display on map.
        MAPSERVPORT(7) -- TCP port of mapping server
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== MAPSERVPORT ====
<code>MAPSERVPORT(7)         XROUTER REFERENCE MANUAL               6/9/2023

</code> **NAME** <code>
        MAPSERVPORT -- TCP port of mapping server.

</code> **SYNOPSIS** <code>
        MAPSERVPORT=n (where n is between 0 and 65535)

</code> **DESCRIPTION** <code>
        MAPSERVPORT is an optional directive, used in XROUTER.CFG.
        If present, it specifies an alternative TCP port for the
        mapping server, overriding the inbuilt value.

        Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's
        association between callsigns and IP addresses. The mapping
        server displays nodes and links on a MAP.

        This directive is provided only in case the server details
        change in future. Setting it to 0 disables map reporting,
        but we really hope you won't do this - if you are concerned
        about privacy, please consider using a false location, as
        close to your real locations as you feel comfortable with.

</code> **SEE ALSO** <code>
        MAPSERVADDR(7) -- Address of mapping server
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== MAXFRAME ====
<code>MAXFRAME(7)            XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        MAXFRAME -- Maximum Unacked AX25 Frames.

</code> **SYNOPSIS** <code>
        MAXFRAME=n (where n is in the range 1 to 63)

</code> **DESCRIPTION** <code>
        MAXFRAME is an optional PORT configuration directive used in
        XROUTER.CFG.

        It specifies the AX25 "window", i.e. the maximum number of
        unacknowledged frames allowed before the link must stop and
        wait for an ack. The normal range is between 1 and 7,
        although maxframes of up to 63 are allowed on modulo-128
        (EAX25) links. The default value of MAXFRAME is 3.

        The value can be changed during run-time using the MAXFRAME
        command.

</code> **OPTIONS** <code>
        If you set a value between 8 and 63, XRouter will attempt to
        use Modulo-128 (Extended AX25) on outgoing links. If the link
        partner is not capable of Modulo-128, the link will fall-back
        to normal AX25.

        If the port PACLEN is set to 0, XRouter dynamically adapts
        MAXFRAME (and PACLEN) to the link conditions, to maximise
        throughput.

</code> **EXAMPLE** <code>
        MAXFRAME=4 

</code> **SEE ALSO** <code>
        MAXFRAME(1)    -- Display / Set port MAXFRAME value.
        PACLEN(7)      -- Maximum AX25 Packet Length.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MAXHOPS ====
<code>MAXHOPS(7)              XROUTER REFERENCE MANUAL             25/9/2023
</code> **NAME** <code>
        MAXHOPS -- Set Hopcount Horizon.

</code> **SYNOPSIS** <code>
        MAXHOPS=n (n = 0-30)

</code> **AVAILABILITY** <code>
        Used only in XROUTER.CFG.

</code> **DESCRIPTION** <code>
        MAXHOPS is a global and PORT configuration keyword used in
        XROUTER.CFG, and a parameter which can be used in a ROUTE ADD
        command.

        It specifies the maximum accepted hop count for new nodes
        table entries received via INP3 unicasts from neighbours.
        Node information with hop counts that exceed this figure are
        not accepted into the nodes table.  This parameter has no
        effect on data received via conventional NetRom broadcasts.

        MAXHOPS would typically be used to limit the "hop horizon" to
        a smaller value than the default horizon, which is 30.  Like
        MAXTT, it can be used to limit the number of node entries
        that are accepted via a particular port or neighbour.

        For example, the RF purists don't like Internet-routed nodes
        cluttering up their tables, nor do they want traffic to
        "short-circuit" the RF links via tortuous multi-hop Internet
        routes.  In this case, a low MAXHOPS might be used at the
        interface between the RF-based network segment and the
        Internet-based segment, to (a) control the number of Internet
        nodes appearing in the nodes tables of the RF routers, and
        (b) limit the run-length of Internet routes.

        MAXHOPS can be used in 3 places:  If used in the "global"
        section of XROUTER.CFG, it specifies a default value for all
        ports, overriding the default of 30.  If used in a PORT
        configuration block, it overrides the global default.  All
        new routes inherit this value.  Finally the PORT value can be
        overridden for individual routes using by "locking-in" the
        route at the end of XROUTER.CFG, or by a ROUTE ADD command in
        the XRNODES file or at the command prompt. For example:  

                route add g8pzt 5 100 ! 0 0 0 2000 5

        This adds a locked in route to neighbour "g8pzt" on port 5,
        quality 100, with default maxframe, paclen and frack, MAXTT
        of 2000 and MAXHOPS of 5.

        Setting MAXHOPS to 0 will block all received INP3 data.

</code> **CAVEATS** <code>
        Using MAXHOPS to limit the no. of nodes learned via a
        neighbour may fail if the neighbour duplicates the INP3 data
        in NetRom nodes broadcasts.  This may enter nodes which are
        beyond your chosen hop limit into the nodes table and keep
        them refreshed.  The only defence is to ignore data from
        NetRom broadcasts by setting the port QUALITY below MINQUAL,
        or to set the MINQUAL high. Both actions may cause the loss
        of some NetRom-only nodes from the table.

</code> **SEE ALSO** <code>
        INP3(9)        -- InterNode Protocol
        MAXTT(7)       -- Maximum Trip Time.
        MINQUAL(1)     -- Display / Set port Minimum Quality
        QUALITY(1)     -- Display / Modify NetRom Quality.
        ROUTES(1)      -- Display / Modify NetRom Neighbour Routes.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MAXLINKS ====
<code>MAXLINKS(7)             XROUTER REFERENCE MANUAL            24/10/2023
</code> **NAME** <code>
        MAXLINKS -- Maximum Simultaneous AX25 L2 links.

</code> **SYNOPSIS** <code>
        MAXLINKS=n (n=0-65535)

</code> **DESCRIPTION** <code>
        MAXLINKS is an optional directive used in the "global"
        section of XROUTER.CFG.

        It specifies the maximum number simultaneous AX25 L2 links
        that XRouter can accommodate. (default=30)

        You should set this large enough to accommodate the total
        number of AX25 L2 users and internode links that you expect,
        but not too large because it reserves a block of memory for
        each link.

</code> **EXAMPLE** <code>
        MAXLINKS=50

</code> **SEE ALSO** <code>
        SESSLIMIT(7)   -- Maximum Simultaneous Connections on Port.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MAXTT ====
<code>MAXTT(7)               XROUTER REFERENCE MANUAL              25/9/2023
</code> **NAME** <code>
        MAXTT -- Maximum Trip Time.

</code> **SYNOPSIS** <code>
        MAXTT=n (n = 0-60000)

</code> **AVAILABILITY** <code>
        Used only in XROUTER.CFG.

</code> **DESCRIPTION** <code>
        MAXTT is a global and PORT configuration keyword used in
        XROUTER.CFG, and a parameter which can be used in a ROUTE ADD
        command.

        It defines the maximum accepted "trip time" (transit time) for
        new nodes table entries received via INP3 unicasts from
        neighbours.  Node information with trip times that exceed this
        figure are not accepted into the nodes table.  This parameter
        has no effect on data received via conventional NetRom nodes
        broadcasts.

        MAXTT would typically be used to limit the "trip time horizon"
        to a smaller value than the default horizon, which is 60000
        (600 seconds).  Like MAXHOPS, it can be used to limit the
        number of node entries that are accepted via a particular port
        or neighbour.

        For example, if an RF user lists a moderately sized nodes
        table via an average 1200 baud RF link, it could take several
        minutes to download the data.  It becomes impractical to use
        the "N" commands in that situation.  Experience has shown that
        a nodes table with more than 150 entries is impractical for RF
        users.  Since Internet-based routers have low trip times to
        everywhere, they tend to have very large nodes tables.  Thus
        routers on the Internet<>RF interface, and their RF
        neighbours, would also have over-sized tables, comprised
        mainly of Internet-routed nodes.  Many of these nodes are in
        foreign-language countries of no interest to the RF user.  The
        sysop may choose to limit the horizon to reduce the number of
        Internet nodes in the table.

        Alternatively (and more likely since there are so few RF nodes
        nowadays), a sysop may decide that nodes with trip times of
        more than 10 seconds are too slow, and not worth having in
        the table, and would therefore set a MAXTT of 1000.

        MAXTT can be used in 3 places:  If used in the "global"
        section of XROUTER.CFG, it specifies a default value for all
        ports, overriding the default of 60000.  If used in a PORT
        configuration block, it overrides the global default.  All
        new routes inherit this value.  Finally the port default can
        be overridden for individual routes using by "locking-in" the
        route at the end of XROUTER.CFG, or by a ROUTE ADD command in
        the XRNODES file or at the command prompt. For example:  

                ROUTE ADD g8pzt 5 100 ! 0 0 0 2000 5

        This adds a locked in route to neighbour "g8pzt" on port 5,
        quality 100, with default maxframe, paclen and frack, MAXTT
        of 2000 and MAXHOPS of 5.

        Setting a route's MAXTT to 0 effectively blocks all INP3
        activity.  It disables INP3 unicasts, and ignores received
        INP3.  This is not recommended, but NetRom purists may wish
        to do it anyway.

</code> **CAVEATS** <code>
        Using MAXTT to limit the no. of nodes learned via a neighbour
        may fail if the neighbour duplicates the INP3 data in
        conventional NetRom nodes broadcasts.  This may enter nodes
        which are beyond your chosen trip time horizon into the nodes
        table and keep them refreshed.  The only defence is to ignore
        data from NetRom broadcasts by setting the port QUALITY below
        MINQUAL, or to set the MINQUAL high.  Both actions may cause
        the  loss of some NetRom-only nodes from the table.

</code> **SEE ALSO** <code>
        INP3(9)        -- InterNode Protocol
        MAXHOPS(7)     -- Maximum Hop Count.
        MINQUAL(1)     -- Display / Set port Minimum Quality
        QUALITY(1)     -- Display / Modify NetRom Quality.
        ROUTES(1)      -- Display / Modify NetRom Neighbour Routes.
        XRNODES(8)     -- Nodes / Routes Recovery File.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MHEARD ====
<code>MHEARD(7)             XROUTER REFERENCE MANUAL               21/9/2023
</code> **NAME** <code>
        MHEARD -- Enable MHeard & set size.

</code> **SYNOPSIS** <code>
        MHEARD=<size> (where <size> is a number between 0 and 50)

</code> **DESCRIPTION** <code>
        MHEARD is an optional directive which may be used in PORT
        defininition blocks in XROUTER.CFG. If present, it specifies
        the MHEARD size for that port.

        Specifying a <size> of zero, or omitting the directive,
        disables MHEARD on that port.

        The maximum size is currently 50 slots, to discourage the
        sending of ridiculously long MHeard lists on congested RF
        channels. If you have a requirement for more, please say so.

        The size of the MHeard list may be changed during run-time
        using the MHSIZE command.

</code> **EXAMPLES** <code>
        MHEARD=10 ; Enable MHeard, 10 callsigns max
        MHEARD=0  ; Disable MHeard

</code> **SEE ALSO** <code>
        MHCLEAR(1)     -- Clear MHeard list.
        MHEARD(1)      -- List recently heard stations.
        MHFLAGS(1)     -- Display / Set MHeard options.
        MHSIZE(1)      -- Adjust size of MHeard list.
        MHFLAGS(7)     -- MHeard option flags directive.
        XROUTER.CFG(8) -- Main Configuration File.
        MHEARD(9)      -- About "Monitor Heard".

</code>
----
==== MHFLAGS ====
<code>MHFLAGS(7)            XROUTER REFERENCE MANUAL              18/10/2023
</code> **NAME** <code>
        MHFLAGS -- MHeard option flags.

</code> **SYNOPSIS** <code>
        MHFLAGS=n (where n is a number between 0 and 255)

</code> **DESCRIPTION** <code>
        MHFLAGS is an optional directive which may be used in PORT
        defininition blocks in XROUTER.CFG. If present, it specifies
        the MHEARD options for that port.  These flags control
        which callsigns are recorded in the MHeard list.

        The settings may be changed suring run-time using the
        MHF[lags] command.

</code> **OPTIONS** <code>
        The argument to MHFLAGS is the sum of the required options
        from this list:
 
           1   Record directly heard stations
           2   Record directly heard digipeaters
           4   Record digipeated stations
           8   Record direct/digipeated separately for each station
          16   Preserve MHeard list across reboots.

        The default is 255 (record everything).

</code> **EXAMPLES** <code>
        MHFLAGS=3 ; Directly heard stations & digipeaters only
        MHFLAGS=4 ; Digipeated stations only

</code> **SEE ALSO** <code>
        MHCLEAR(1)     -- Clear MHeard list.
        MHEARD(1)      -- List recently heard stations.
        MHFLAGS(1)     -- Display / Set MHeard options.
        MHSIZE(1)      -- Adjust size of MHeard list.
        MHEARD(7)      -- MHeard size/enable directive
        XROUTER.CFG(8) -- Main Configuration File.
        MHEARD(9)      -- About "Monitor Heard".

</code>
----
==== MINQUAL ====
<code>MINQUAL(7)             XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        MINQUAL -- Minimum Quality to Add to Nodes Table.

</code> **SYNOPSIS** <code>
        MINQUAL=n (where n is in the range 0 to 255)

</code> **DESCRIPTION** <code>
        MINQUAL is an optional global and PORT directive used in
        XROUTER.CFG.

        It specifies the minimum Net/rom "quality" a node must
        have, in order to be accepted into the nodes table.

        The "global" MINQUAL is inherited by all PORTs subsequently
        defined, unless explicitly overridden by a port MINQUAL.

        When "nodes" broadcasts are received on a port, the "quality"
        of each node thus learned is "de-rated" by an amount
        dependent on the port's QUALITY figure. If the de-rated
        quality is less than the port MINQUAL, the node is not
        accepted into the table.

        This can be used to exclude unreachable and marginal nodes,
        but must be used with care.

</code> **EXAMPLE** <code>
        MINQUAL=100   ; No nodes less than quality 100 

</code> **SEE ALSO** <code>
        MINQUAL(1)     -- Display / Set port minimum quality
        PORTS(6)       -- Ports in XRouter.
        QUALITY(7)     -- NetRom Quality
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MINTXQUAL ====
<code>MINTXQUAL(7)           XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        MINTXQUAL -- Minimum Quality to Broadcast.

</code> **SYNOPSIS** <code>
        MINTXQUAL=n (where n is in the range 0 to 255)

</code> **DESCRIPTION** <code>
        MINTXQUAL is a PORT directive used in XROUTER.CFG.

        It specifies the minimum NetRom node "quality" to include in
        nodes broadcasts on this port. The acceptable range is 0 to
        255, and the default is 0.

        This is used to limit the size of nodes broadcasts on ports
        which are low bandwidth, low quality, or where the
        neighbours have limited nodes table capacity.

        The value of MINTXQUAL can be changed during run-time using
        the MINTXQUAL command.

</code> **EXAMPLE** <code>
        MINTXQUAL=100 ; Don't broadcast nodes with quality <100 

</code> **SEE ALSO** <code>
        MINQUAL(7)     -- Minimum Quality.
        MINTXQUAL(1)   -- Display / Set minimum quality to transmit
        PORTS(6)       -- Ports in XRouter.
        QUALITY(7)     -- NetRom Quality
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MQTTPORT ====
<code>MQTTPORT(7)             XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        MQTTPORT -- TCP Port for MQTT Server/Broker.

</code> **SYNPOSIS** <code>
        MQTTPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        MQTTPORT is an optional GLOBAL configuration directive
        used in XROUTER.CFG.

        If present, it specifies the TCP "service port" number for
        XRouter's internal MQTT server/broker. If not present, the
        default is 1883.
 
        The MQTT server (previously known as a "broker") allows MQTT
        clients to exchange information with XRouter, with each
        other, and with an external broker.

        Although primarily intended for use via the LAN, the broker
        is also available via NetRomX service 1883 for anyone who
        wants to experiment with MQTT over radio.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "MQTTPORT=99", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "MQTTPORT=99 9999",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting MQTTPORT to zero on a stack prevents TCP connections
        to the broker via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        MQTT-SRV(9)    -- MQTT Server/Broker.
        MQTT-SVC(9)    -- NetRomX MQTT Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== MQTTSERVADDR ====
<code>MQTTSERVADDR(7)         XROUTER REFERENCE MANUAL             23/9/2023

</code> **NAME** <code>
        MQTTSERVADDR -- Hostname / IP address of external MQTT Broker.

</code> **SYNOPSIS** <code>
        MQTTSERVADDR=<ip_address_or_hostname_of_mqtt_broker>

</code> **DESCRIPTION** <code>
        MQTTSERVADDR is an optional directive used in XROUTER.CFG.

        If present, it specifies the IP address or hostname of an
        external MQTT broker, to which XRouter's MQTT "publisher"
        can connect and publish data.

        If MQTTSERVADDR is not specified, which is the default
        condition, the publisher is disabled.

</code> **EXAMPLES** <code>
        MQTTSERVADDR=192.168.1.20
        MQTTSERVADDR=test.mosquitto.org

</code> **SEE ALSO** <code>
        MQTT-PUB(9)     -- MQTT Publisher.
        MQTTSERVPORT(7) -- TCP Port of external MQTT Broker
        XROUTER.CFG(8)  -- Main configuration file

</code>
----
==== MQTTSERVPORT ====
<code>MQTTSERVPORT(7)        XROUTER REFERENCE MANUAL              23/9/2023

</code> **NAME** <code>
        MQTTSERVPORT -- TCP Port of External MQTT Broker.

</code> **SYNOPSIS** <code>
        MQTTSERVPORT=n (where n is between 0 and 65535)

</code> **DESCRIPTION** <code>
        MQTTSERVPORT is an optional directive, used in XROUTER.CFG.

        If present, it specifies the TCP port of an external MQTT
        broker, to which XRouter's MQTT "publisher" can connect and
        publish data.

        MQTTSERVPORT defaults to 1883. Setting it 0 disables the
        MQTT publisher.

</code> **EXAMPLE** <code>
        MQTTSERVADDR=2884

</code> **SEE ALSO** <code>
        MQTT-PUB(9)     -- MQTT Publisher.
        MQTTSERVADDR(7) -- Hostname / IP of External MQTT Broker.
        XROUTER.CFG(8)  -- Main configuration file.

</code>
----
==== NETMASK ====
<code>NETMASK(7)            XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        NETMASK -- Subnet Mask.

</code> **SYNOPSIS** <code>
        NETMASK=<netmask>

</code> **DESCRIPTION** <code>
        NETMASK is an optional PORT directive used in XROUTER.CFG.

        It specifies a "subnet mask", which together with the port
        IPADDRESS defines the range of IP addresses that are on the
        same physical network segment as XRouter, and thus can be
        reached directly.

        If XRouter sees any IP datagrams with destination addresses
        in that range, that are NOT addressed to itself, it will not
        attempt to route them.

        The value set by this directive at boot-time can be changed
        during run-time. For more information see the NETMASK command
        page. 

</code> **EXAMPLE** <code>
        NETMASK=255.255.255.0

</code> **SEE ALSO** <code>
        IPADDRESS(7)   -- Main or Port IP Address.
        NETMASK(1)     -- Display / Set Port NETMASK.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== NODEALIAS ====
<code>NODEALIAS(7)           XROUTER REFERENCE MANUAL              25/9/2023
</code> **NAME** <code>
        NODEALIAS -- Primary AX25 / NetRom Alias.

</code> **SYNOPSIS** <code>
        NODEALIAS=<alias>

</code> **DESCRIPTION** <code>
        NODEALIAS is a MANDATORY directive used in the "global"
        section of XROUTER.CFG,

        It specifies an "alias", i.e. a memorable or meaningful
        alternative to the NODECALL, which can be used for all AX25
        and NetRom operations.

        The <alias> is a string of up to 6 uppercase ASCII characters
        and numbers of your choice.  It does not have a SSID.

        Aliases beginning with "#" are not displayed in node lists,
        and are used for "linking only" nodes with no user access.

        It is suggested that the alias be geographically relevant
        beyond your own local area, for example BRSTOL, LEEDS or
        BRUM, so it can be easily identified.  However, some sysops
        who run multiple node types tend to use "XR..." or "...XR"
        for their XRouter nodes, e.g. "XRPAG5", "DOTXR", "OMXRP".

        All AX25 ports respond to AX25 connect requests directed at
        this alias. They may also have up to 2 additional aliases.

</code> **EXAMPLES** <code>
        NODEALIAS=KIDDER         ; Kidderminster
        NODEALIAS=PZTXRP         ; G8PZT's XRPi

</code> **SEE ALSO** <code>
        NODECALL(7)    -- Primary AX25 / Netrom Callsign.
        PORTALIAS(7)   -- Additional Alias for a Port.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== NODECALL ====
<code>NODECALL(7)             XROUTER REFERENCE MANUAL            23/10/2023
</code> **NAME** <code>
        NODECALL -- Primary AX25 / NetRom Callsign.

</code> **SYNOPSIS** <code>
        NODECALL=<callsign>[-ssid]

</code> **DESCRIPTION** <code>
        NODECALL is a MANDATORY directive used in the "global"
        section of XROUTER.CFG,

        It specifies the callsign used for all AX25 L3/4 operations,
        and the default for L2 operations on each port.  It is the
        primary station identifier, and is also used in the prompts,
        ID beacons etc.

        The argument to NODECALL consists of up to 6 alphanumeric
        characters plus an optional SSID between 1 and 15.

</code> **EXAMPLE** <code>
        NODECALL=GB7PZT-12

</code> **SEE ALSO** <code>
        NODEALIAS(7)   -- Primary AX25 / Netrom Alias.
        PORTCALL(7)    -- Port Callsign.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== NODESINT ====
<code>NODESINT(7)            XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        NODESINTERVAL -- Nodes Broadcast Interval.

</code> **SYNOPSIS** <code>
        NODESINTERVAL=<minutes>

</code> **DESCRIPTION** <code>
        NODESINTERVAL is both a global and PORT directive, used in
        XROUTER.CFG.

        It specifies the interval, in minutes, between NetRom nodes
        broadcasts. The default is 60 minutes.

        If used in the "global" section of XROUTER.CFG, it sets the
        global NODESINTERVAL, the default for all PORTs. If used in
        a PORT block, it applies to that port only.

        Whilst the Netrom network usually works on a 60 minute nodes
        broadcast cycle, some types of software insist on a much
        smaller broadcast interval.

        It is harmful to the established network if sysops try to
        accommodate these neighbours by setting the global
        NODESINTERVAL to a smaller value, but using this keyword on 
        a per-port basis you can keep these neighbours happy without
        disrupting the rest of the Netrom network.

</code> **OPTIONS** <code>
        If you set a NODESINTERVAL=0 on a PORT, XRouter ignores
        received nodes broadcasts on that port, but will allow L3/L4
        activity if QUALITY is non-zero.

</code> **EXAMPLE** <code>
        NODESINTERVAL=10 ; 10 minues between broadcasts 
    
</code> **SEE ALSO** <code>
        NODESINT(1)    -- Display / Set NODESINTERVAL.
        PORTS(6)       -- Ports in XRouter.
        QUALITY(7)     -- NetRom Quality
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PACLEN ====
<code>PACLEN(7)              XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        PACLEN -- Maximum Packet Length.

</code> **SYNOPSIS** <code>
        PACLEN=n (where n is in the range 0 to 256)

</code> **DESCRIPTION** <code>
        PACLEN is both a GLOBAL and a PORT configuration directive,
        used in XROUTER.CFG.

        It specifies the maximum length of the information-bearing
        portion of frames transmitted by XRouter. 

        If used in the "global" section of XROUTER.CFG, it sets the
        default value for NetRom L3 operations. The default is 236,
        which is the largest NetRom payload that will fit in a full
        sized AX25 frame.

        If used in a PORT definition block, PACLEN applies to that
        port only, and sets the maximum payload size for AX25
        frames transmitted on that port. The default in this case is
        256. New AX25 connections "inherit" this value, but may
        adjust it dynamically if allowed to do so.  Inter-node links
        can override this inheritance and use a value specified by a
        ROUTE command or a suitable entry in XRNODES.

</code> **OPTIONS** <code>
        If the port PACLEN is set to 0, Xrouter dynamically adapts
        PACLEN (and MAXFRAME) to the link conditions, to maximise
        throughput.

</code> **EXAMPLE** <code>
        PACLEN=160   ; Allow 160 byte packets 

</code> **SEE ALSO** <code>
        MAXFRAME(7)    -- Maximum Unacked AX25 Frames.
        PACLEN(1)      -- Display / Set Paclen.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PEER ====
<code>PEER(7)                 XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        PEER -- Specify AXIP / AXUDP Link Partner.

</code> **SYNOPSIS** <code>
        PEER=<callsign>[:alias] <ipaddress | hostname> <udp_port>

</code> **DESCRIPTION** <code>
        PEER is an optional directive that may be used in certain
        types of PORT block within XROUTER.CFG. It is used to specify
        the IP addresses and UDP ports for one or more AXUDP / AXIP
        link partners.

        PEER is valid only when the PORT is attached to an INTERFACE
        which has "TYPE=AXUDP" and the PORT's IPLINK is "0.0.0.0". A
        PORT defined like this can support both AXIP and AXUDP links.
        Only ONE such port is allowed.

        This is the "alternative" way of doing AXIP / AXUDP, which is
        slighly less flexible than the "normal" (one link per port)
        method. It can be used alongside the "normal" method.

        The fields of a PEER statement may be separated by one or
        more spaces or tabs

        There is no limit to the number of PEER statements that may
        be used.

</code> **OPTIONS** <code>
        <callsign> is mandatory. It is not case-dependent. If an SSID
        is included, only packets addressed that exact destination
        will be routed. If an SSID is not included, all SSID's of the
        callsign are routed. To route packet only to G8PZT and none
        of its SSID's you would use G8PZT-0.

        [alias] is optional, and case-independent. If present, it
        allows AX25 Layer 2 connections to the partner's alias.

        <ip_address | hostname> is mandatory. Use an IP address if
        possible, because it saves having to resolve the hostname.

        <udp_port> is mandatory, but is specified as 0 for AXIP.

</code> **EXAMPLES** <code>
        # Route all SSID's of G8PZT using AXUDP, to udp port 9393
        PEER=G8PZT g8pzt.ath.cx 9393
        
        # As above, but route on either callsign or alias
        PEER=G8PZT g8pzt.ath.cx 9393
        
        # Route only to exact SSID G8PZT-14 via localhost
        PEER=G8PZT-14 127.0.0.1 10093
        
        # Route packets using AXIP instead of AXUDP
        PEER=G8PZT-0:KIDDER g8pzt.ath.cx 0

</code> **SEE ALSO** <code>
        AXIP(9)        -- AX25 over IP
        AXUDP(9)       -- AX25 over UDP
        LEARN(7)       -- Learn Unsolicited AX*P Peer Details.
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== PERSIST ====
<code>PERSIST(7)             XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        PERSIST -- AX25 Probablity to Transmit.

</code> **SYNOPSIS** <code>
        PERSIST=n (n=0-255)

</code> **DESCRIPTION** <code>
        PERSIST is an optional PORT directive used in XROUTER.CFG.

        It specifies the AX25 "Probability to transmit" in a given
        time slot (see SLOTTIME), used as part of the CSMA channel
        access procedure, to minimise media contention.

        A low value is used when there are several stations sharing
        the channel, giving each a fair chance to transmit.  A high
        value can be used when the channel isn't shared.

        The optimum setting is 255/n  where n is the number of
        stations sharing the channel. The default is 64. 

</code> **EXAMPLES** <code>
        PERSIST=25    ; 10% probability / 10 stations
        PERSIST=128   ; 50% probability / 2 stations
        
</code> **SEE ALSO** <code>
        PERSIST(1)     -- Display / Set Port Persist.
        PORTS(6)       -- Ports in XRouter.
        SLOTTIME(7)    -- CSMA interval timer
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PIPE ====
<code>PIPE(7)               XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        PIPE -- Frame Pipe.

</code> **SYNOPSIS** <code>
        PIPE=<destination_port_number> [callsign,callsign...]

</code> **DESCRIPTION** <code>
        PIPE is an optional PORT directive used in XROUTER.CFG.

        It creates a "frame pipe" to another port. This allows
        frames received (and optionally sent) on this port to be
        copied to another port, e.g. to allow a PMS on one port to
        see the traffic on another port.

        Unless the "bi-directional" option (see below) is specified,
        pipes are one way. In order to have two way traffic using a
        uni-directional pipe, you must set up a reverse pipe on the
        opposite port.

        You may pipe several ports to a single destination port, but
        you can only have one *outgoing* pipe from any port.

        Pipes are capable of generating an immense amount of traffic,
        so use them with care - your target port MUST be capable of
        handling the traffic load.

        By default, pipes are not selective, i.e. they pass traffic
        from any source callsign to any destination callsign (with
        the exception of Budlisted callsigns). On a busy channel,
        this could result in a lot of unnecessary traffic being piped.

        Therefore pipes can be made "selective", by adding a comma-
        delimited callsign list, e.g. "PIPE=4 GB7PZT,KDRBBS". This
        reduces the loading on the target port, by piping only the
        frames with the specified calls in the destination field.

        Pipes can also be made selective in terms of the types of
        traffic they pipe (AX25, NetRom etc). This is controlled by
        PIPEFLAG.

        Pipes can be made "bi-directional" by adding 512 to the
        PIPEFLAG value (suggested value = 515). If a frame is piped
        on a bi-directional pipe, the source call is remembered so
        that responses can be piped back to the sender. Thus a
        reverse pipe is not needed.

        Bi-directional pipes are useful where a BBS has a front end
        router - simply set up bi-directional selective pipes from
        each user port to the BBS port, and set up the BCAST option
        so that the UI mail headers are broadcast on each user port.
        The BBS will then allow direct connect and will respond to
        resync requests.

        To disable piping, set PIPE=0 or just omit the directive.

        Pipes can also be created and reconfigured during run-time,
        using the PIPE command.

</code> **EXAMPLES** <code>
        PIPE=2                ; Pipe frames from this port to port 2 
        PIPE=4 GB7PZT,KDRBBS  ; Selective pipe to port 4

</code> **SEE ALSO** <code>
        PIPE(1)        -- Display / Set "frame piping".
        PIPEFLAG(7)    -- Frame Pipe Options.
        PIPES(9)       -- About Frame Pipes.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PIPEFLAG ====
<code>PIPEFLAG(7)            XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        PIPEFLAG -- Frame Pipe Option Flags.

</code> **SYNOPSIS** <code>
        PIPEFLAG=n (where n is in the range 0 to 1023)

</code> **DESCRIPTION** <code>
        PIPEFLAG is an optional PORT directive, used in XROUTER.CFG.

        It is only used when piping is active, and controls which
        frames are piped. The default value is 3. 

</code> **OPTIONS** <code>
        The argument is the sum of the required options as follows:

             1  - UI frames *not* addressed to nodecall/alias.
             2  - Non-UI frames *not* addressed to nodecall/alias.
             4  - UI frames addressed to nodecall/alias.
             8  - Non-UI frames addressed to nodecall/alias.
            16  - UI frames transmitted by XRouter.
            32  - Non-UI frames transmitted by XRouter.
            64  - Allow budlisted users to be piped.
           128  - Netrom frames
           256  - IP / ARP frames
           512  - Bi-directional piping        

</code> **EXAMPLES** <code>
        PIPEFLAG=5        ; Pipe received UI frames only
        PIPEFLAG=517      ; Bi-directional UI pipe 

</code> **SEE ALSO** <code>
        PIPE(7)        -- Frame Pipe Directive.
        PIPEFLAG(1)    -- Display / Set Frame Pipe Options.
        PIPES(9)       -- About Frame Pipes.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PMSALIAS ====
<code>PMSALIAS(7)            XROUTER REFERENCE MANUAL              25/9/2023
</code> **NAME** <code>
        PMSALIAS -- Alias for Personal Mail System.

</code> **SYNOPSIS** <code>
        PMSALIAS=<alias>

</code> **DESCRIPTION** <code>
       PMSALIAS is a directive that can be used in XROUTER.CFG,
        both "globally" and within PORT definition blocks.

        It specifies an "alias", i.e. a sort of memorable alternative
        "callsign" for the PMS, e.g. "IOWPMS" (Isle of Wight
        PMS). This can be used interchangeably with the PMSCALL;
        i.e. the PMS will respond to either.

        The <alias> is a string of up to 6 uppercase ASCII characters
        and numbers. It is suggested that it should end with "PMS",
        and begin with the last 3 letters of the sysop's callsign.

        Alternatively, if the PMS is being used as a public BBS, you
        could use something geographically relevant, e.g. BHMPMS for
        Birmingham, KDRPMS for Kidderminster etc., so it can be
        easily identified in node tables.

        If used "globally", it specifies the "primary" PMS alias,
        used for AX25, NetRom and TCP operations.

        Any PORTs declared further down XROUTER.CFG "inherit" this
        alias for AX25 Layer 2 PMS operation on that port, UNLESS
        overridden by the use of PMSALIAS within that PORT's
        definition block.

        If PMSALIAS is used within a PORT definition block, it
        replaces the "global" PMS alias for that port only.

</code> **EXAMPLES** <code>
        PMSALIAS=IOWPMS
        PMSALIAS=PZTPMS

</code> **CAVEATS** <code>
        Omitting the global PMSALIAS, or setting it IDENTICAL to
        NODEALIAS disables PMS NetRom connectivity, but the PMS
        can still be used "standalone" via the PMS command.

</code> **SEE ALSO** <code>
        PMS(1)         -- Start PMS Session.
        PMS(9)         -- Personal Mail Server.
        PMSCALL(7)     -- PMS Callsign.
        PMSQUAL(7)     -- NetRom Quality for PMS.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PMSCALL ====
<code>PMSCALL(7)             XROUTER REFERENCE MANUAL              24/9/2023

</code> **NAME** <code>
        PMSCALL -- Callsign for Personal Message System.

</code> **SYNOPSIS** <code>
        PMSCALL=<callsign>

</code> **DESCRIPTION** <code>
        PMSCALL is a directive that can be used in XROUTER.CFG,
        both "globally" and within PORT definition blocks.

        It specifies the AX25/NetRom callsign for the Personal
        Message / Mailbox System (PMS). This can be used
        interchangeably with the PMSALIAS; i.e. the PMS will
        respond to connections directed at either.

        If used "globally", PMSCALL specifies the "primary" PMS
        callsign, used for AX25 and NetRom operations. This can be
        the same as NODECALL, but MUST use a different SSID. A SSID
        of -2 is the de-facto standard for XRPMS systems.

        Any PORTs declared further down XROUTER.CFG "inherit" this
        callsign for AX25 Layer 2 PMS operation on that port,
        UNLESS overridden by the use of PMSCALL within that PORT's
        definition block.

        If PMSCALL is used within a PORT definition block, it
        replaces the "global" PMS callsign for that port only.

</code> **EXAMPLE** <code>
        PMSCALL=G8PZT-2

</code> **CAVEATS** <code>
        Omitting the global PMSCALL, or setting it IDENTICAL to
        NODECALL (including the SSID) disables PMS server
        connectivity, but the PMS can still be used "standalone"
        via the PMS command.

</code> **SEE ALSO** <code>
        PMS(1)         -- Start PMS Session.
        PMS(9)         -- About the Personal Message System.
        PMSALIAS(7)    -- Personal Message System Alias.
        PMSQUAL(7)     -- NetRom Quality for PMS.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PMSHADDR ====
<code>PMSHADDR(7)             XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        PMSHADDR -- Hierarchical Address of PMS.

</code> **SYNOPSIS** <code>
        PMSHADDR=<h_address>

</code> **DESCRIPTION** <code>
        PMSHADDR is an optional directive, which can be used anywhere
        within the "global" section of XROUTER.CFG. If present, it
        specifies the "hierarchical address" of the inbuilt mailbox.
        This address is used, in combination wih the mailbox callsign,
        for routing mail.

        If a typical mailbox address is "GB7PZT.#24.GBR.EU", the
        ".#24.GBR.EU" is the "hierarchical address" (HA) part. This
        is usually read from right to left, specifying first the
        continent (EU), then the country within the continent (GBR),
        then the region within the country (#24).

        PMSHADDR is not required for "normal" PMS operation, but is
        required if you intend to exchange mail with other systems.
        Note that it MUST begin with a dot.

</code> **EXAMPLE** <code>
        PMSHADDR=.#24.GBR.EU

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

</code>
----
==== PMSQUAL ====
<code>PMSQUAL(7)              XROUTER REFERENCE MANUAL             26/9/2023
</code> **NAME** <code>
        PMSQUAL -- NetRom Quality for Personal Message System.

</code> **SYNOPSIS** <code>
        PMSQUAL=n  (n=0-255)

</code> **DESCRIPTION** <code>
        PMSQUAL is an optional directive used in the "global"
        section of XROUTER.CFG.

        It specifies the NetRom "quality" associated with the
        PMSCALL and PMSALIAS in nodes broadcasts from XRouter.

        The default is 0, which suppresses broadcasting of the PMS
        callsign and alias.

        A non-zero value of PMSQUAL has no effect unless both PMSCALL
        and PMSALIAS are defined.

        The use of a non-zero value is deprecated unless you are
        using the PMS as a public maildrop / BBS, because it bloats
        the nodes tables with PMS's that nobody is likely to use.

        Even if PMSQUAL is 0, the PMS is always available via the
        NODECALL, using NetRomX service number 2.

</code> **EXAMPLE** <code>
        PMSQUAL=50

</code> **SEE ALSO** <code>
        PMSALIAS(7)    -- Alias of Personal Message System.
        PMSCALL(7)     -- Callsign of Personal Message System
        PMS(9)         -- About the Personal Message System
        PMS-SVC(9)     -- NetRomX PMS Service.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PMSTYPE ====
<code>PMSTYPE(7)              XROUTER REFERENCE MANUAL             29/3/2024

</code> **NAME** <code>
        PMSTYPE -- Set PMS / BBS mode.

</code> **SYNOPSIS** <code>
        PMSTYPE=n (n=0-4)

</code> **DESCRIPTION** <code>
        PMSTYPE is an optional directive, which can be used anywhere
        within the "global" section of XROUTER.CFG. If present, it
        specifies the type, or mode, of the inbuilt mailbox. If not
        present, the mode defaults to 1 (standard PMS).

        The purpose of this is to allow the sysop to comply with
        their local licensing regulations and/or to have some
        control over what their system is doing.

</code> **OPTIONS** <code>
        0  Reserved for possible "No bulletins" option.
        1  Normal PMS, reverse forwarding only (default)
        2  PMS with forwarding and reverse forwarding.
        3  PMS with forwarding, reverse forwarding & relaying
        4  Full BBS

        The "Standard PMS" option accepts incoming mail (including
        bulletins) from bulletin boards, and allows outgoing mail to
        be collected by them. It also allows automatic XRouter to
        Xrouter private mail forwarding. It does not allow the
        mailbox to initiate "conventional" forwarding to other
        systems.

        Mode 2 allows "conventional" forwarding and reverse
        forwarding, but does not allow "relaying", i.e. mail
        received from one BBS cannot be forwarded to another.

        Mode 3 is a "sleeper" BBS. It looks and acts like a BBS, but
        pretends to be a PMS. It is still accessed using the PMS
        command.

        Mode 4 changes some of the captions, and installs the "BBS"
        command (in addition to the PMS command). If accessed via the
        former, both bulletins and personal mail are displayed by
        default. If accessed via the PMS command, only personal mail
        is displayed by default. 

</code> **EXAMPLES** <code>
        PMSTYPE=1  - Normal PMS
        PMSTYPE=3  - BBS masqurading as a PMS

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

</code>
----
==== PORTALIAS2 ====
<code>PORTALIAS2(7)           XROUTER REFERENCE MANUAL             25/9/2023

</code> **NAME** <code>
        PORTALIAS2 -- Secondary Alias for a Port.

</code> **SYNOPSIS** <code>
        PORTALIAS2=<alias>

</code> **DESCRIPTION** <code>
        PORTALIAS2 is an optional PORT directive used in XROUTER.CFG.

        It specifies an additional AX25 alias for the port, to be
        used for DIGIPEATING only. It does not accept connections.

        The <alias> is a string of up to 6 uppercase ASCII characters
        and numbers.

</code> **EXAMPLE** <code>
        PORTALIAS2=KRDIGI

</code> **SEE ALSO** <code>
        PORTALIAS(7)   -- Additional Port Alias.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PORTALIAS ====
<code>PORTALIAS(7)           XROUTER REFERENCE MANUAL              25/9/2023

</code> **NAME** <code>
        PORTALIAS -- Additional Alias for a Port.

</code> **SYNOPSIS** <code>
        PORTALIAS=<alias>

</code> **DESCRIPTION** <code>
        PORTALIAS is an optional PORT directive used in XROUTER.CFG.

        It specifies an AX25 alias for the port, to be used in
        addition to the NODEALIAS. The port will then respond to
        connect requests directed at either alias.

        The <alias> is a string of up to 6 uppercase ASCII characters
        and numbers.

</code> **EXAMPLE** <code>
        PORTALIAS=KDRMIN

</code> **SEE ALSO** <code>
        NODEALIAS(7)   -- Primary Node Alias
        PORTALIAS2(7)  -- Secondary Port Alias.
        PORTCALL(7)    -- Port Callsign.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PORTCALL ====
<code>PORTCALL(7)           XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        PORTCALL -- Additional Callsign for a Port.

</code> **SYNOPSIS** <code>
        PORTCALL=<callsign>[-ssid]

</code> **DESCRIPTION** <code>
        PORTCALL is an optional PORT directive used in XROUTER.CFG.

        It specifies an AX25 callsign for the port, to be used in
        addition to the NODECALL. The port will then respond to
        connect requests directed at either callsign.

</code> **EXAMPLE** <code>
        PORTCALL=GB7PZT-1

</code> **SEE ALSO** <code>
        NODECALL(7)    -- Node Main Callsign.
        PORTALIAS(7)   -- Port Alias.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PROMPTCOLOR ====
<code>PROMPTCOLOR(7)          XROUTER REFERENCE MANUAL            26/10/2023
</code> **NAME** <code>
        PROMPTCOLOR -- Colour For XRouter Prompts.

</code> **SYNOPSIS** <code>
        PROMPTCOLOR=<colour>

</code> **DESCRIPTION** <code>
        PROMPTCOLOR is an optional directive that can be used both
        in the "global" section of XROUTER.CFG, and within CONSOLE
        definition blocks.

        It specifies the colour used by XRouter for prompts such
        as "VK2DOT-1:DOTXR}", "Type ? for command list", "Callsign:"
        etc.

        If used in the "global" section of XROUTER.CFG, the setting
        is inherited by all CONSOLEs subsequently defined.

        If used within a CONSOLE definition block, it applies only
        to that console, overriding any inherited setting.

        The default PROMPTCOLOR is TURQUOISE.  Default colours have
        been carefully chosen for good visibility against a BLACK
        background.

</code> **OPTIONS** <code>
        <colour> should be one of the 16 colour names described in
        COLOURS(6), but please note that some colour combinations
        have very poor visibility.

        In general, the lighter the background colour, the smaller
        the choice of foreground colours that will work with it.

</code> **EXAMPLE** <code>
        PROMPTCOLOR=YELLOW

</code> **SEE ALSO** <code>
        ANSI(1)         -- Enquire/set ANSI colour mode
        COLOURS(6)      -- XRouter Display Colours.
        CONSOLES(6)     -- About XRouter Consoles.
        ACTIONCOLOR(7)  -- Colour For XRouter Actions and Events.
        CAPTIONCOLOR(7) -- Colour For Captions and Headings.
        WARNCOLOR(7)    -- Colour For warnings and Errors.
        XROUTER.CFG(8)  -- Main Configuration File.

</code>
----
==== PROTOCOL ====
<code>PROTOCOL(7)             XROUTER REFERENCE MANUAL            24/10/2023
</code> **NAME** <code>
        PROTOCOL -- Protocol Used on INTERFACE.

</code> **SYNPOSIS** <code>
        PROTOCOL=<protocol>

</code> **DESCRIPTION** <code>
        PROTOCOL is a configuration directive used within INTERFACE
        definition blocks in XROUTER.CFG, to specify the protocol to
        use on the interface.

        It is mandatory in most types of INTERFACE, but not required
        in other types, e.g. TYPE=AXIP, AXUDP etc.

        <protocol> must be one of the options detailed below.

</code> **OPTIONS** <code>
        ASCII   - Raw ASCII.
                  This is a plain ASCII *uplink* to XRouter's
                  command interpreter from a real "dumb terminal",
                  or a "terminal emulator" such as Hyperterm,
                  Procomm, PuTTY, Telink etc. via ASYNC interface.
                  May also be used via TCP or UDP interface types.

        AX25    - Pure AX25, with no CRC or HDLC framing.
                  Used for devices which provide their own CRC and
                  HDLC framing, such as AGW, SCC cards, Baycom & YAM
                  modems. Can also be used via "block mode"
                  interfaces which need no CRC or HDLC framing, such
                  as types LOOPBACK, TCP and UDP. 

        AXIP    - AX25 (with CRC) over IP.
                  This is implicit for interface type AXIP, but does
                  not cause an error if specified. Not for use with
                  any other interface type.  See AXIP(9) for
                  more information.

        AXTCP   - AX25 (with CRC) over TCP/IP
                  This is implicit for interface type AXTCP, but
                  does not cause an error if specified. Not for use
                  with any other interface type.  See AXTCP(9) for
                  more information.

        AXUDP   - AX25 (with CRC) over UDP/IP.
                  This is implicit for interface type AXUDP, but
                  does not cause an error if specified. Not for use
                  with any other interface type. See AXUDP(9) for
                  more information.

        DEDHOST - WA8DED Host Mode emulation.
                  Used with ASYNC interface to support applications
                  such as F6FBB BBS via real RS232 or pseudo-TTY
                  pairs.  See DEDHOST(9) for more information.

        ETHER   - Ethernet protocol.
                  Usually used with interface type EXTERNAL, but may
                  also be used via LOOPBACK, TCP and UDP interfaces.

        HDLC    - High-level Data Link Control protocol.
                  This is not proper HDLC! It is AX25 with CRC, but
                  without the HDLC flags and bit stuffing. For use
                  with TCP, UDP and LOOPBACK interface types.

        IP      - Raw Internet Protocol (IPv4).
                  Used primarily for TUN interfaces, but may also be
                  used on TCP, UDP and LOOPBACK interfaces.

        KISS     - AX25 within KISS framing.
                   Used via ASYNC interfaces for driving KISS TNCs,
                   via TCP interface for soundcard packet drivers
                   such as UZ7HO, Soundmodem, Direwolf etc.
.
        MODEM    - Hayes compatible PSTN modem.
                   This is used only on ASYNC interfaces.

        NETROM   - NetRom "backend" serial protocol.
                   This is an "inter-node" protocol originally
                   intended for linking NetRom TNC's (i.e. real
                   TNCs running NET/ROM or TheNet node EPROM's) via
                   their serial ports. Used with ASYNC interface
                   type, but may also be used via LOOPBACK, TCP and
                   UDP interfaces. The latter two 

        NONE     - No protocol.
                   This is a dummy protocol for use with LOOPBACK.

        PPP      - Point to Point Protocol.
                   Used to transport IP over serial links such as
                   RS232, dial-up connections etc. Used mainly with
                   ASYNC interfaces, but can also be used on TCP,
                   UDP and LOOPBACK. See PPP(9) for more info.

        SLIP     - Serial Line Internet Protocol.
                   This is IPv4 in a very simple encapsulation, for
                   use on ASYNC interfaces, but can also be used on
                   TCP, UDP and LOOPBACK.  See SLIP(9) for more.

        TNC      - TNC command line protocol.
                   This is a plain ASCII *downlink* from XRouter to
                   the command interpreter of a real TNC, or that of
                   an application which accepts TNC-style commands,
                   such as VARA. Used with ASYNC, TCP or UDP
                   interfaces.

        TNC2     - TNC2 emulator.
                   This is an 8-bit ASCII *uplink* from an external
                   device or program to XRouter's TNC2 emulator,
                   where XRouter looks like a "real" multi-port TNC
                   as far as the external device is concerned.
                   Usually used with ASYNC interface, but may also
                   be used with interface types TCP and UDP.
                   See TNC2(9) for more information.

</code> **NOTE** <code>
        The LOOPBACK interface is completely internal to XRouter,
        and is intended only for test purposes. The use of any of
        the above protocols via LOOPBACK is completely pointless!

</code> **SEE ALSO** <code>
        IFACES(6)      -- Interfaces in XRouter.
        AXIP(9)        -- AX25 over IP Tunneling Protocol.
        AXTCP(9)       -- AX25 over TCPP Tunneling Protocol.
        AXUDP(9)       -- AX25 over UDP Tunneling Protocol.
        DEDHOST(9)     -- WA8DED Hostmode Emulation.
        PPP(9)         -- Point to Point Protocol.
        PSTN(9)        -- PSTN Modem Support.
        SLIP(9)        -- Serial Line Internet Protocol.
        TNC2(9)        -- TNC2 Emulator.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== PROXY ====
<code>PROXY(7)              XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        PROXY -- Proxy Connectivity.

</code> **SYNOPSIS** <code>
        PROXY=<call1>[,call2,...]
        PROXY=<call> <alias> <qual> <ax_call> <portnum>
        PROXY=<call> <alias> <qual> <ipaddr> <tcp_port> [passwrd]

</code> **DESCRIPTION** <code>
        PROXY is an optional XROUTER.CFG directive that can be used
        both "globally" and within PORT definition blocks.

        It is used to define "proxies", which are AX25 or NetRom
        addresses which provide connectivity for otherwise
        unreachable targets. For example, providing an AX25 callsign
        for a TCP-based BBS. (See PROXIES page for full explanation).

</code> **OPTIONS** <code>
        If used within a PORT definition block, PROXY defines an
        "AX25-to-NetRom" proxy, giving a NetRom target system a direct
        AX25 presence on the port. The format is:

            PROXY=<netrom1>[,netrom2,...]

            <netrom1> and <netrom1> are the NetRom callsigns of the
            proxied systems.

            Example: PROXY=GB7PZT,GB7BBS

        If used within the "global" section of XROUTER.CFG, there are
        TWO possible forms of the PROXY, as follows:

        The first of these is the "NetRom-to-AX25" proxy, the opposite
        of the above, whereby an AX25-only target is given a NetRom
        and AX25 presence, as if it was a real NetRom node. I.e. it
        appears in XRouter's nodes table and is broadcast to its
        neighbours.

            PROXY=<call> <alias> <qual> <ax_call> <portnum>

            <call> is the NetRom and AX25 callsign
            <alias> is the NetRom and AX25 "alias"
            <qual> is the NetRom "quality" of the node in our table
            <ax_call> is the AX25 callsign of the proxied system
            <portnum> is the PORT where the proxied system resides

            Example: PROXY=MB7UYL UYLBBS 150 G6KDR-3 7

        The second "global" form is the "AX25/NetRom-to-TCP" proxy,
        which gives a TCP-only system both an AX25 and a NetRom
        presence on all ports. It is specified like this:

            PROXY=<call> <alias> <qual> <ipaddr> <tcp_port> [passwrd]

            <call> is the NetRom and AX25 callsign
            <alias> is the NetRom and AX25 "alias"
            <qual> is the NetRom "quality" of the node in our table
            <ipaddr>  is the proxied system's IP address.
            <tcp_port> is the TCP port number of the proxied system.
            <passwrd> is an optional password sent to the proxied
                      system upon connection. The proxied system uses
                      this to verify that the TCP connection
                      originates from an approved proxy.
 
            Example: PROXY=GB7PZT KDRBBS 150 192.168.0.4 8888 bloggs

</code> **WARNING** <code>
        Proxies are very useful, but very dangerous if you aren't sure
        what you are doing! Proxy-created "forever loops" can kill
        XRouter, or cause interference to other systems. Don't use
        them if you don't need to, and please read the warnings in the
        PROXIES page. If your XRouter crashes, and you have proxies,
        then its a sure sign that you have configured them wrongly!

</code> **SEE ALSO** <code>
        PROXIES(9)     -- About Proxy Connections.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== QUALADJ ====
<code>QUALADJ(7)              XROUTER REFERENCE MANUAL            18/10/2023
</code> **NAME** <code>
        QUALADJUST -- NetRom Quality Manipulation.

</code> **SYNOPSIS** <code>
        This file describes a feature which allows you to reduce
        the NetRom quality of "foreign" nodes on your system, or to
        exclude certain nodes or groups of nodes altogether.

</code> **DESCRIPTION** <code>
        With ever-increasing connectivity via the Internet, the
        NetRom network is bypassing national and geographical
        boundaries, and this is causing problems.  Because Internet
        qualities are much higher than radio qualities, there are
        far more nodes in the tables.
        
        In some cases there may be a limit to the size of tables,
        and more importantly there is a limit to the number of nodes
        that can be broadcast on a low bandwidth RF channel.

        In addition, with too many nodes in the table the "N"
        commands become useless because the response becomes too
        large for the user to download on a limited bandwidth
        channel.  Even if there is sufficient bandwidth, the
        response may occupy several pages and the user may not be
        able to review anything which has scrolled off the screen.

        Experience has shown that 150 nodes is roughly the maximum
        comfortable table size. But how do you decide *which* 150
        nodes to include?  How do you achieve the balance between
        slow, unreliable, radio-routed nodes and fast, reliable,
        Internet-routed ones?

        Some people advocate setting low route qualities for the
        Internet links, but unless everyone agrees on those
        qualities, this can lead to traffic being routed via slow,
        unreliable links when faster and more direct routes exist!

        And do you want your table full of high quality
        internet-routed foreign nodes, to the exclusion of your
        local RF nodes?  Can your users find the nodes they want,
        amidst the clutter?

        Quality de-rating by callsign can help with this management
        issue.  It allows you to de-rate the NetRom quality of a
        node or group of nodes based on the NetRom callsign,
        instead of the route on which they were received.

        Thus, no matter what relative route qualities you use, you
        can change the relative qualities to favour your local
        nodes, or (more likely) those which share your language.

</code> **OPTIONS** <code>
        This feature uses the global QUALADJUST directive in
        XROUTER.CFG as follows:

           QUALADJUST <call | "default"> <0-255>

        e.g.    QUALADJUST DEFAULT 120
                QUALADJUST G* 255
                QUALADJUST ZL* 200

        The "default" argument sets the default value which is used
        to de-rate all nodes not matched by any other QUALADJUST
        statement.  The normal NetRom de-rate algorithm is used, so
        255 gives no de-rate and 0 gives full de-rate (i.e. to block
        a callsign or group of callsigns). If there are no
        QUALADJUST statements the default is 255.

</code> **LIMITATIONS** <code>
        QUALADJUST is applied to neighbour nodes and all nodes
        learned from NetRom broadcasts.  It is NOT applied to nodes
        learned via INP3 because they have no quality to de-rate,
        and is not applied to nodes entered by a NODE ADD command or
        an entry in the XRNODES file.
       
</code> **CAVEATS** <code>
        This is an experimental feature. Please use it with caution.

</code> **SEE ALSO** <code>
        AUTOQUAL(9)    -- Automatic Route Quality.
        NODES(1)       -- Display / Modify the Nodes table.
        QUALITY(1)     -- Display / Set default quality for a port.
        XRNODES(8)     -- Routes / Nodes Recovery File.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== QUALITY ====
<code>QUALITY(7)            XROUTER REFERENCE MANUAL               25/9/2023

</code> **NAME** <code>
        QUALITY -- Default NetRom Quality.

</code> **SYNOPSIS** <code>
        QUALITY=n (where n is 0 to 255)

</code> **DESCRIPTION** <code>
        QUALITY is an optional PORT directive used in XROUTER.CFG.

        It specifies the default quality for nodes whose broadcasts
        are received on the port (default=10).

        The value can be changed during run-time using the command
        of the same name.

        Setting QUALITY to 0 disables all NetRom L3/4 activity on
        the port, e.g. on user access frequencies.

</code> **EXAMPLE** <code>
        QUALITY=30 

</code> **SEE ALSO** <code>
        QUALITY(1)     -- Display / Set default Quality.
        QUALADJ(7)     -- NetRom Quality Manipulation.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RADIO ====
<code>RADIO(7)              XROUTER REFERENCE MANUAL               21/9/2023

</code> **NAME** <code>
        RADIO -- Radio control definition block.

</code> **SYNOPSIS** <code>
        RADIO=n (where n is a number between 1 and 5)

</code> **DESCRIPTION** <code>
        RADIO is an optional directive used in XROUTER.CFG. If
        present in the "global" section, it begins a "radio control"
        block, which is used, along with the RADIO command, to
        control an attached radio.

        If present within an INTERFACE definition block, RADIO
        specifies which previously defined radio block is associated
        with the interface.

        RADIO definition blocks start with RADIO=n, contain a number
        of other directives, and end with ENDRADIO. They *must* be
        defined BEFORE any INTERFACEs that refer to them.

</code> **OPTIONS** <code>
        The following directives are accepted within a RADIO block:

        NAME    Specifies a name for this radio, e.g. "HF Rig".
                Maximum 63 characters, spaces allowed.

        TYPE    Radio type: 1=Custom, 2=Icom ICR7000, 3=Icom PCR1000,
                4=Yaesu Ft100, 5=Flex, 6=Hamlib.

                ICR7000 is a receiver which uses Icom CI-V interface.
                PCR1000 is a receiver which uses serial TTY control
                FT100 is a transceiver using Yaesu CAT interface
                FLEX is for Flexradio
                HAMLIB lets XR talk to Hamlib which controls the rig.

                Additional radio types can be added upon request.

        COM     Specifies how XRouter communicates with the rig.
                For most types this is via a TTY, for example
                "COM=/dev/ttyUSB0". But for Hamlib it should specify
                the IP address and port used by Hamlib,
                for example "COM=127.0.0.1:3900".

        BAUDS   Baud rate for the TTY (not needed for Hamlib).
                Defaults to 9600 (1200 for ICR7000).

        STOPBITS Number of "stop" bits on the serial data (default=2)
                 (Not required for Hamlib)

        FREQUENCY Initial receive frequency in Hz, e.g. "144925000"

        OFFSET  "Tuning Offset" in PPM between requested frequency
                and actual frequency, in case the rig's reference
                crytal has drifted.

        MODE    Initial modulation mode:
                (Not all radios support all types)
                "USB", "LSB", "SSB", "DSB" "CW", "CWR", "RTTY",
                "RTTYR", "AM", "FM", "NFM", "WFM", "AMS", "PKTLSB",
                "PKTUSB", "PKTFM", "ECSSUSB", "ECSSLSB", "FAX",
                "SAM", "SAL", "SAH", "DATA, "DIG"

        SQUELCH Initial Squelch level (0-255)
                0=fully open, 255=fully closed

        VOLUME  Initial Audio volume (0-255) 0=min, 255=max

        TXFREQ  Initial Transmission frequency in Hz
                (if different to receive)

        PTTMETHOD How the PTT is controlled:
                0        Undefined
                1        Serial RTS
                2        Serial DTR
                3        CM108 HID
                4        CAT, CI5, FLEX etc
                5        GPIO pin (Pi only)

        RXAUDIODEV Device for inputting audio from radio to node,
                for example: "RXAUDIODEV=/dev/dsp2"

        Some of the values are "initial" values, that can be changed
        by the RADIO command during run-time, for example FREQUENCY,
        VOLUME, MODE etc.

</code> **EXAMPLE** <code>
        Example for PCR1000 receiver controlled via /dev/ttyUSB0,
        defaulting to 9600,8,n.2 with VOIP audio input via /dev/dsp2

        RADIO=1
                NAME=PCR-1000
                TYPE=3
                COM=/dev/ttyUSB0
                FREQUENCY=145.625
                MODE=FMn
                VOLUME=80
                SQUELCH=75
                RXAUDIODEV=/dev/dsp2
        ENDRADIO

</code> **SEE ALSO** <code>
        RADIO(1)       -- Rig control commands
        XROUTER.CFG(8) -- Main configuration file

</code>
----
==== RESPTIME ====
<code>RESPTIME(7)            XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        RESPTIME -- AX25 Delayed Ack Time.

</code> **SYNOPSIS** <code>
        RESPTIME=<milliseconds>

</code> **DESCRIPTION** <code>
        RESPTIME is an optional PORT drectuive, used in XROUTER.CFG.

        It specifies the AX25 "T2" (delayed ack) time, i.e. the time
        to wait after receiving a frame before sending an ack, which
        allows multi-frame transmissions to be acknowledged with a
        single ack, increasing link efficiency. The value is in
        milliseconds, and the default is 1500.

        Resptime should be long enough for a link partner to transmit
        a full-sized information frame, i.e. approximately
        ((their_paclen * 10000) / RFbaudRate) millisecs, otherwise
        XRouter will send unnecessary ack frames.

        Too high a value will cause the link to be too "relaxed",
        whereas too low a value will cause too many acks. Both
        extremes reduce the link efficiency.

        The default RESPTIME of 1500 milliseconds is OK for 1200 baud
        with paclen=120, but 2200 would be more appropriate if their
        paclen was 256. At 9600 baud, or on AXUDP links, 200 ms is
        probably adequate.

        The value can be changed "on the fly" using the command of
        the same name.

</code> **EXAMPLE:** <code>
        RESPTIME=2000   ; 2 seconds 

</code> **SEE ALSO** <code>
        FRACK(7)       -- Frame Acknowledgement Time.
        RESPTIME(1)    -- Display / Set AX25 Delayed Ack Time.
        PACLEN(7)      -- Maximum Packet Length.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RETRIES ====
<code>RETRIES(7)            XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        RETRIES -- AX25 Maximum Retry Count.

</code> **SYNOPSIS** <code>
        RETRIES=n (where n is 0 to 100)

</code> **DESCRIPTION** <code>
        RETRIES is a PORT directive used in XROUTER.CFG.

        It specifies the AX25 maximum consecutive connect /
        disconnect / resend attempts (default = 10).

        There is little point in setting retries more than 10, other
        than for test purposes. If you need so many retries, it's a
        useless link and you're just wasting everyone else's airtime.

        The higher you set this value, the longer users will have to
        wait to get a "failure with" for an unconnectable
        destination.

        RETRIES=0 means "try forever", and should be avoided except
        for testing.

        The value can be changed during run-time using the command
        of the same name.

</code> **EXAMPLE** <code>
        RETRIES=5

</code> **SEE ALSO** <code>
        RETRIES(1)     -- Display / Set Maximum Retries
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RFBAUDS ====
<code>RFBAUDS(7)             XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        RFBAUDS -- Radio Channel Baud Rate.

</code> **SYNOPSIS** <code>
        RFBAUDS=<baud_rate>

</code> **DESCRIPTION** <code>
        RFBAUDS is an optional PORT directive used in XROUTER.CFG.

        It specifies the over-the-air baud rate (default = 1200).

        This parameter is used with "real" tnc's and YAM modems
        attached via RS232, because the RF baud rate is usually
        different to the RS232 baud rate.

        It helps XRouter make timing decisions (such as nodes
        broadcast inter-packet timing) and to report certain stats
        correctly. It is also reported to the node mapping server.

</code> **EXAMPLE** <code>
        RFBAUDS=2400 

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.
        YAM(9)         -- YAM ("Yet Another Modem") HDLC Modem.

</code>
----
==== RHPPORT ====
<code>RHPPORT(7)             XROUTER REFERENCE MANUAL              27/9/2023

</code> **NAME** <code>
        RHPPORT -- TCP Port for RHP Server.

</code> **SYNOPSIS** <code>
        RHPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        RHPPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the RHP (Remote Host Protocol) server. If not present,
        the default is 9000.

        The RHP server provides a socket-like application interface
        to various layers within XRouter.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "RHPPORT=80", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "RHPPORT=80 8080", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting RHPPORT to zero on a stack prevents TCP connections
        to the RHP server via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        RHP-SRV(9)     -- Remote Host Protocol server.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== RLOGINPORT ====
<code>RLOGINPORT(7)           XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        RLOGINPORT -- TCP Port for Remote Login Service.

</code> **SYNOPSIS** <code>
        RLOGINPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        RLOGINPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the RLOGIN (Rmote Login) service. If not present, the
        default is 513.

        RLOGIN is a "remote login" facility for full sysop access via
        secure links.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "RLOGINPORT=513", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "RLOGINPORT=513 514", the
        first argument applies to the XRouter stack and the second to
        the host system's stack. The numbers must be separated by
        whitespace

        Setting RLOGINPORT to zero on a stack prevents TCP
        connections to the RLOGIN service via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        RLOGIN(9)      -- Remote Login Service.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== ROWS ====
<code>ROWS(7)                 XROUTER REFERENCE MANUAL            19/10/2023
</code> **NAME** <code>
        ROWS -- Set Display Height.

</code> **SYNOPSIS** <code>
        ROWS=n (n = 25-60)

</code> **DESCRIPTION** <code>
        ROWS is an optional configuration directive, used only in the
        "global" section of XROUTER.CFG. It sets the display height
        in rows or lines of text.

        The default display height for XRouter is 25 rows, which is
        a legacy from the 80x25 DOS days. With XR32 running in a
        Windows "command" window, this setting allows the use of
        retro "full screen" mode, using the ALT-RETURN key
        combination.

        However, you may find that with just 25 lines, the status
        windows are too cramped, and console pages are too short for
        comfort, in which case you may expand the display by using
        the ROWS directive at the start of XROUTER.CFG, before any
        CONSOLE definitions.  For instance, for a 50-row display use
        ROWS=50.

        Depending on your screen resolution and "Command window" (or
        Linux "terminal") settings you may be able to use 60 or more
        rows, however some display adaptors won't allow you to go
        much beyond 40 rows.

        It is better to start with a low figure and increase it 10 at
        a time until you find the limit for your adaptor.  Beyond the
        limit, the display will either break up or behave oddly.

</code> **CAVEATS** <code>
        If you set ROWS more than 25, you cannot use "full screen"
        mode on Windows.

</code> **SEE ALSO** <code>
        COLS(7)        -- Set Display Width.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SESSLIMIT ====
<code>SESSLIMIT(7)            XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        SESSLIMIT -- Maximum Simultaneous Connections on Port.

</code> **SYNOPSIS** <code>
        SESSLIMIT=n (where n is 0 to 255)

</code> **DESCRIPTION** <code>
        SESSLIMIT is an optional PORT directive used in XROUTER.CFG.

        It specifies the maximum simultaneous connections each user
        is allowed on the port. The default is 255, i.e. unlimited.

        This would typically be used to "choke" users who hog all
        the bandwidth on a port with too many connections.

        There is a global limit on the number of AX25 links, namely
        MAXLINKS (default=30), so on a multi-port node it is worth
        setting SESSLIMIT substantially lower than MAXLINKS.

        The user must however use a different SSID for each
        connection on any given PORT, which limits his maximum
        number of connections to 16.
 
</code> **EXAMPLE** <code>
        SESSLIMIT=5 

</code> **SEE ALSO** <code>
        MAXLINKS(7)    -- Global Maximum AX25 Connections.
        PORTS(6)       -- Ports in XRouter.
        USERS(7)       -- Maximum Users on Port.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SLOTTIME ====
<code>SLOTTIME(7)            XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        SLOTTIME -- CSMA Interval Time.

</code> **SYNOPSIS** <code>
        SLOTTIME=<millisecs>

</code> **DESCRIPTION** <code>
        SLOTTIME is an optional PORT directive used in XROUTER.CFG.

        It specifies the CSMA (Carrier Sense Multiple Access)
        interval time, used with PERSIST to make channel access
        decisions. The value is in milliseconds (default=100).

        If the channel is clear, the TNC (or SCC/YAM card) generates
        a random number which is then compared with PERSIST. If the
        random number is less than PERSIST, the TNC will wait for the
        SLOTTIME interval, then repeat the action, otherwise it will
        transmit immediately.

        This improves throughput by ensuring that everyone doesn't
        transmit as soon as the channel is clear, which would cause
        collisions and retries.

        The value can be changed "on the fly" using the SLOTTIME
        command.

</code> **EXAMPLE** <code>
        SLOTTIME=100   ; 100 millisecs per slot 

</code> **SEE ALSO** <code>
        SLOTTIME(1)    -- Display / Set CSMA Interval.
        PERSIST(7)     -- AX25 Probablity to Transmit.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SOCKSPORT ====
<code>SOCKSPORT(7)            XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        SOCKSPORT -- TCP Port for SOCKS Proxy.

</code> **SYNOPSIS** <code>
        SOCKSPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        SOCKSPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        by the SOCKS Proxy. If not present, the default is 1080.

        SOCKS is a circuit level proxy for applications, as an
        alternative to Network Address Transslation (NAT).

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "SOCKSPORT=1080", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "SOCKSPORT=1080 1090",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting SOCKSPORT to zero on a stack prevents TCP connections
        to the SOCKS proxy via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        SOCKS(9)       -- About the SOCKS Proxy.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SOFTDCD ====
<code>SOFTDCD(7)             XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        SOFTDCD -- Software Data Carrier Detect.

</code> **SYNOPSIS** <code>
        SOFTDCD=<0|1>

</code> **DESCRIPTION** <code>
        SOFTDCD is an optional PORT directive used in XROUTER.CFG.

        It specifies whether or not software-derived DCD (Data
        Carrier Detect) is used insteaed of hardware DCD. It is used
        only by SCC cards, and defaults to 0 (off).

</code> **OPTIONS** <code>
        If SOFTDCD=0 the "real" DCD generated by SCC card is used.

        If SOFTDCD=1 the real dcd is ignored, and the SCC driver uses
        the presence of HDLC data as a DCD indication.

</code> **CAVEATS** <code>
        Using SOFTDCD=1 with an open squelch generates a *huge*
        interrupt loading, which may cause degradation of
        performance, depending on the PC type, so it is not
        recommended.

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== SYSOP ====
<code>SYSOP(7)              XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        SYSOP -- Description..

</code> **SYNOPSIS** <code>
        SYSOP=<0|1>

</code> **DESCRIPTION** <code>
        SYSOP is an optional PORT directive, used in XROUTER.CFG.

        If you set SYSOP=1 on a PORT, anyone who connects on that
        port gets full sysop status without needing to answer a
        password challenge.

        This is intended ONLY FOR USE ON SECURE LINKS, such as RS232
        or Ethernet, and the default is zero. 

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TELNETPORT ====
<code>TELNETPORT(7)           XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        TELNETPORT -- TCP Port for TELNET Access.

</code> **SYNOPSIS** <code>
        TELNETPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        TELNETPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        for TELNET access to XRouter. If not present, the default is
        23.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "TELNETPORT=23", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "TELNETPORT=23 8023",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting TELNETPORT to zero on a stack prevents TELNET
        access via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        TELNET(9)      -- About TELNET Access.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TELPROXYPORT ====
<code>TELPROXYPORT(7)         XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        TELPROXYPORT -- TCP Port for Telnet Proxy.

</code> **SYNOPSIS** <code>
        TELPROXYPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        TELPROXYPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        for Telnet proxy access to XRouter. If not present, the
        default is 2323.

        The Telnet proxy allows 100% binary connections not only to
        TCP/IP targets, but also to Netrom and AX25 targets. This
        would typically be used by a TCP/IP-only BBS to perform
        FBB compressed forwarding with netrom and ax25 targets.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "TELPROXYPORT=2323",
        it applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "TELPROXYPORT=236 2323",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting TELPROXYPORT to zero on a stack prevents Telnet
        proxy access via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        TELPROXY(9)    -- About the Telnet Proxy.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TTYLINKPORT ====
<code>TTYLINKPORT(7)          XROUTER REFERENCE MANUAL             27/9/2023

</code> **NAME** <code>
        TTYLINKPORT -- TCP Port for TTYLINK Access.

</code> **SYNOPSIS** <code>
        TTYLINKPORT=n1 [n2] (where n1 and n2 are 0 to 65535)

</code> **DESCRIPTION** <code>
        TTYLINKPORT is an optional "global" directive used in
        XROUTER.CFG.

        If present, it specifies the TCP "service port" number used
        for TTYLINK (keyboard to keyboard chat) access to XRouter. If
        not present, the default is 87.

        TTYLINK is also available as NetRomX service 87.

</code> **OPTIONS** <code>
        If a single argument is supplied, e.g. "TTYLINKPORT=23", it
        applies to whichever TCP/IP stack(s) XRouter is using.

        If TWO arguments are supplied, e.g. "TTYLINKPORT=87 8087",
        the first argument applies to the XRouter stack and the
        second to the host system's stack. The numbers must be
        separated by whitespace

        Setting TTYLINKPORT to zero on a stack prevents TTYLINK
        access via that stack.

        See TCP-PORTS(6) for more information on this and the caveat
        below.

</code> **CAVEATS** <code>
        In order to use port numbers below 1024 on the Linux stack,
        XRouter must be run from a root account, or given the
        CAP_NET_BIND_SERVICE capability.

</code> **SEE ALSO** <code>
        CAPFLAGS(6)    -- Capability Flags.
        TTYLINK(9)     -- About TTYLINK.
        TCP-PORTS(6)   -- TCP Service Ports.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TXDELAY ====
<code>TXDELAY(7)             XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        TXDELAY -- Transmit Delay.

</code> **SYNOPSIS** <code>
        TXDELAY=<millisecs>

</code> **DESCRIPTION** <code>
        TXDELAY is an optional PORT directive used in XROUTER.CFG.

        It specifies the delay between transmitter activation and the
        start of the frame data in milliseconds (default=300).

        After turning the transmitter on, the TNC (or SCC / YAM card)
        waits for this interval before sending HDLC data. This allows
        the TX to stabilise, and the link partner's squelch to open.

        The value can be changed on the fly using the TXDELAY
        command, but please be ware that changes may take up to 5
        minutes to take effect on KISS TNC's.

</code> **NOTE** <code>
        Software TNC's such as "Direwolf" might complain that your
        TXDELAY setting is too long, but they have no knowledge of
        how long it takes the transmitter frequency to stabiise, nor
        how long it takes the link partnar's squelch to open, so you
        should ignore it and trust your own judgement!

        Start with a long TXDELAY, e.g. 500 millisecs, then gradually
        reduce it until the partner stops responding. That is the
        absolute minimum txdelay. Raise TXDELAY until the link
        becomes reliable again. Stupidly low TXDELAY is a common
        cause of erratic links! Don't forget that the radios may be
        inconsistent - they might be slower to respond when cold or
        hot, or when desensitised by other signals.

</code> **SEE ALSO** <code>
        TXDELAY(1)     -- Display / Set TX Delay.
        PORTS(6)       -- Ports in XRouter.
        TXTAIL(7)      -- TX Tail Time
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TXPORT ====
<code>TXPORT(7)             XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        TXPORT -- Port to Transmit On.

</code> **SYNOPSIS** <code>
        TXPORT=<port_number>

</code> **DESCRIPTION** <code>
        TXPORT is an optional PORT directive used in XROUTER.CFG.

        It specifies the number of the PORT upon which outgoing
        frames should be transmitted. The default is 0, i.e. TX and
        RX on the same port.

        You would typically use this when several ports, with
        separate receivers, share a single transmitter.

        This parameter can be changed "on the fly", using the TXPORT
        command.

</code> **EXAMPLE** <code>
        TXPORT=5     ; Transmit on port 5 

</code> **SEE ALSO** <code>
        TXPORT(1)      -- Display / Set Port to Transmit On.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== TXTAIL ====
<code>TXTAIL(7)             XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        TXTAIL -- Transmitter Turnoff Delay.

</code> **SYNOPSIS** <code>
        TXTAIL=<millisecs>

</code> **DESCRIPTION** <code>
        TXTAIL is an optional PORT directive used in XROUTER.CFG.

        It specifies the transmiter turnoff delay in milliseconds
        (default = 100).

        This is the interval, after sending a frame, for which the
        transmitter remains activated. It is intended to allow the
        CRC (Cyclic Redundancy Check) and closing flags to be sent.
        It has no meaning on non-radio ports.

        Due to PC timing inaccuracies, you should set this no lower
        than 100 for SCC cards!

        The value can be changed on the fly using the TXTAIL command,
        but changes may take up to 5 minutes to take effect on KISS
        ports.

</code> **SEE ALSO** <code>
        TXTAIL(1)      -- Display / Set TX Tail Time.
        TXDELAY(7)     -- TX Activation Delay
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== UDPLOCAL ====
<code>UDPLOCAL(7)            XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        UDPLOCAL -- Local UDP Port for Link.

</code> **SYNOPSIS** <code>
        UDPLOCAL=<udp_port>

</code> **DESCRIPTION** <code>
        UDPLOCAL is a PORT directive used in XROUTER.CFG for AXUDP
        ports only.

        It specifies the UDP port number for the local end of an
        AXUDP link. The default is 93. This number must match the
        link partner's UDPREMOTE, i.e. the destination service number
        in the frames from him to you.

        It is perfectly valid for all your PORTS to use the same
        UDPLOCAL. This reduces the number of "holes" (port forwards)
        you need to make in your firewall. The *only* reason ever to
        have more than one UDPLOCAL is when you have more than one
        AXUDP node sharing the same public IP address. Your link
        partners have no right to dictate this value!

</code> **EXAMPLE** <code>
        UDPLOCAL=7388 

</code> **CAVEATS** <code>
        If UDPLOCAL is less than 1024, and XRouter is using the Linux
        IP stack, XRouter needs to be granted the CAP_NET_BIND_SERVICE
        capability unless it is run from a root account. See CAPFLAGS
        for more information.

</code> **SEE ALSO** <code>
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        CAPFLAGS(6)    -- Capability Flags.
        PORTS(6)       -- Ports in XRouter.
        UDPLOCAL(1)    -- Display / Set Local UDP Port.
        UDPREMOTE(7)   -- Remote UDP Port.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== UDPREMOTE ====
<code>UDPREMOTE(7)            XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        UDPREMOTE -- Remote UDP Port for Link.

</code> **SYNOPSIS** <code>
        UDPREMOTE=<udp_port>

</code> **DESCRIPTION** <code>
        UDPREMOTE is a PORT directive used in XROUTER.CFG for AXUDP
        ports only.

        It specifies the UDP port number for the remote end of an
        AXUDP link, i.e. UDP destination number in the AXUDP frames
        from you to your link partner. It must match the link
        partner's UDPLOCAL, otherwise the link will not function.

        If not specified, UDPREMOTE defaults to 93.

        You have no right to dictate this value to your link partner.
        It is THEIR choice only (see UDPLOCAL).

</code> **EXAMPLE** <code>
        UDPREMOTE=10093 

</code> **SEE ALSO** <code>
        AXUDP(9)       -- AX25-over-UDP Tunnelling.
        PORTS(6)       -- Ports in XRouter.
        UDPLOCAL(7)    -- Local UDP Port.
        UDPREMOTE(1)   -- Display / Set Remote UDP Port.
        XROUTER.CFG(8) -- Main Configuration File

</code>
----
==== UNPROTO ====
<code>UNPROTO(7)            XROUTER REFERENCE MANUAL               26/9/2023

</code> **NAME** <code>
        UNPROTO -- Path for Unproto Broadcasts.

</code> **SYNOPSIS** <code>
        UNPROTO <destcall>[,digicall,digicall,...]

</code> **DESCRIPTION** <code>
        UNPROTO is an optional PORT directive used in XROUTER.CFG.

        It specifies a destination callsign plus optional digipeater
        path used for unproto broadcasts from applications onto the
        port. The callsigns should be separated the with commas.

</code> **EXAMPLE** <code>
        UNPROTO=CQ,G6YAK 

</code> **SEE ALSO** <code>
        UNPROTO(1)  -- Display / Set Path for Unproto Broadcasts.
        APRSPATH(7) -- Default Digipeater Path for APRS.
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== USERS ====
<code>USERS(7)               XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        USERS -- Maximum Users on Port.

</code> **SYNOPSIS** <code>
        USERS=<0-255>

</code> **DESCRIPTION** <code>
        USERS is an optional PORT directive used in XROUTER.CFG.

        It specifies the maximum no. of simultaneous AX25 L2
        connections allowed on the port. The default is 255 which
        means "no limit".

</code> **EXAMPLE** <code>
        USERS=9 

</code> **SEE ALSO** <code>
        PORTS(6)       -- Ports in XRouter.
        SESSLIMIT(7)   -- Maximum Simultaneous Connections on Port.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== VALIDCALLS ====
<code>VALIDCALLS(7)          XROUTER REFERENCE MANUAL              26/9/2023

</code> **NAME** <code>
        VALIDCALLS -- AX25 Whitelist.

</code> **SYNOPSIS** <code>
        VALIDCALLS=<callsign>[,calsign,callsign...]

</code> **DESCRIPTION** <code>
        VALIDCALLS is an optional PORT directive used in XROUTER.CFG.

        It specifies a list of callsigns who are allowed to make AX25
        connections to the port, all other callsigns being excluded.

        It is therefore the opposite of EXCLUDE, and is typically
        used to prevent users or unwanted nodes from connecting to
        link-only ports.

        Callsigns must be separated by commas, with no spaces.

</code> **EXAMPLE** <code>
        VALIDCALLS=G6YAK,G6AMU   ; Accept *only* these callsigns 

</code> **SEE ALSO** <code>
        EXCLUDE(7)     -- AX25 L2 Exclusions (Budlist).
        PORTS(6)       -- Ports in XRouter.
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== WALLFLAGS ====
<code>WALLFLAGS(7)            XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        WALLFLAGS -- Options for Message Wall / Guestbook.

</code> **SYNOPSIS** <code>
        WALLFLAGS=n (where 0 <= n <= 15)

</code> **DESCRIPTION** <code>
        WALLFLAGS is an optional directive used only in XROUTER.CFG.

        It controls whether or not the message "wall" is enabled,
        whether or not the sysop is notified of new "likes" and
        replies, and whether or not the activity is published via the
        MQTT broker.

        If WALLFLAGS is omitted, the wall is disabled.

</code> **OPTIONS** <code>
        The argument to WALLFLAGS is a decimal number, which is the
        sum of the desired options from the following list:

            1 - Enable wall
            2 - Notify sysop (via PMS) of new posts / replies
            4 - Publish new posts / replies via MQTT

</code> **SEE ALSO** <code>
        WALL(1)        -- Access Message Wall / Guestbook.
        MQTT-SRV(9)    -- MQTT Server / Broker
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== WARNCOLOR ====
<code>WARNCOLOR(7)          XROUTER REFERENCE MANUAL              26/10/2023

</code> **NAME** <code>
        WARNCOLOR -- Colour For Warnings and Errors.

</code> **SYNOPSIS** <code>
        WARNCOLOR=<colour>

</code> **DESCRIPTION** <code>
        WARNCOLOR is an optional directive that can be used both
        in the "global" section of XROUTER.CFG, and within CONSOLE
        definition blocks.

        It specifies the colour used by XRouter for warning and
        error messages, such as "Invalid port", "Syntax error",
        "System busy", and so on.

        If used in the "global" section of XROUTER.CFG, the setting
        is inherited by all CONSOLEs subsequently defined.

        If used within a CONSOLE definition block, it applies only
        to that console, overriding any inherited setting.

        The default WARNCOLOR is CERISE.  Default colours have
        been carefully chosen for good visibility against a BLACK
        background.

</code> **OPTIONS** <code>
        <colour> should be one of the 16 colour names described in
        COLOURS(6), but please note that some colour combinations
        have very poor visibility.

        In general, the lighter the background colour, the smaller
        the choice of foreground colours that will work with it.

</code> **EXAMPLE** <code>
        WARNCOLOR=PINK

</code> **SEE ALSO** <code>
        ANSI(1)         -- Enquire/set ANSI colour mode
        COLOURS(6)      -- XRouter Display Colours.
        CONSOLES(6)     -- About XRouter Consoles.
        ACTIONCOLOR(7)  -- Colour For XRouter Actions and Events.
        CAPTIONCOLOR(7) -- Colour For Captions and Headings.
        PROMPTCOLOR(7)  -- Colour For XRouter Prompts.
        XROUTER.CFG(8)  -- Main Configuration File.

</code>
----
==== WXFILE ====
<code>WXFILE(7)               XROUTER REFERENCE MANUAL             26/9/2023

</code> **NAME** <code>
        WXFILE -- Specify Weather Import File.

</code> **SYNOPSIS** <code>
        WXFILE=[path/]<filename]

</code> **DESCRIPTION** <code>
        WXFILE is an optional "global" directive used in XROUTER.XFG.

        It specifies the filename (and if necessary the path to it),
        of a file that contains weather data in WXNOW, CUMULUS or
        "<name>: <value>" format, generated by home weather stations
        or weather applications.

        Once per minute, if the specified file exists, XRouter reads
        its contents into its weather database, making it available
        to the WX command and the NetRomX Weather service.. 

</code> **EXAMPLE** <code>
        WXFILE=/etc/wxnow.txt

</code> **SEE ALSO** <code>
        WX(1)          -- Obtain Weather Information.
        WX-SVC(9)      -- NetRomX Weather Service
        XROUTER.CFG(8) -- Main Configuration File.

</code>
----
==== WXMAXAGE ====
<code>WXMAXAGE(7)             XROUTER REFERENCE MANUAL            31/10/2024

</code> **NAME** <code>
        WXMAXAGE -- Specify Maximum Age of a Weather Record.

</code> **SYNOPSIS** <code>
        WXMAXAGE=<seconds>

</code> **DESCRIPTION** <code>
        WXMAXAGE is an optional "global" directive used in XROUTER.XFG.

        It specifies the maximum lifetime of a weather record, in
        seconds since the time of observation.  Records older than the
        maximum lifetime are purged.

        If not specified, the default lifetime is 21600 seconds, i.e.
        6 hours.

</code> **EXAMPLE** <code>
        WXMAXAGE=3600  - Sets max lifetime to 1 hour

</code> **SEE ALSO** <code>
        WX(1)          -- Obtain Weather Information.
        WX-SVC(9)      -- NetRomX Weather Service
        XROUTER.CFG(8) -- Main Configuration File.

</code> **WXMAXAGE(7)                  END OF DOCUMENT** <code>
</code>
----
==== WXMAXRECS ====
<code>WXMAXRECS(7)            XROUTER REFERENCE MANUAL            31/10/2024

</code> **NAME** <code>
        WXMAXRECS -- Specify Maximum Number of Weather Records.

</code> **SYNOPSIS** <code>
        WXMAXRECS=<0-255>

</code> **DESCRIPTION** <code>
        WXMAXRECS is an optional "global" directive used in XROUTER.XFG.

        It specifies the maximum number of weather records to retain,
        one for each weather "station" (source).

        Records are stored in order of distance from XRouter, i.e. only
        the records from the WXMAXRECS closest weather stations are
        retained.

        If the list is full, new reports from stations further than the
        most distant one are ignored.  If a new report arrives from a
        closer station, the most distant one is deleted.
        
        If not specified, the default value is 5.

</code> **EXAMPLE** <code>
        WXMAXRECS=25   - Store a maxium of 25 weather records

</code> **SEE ALSO** <code>
        WX(1)          -- Obtain Weather Information.
        WX-SVC(9)      -- NetRomX Weather Service
        XROUTER.CFG(8) -- Main Configuration File.

</code> **WXMAXRECS(7)                 END OF DOCUMENT** <code>
</code>
----