packet:xrouter:docs:section7-configurationdirectives
Table of Contents
Section 7 - Configuration Directives
ACTIONCOLOR
ACTIONCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023
NAME
ACTIONCOLOR -- Colour For XRouter Actions and Events.
SYNOPSIS
ACTIONCOLOR=<colour>
DESCRIPTION
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.
OPTIONS
<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.
EXAMPLE
ACTIONCOLOR=PINK
SEE ALSO
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.
AGWPORT
AGWPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
AGWPORT -- TCP Port for AGW Emulator.
SYNOPSIS
AGWPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
AGWHOST(6) -- AGW Emulator.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
ALTITUDE
ALTITUDE(7) XROUTER REFERENCE MANUAL 20/9/2023
NAME
ALTITUDE -- Site altitude above mean sea level.
SYNOPSIS
ALTITUDE=<metres>
DESCRIPTION
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.
EXAMPLE
ALTITUDE=46 -- Site is 46 metres above mean sea level.
SEE ALSO
HAAT(7) -- Antenna Height Above Average Terrain.
XROUTER.CFG(8) -- Main Configuration File.
APPLMASK
APPLMASK(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
APPLMASK -- Application Connectivity Mask.
DESCRIPTION
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.
SEE ALSO
APPLMASK(1) -- APPLMASK Command
PORTS(6) -- Ports in XRouter.
APPLS(9) -- Application Support.
XROUTER.CFG(8) -- Main Configuration File.
APRSPATH
APRSPATH(7) XROUTER REFERENCE MANUAL 23/9/2023
NAME
APRSPATH -- Default Digipeater Path for APRS.
SYNOPSIS
APRSPATH=<digipeater>[,digipeater[,digipeater...]]
DESCRIPTION
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.
EXAMPLE
APRSPATH=RELAY,WIDE
SEE ALSO
AMSG(1) -- APRS Mesaging Mode.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
APRSPORT
APRSPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
APRSPORT -- TCP Port for APRS Server.
SYNOPSIS
APRSPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
AUDIODEVICE
AUDIODEVICE(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
AUDIODEVICE -- Specify audio device name.
SYNOPSIS
AUDIODEVICE=<devicename>
AVAILABILITY
Used only in XROUTER.CFG.
DESCRIPTION
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.
EXAMPLE
# Audio device for sound output:
# Default OSS device is /dev/dsp (/dev/audio on Rasp pi)
#
AUDIODEVICE=/dev/dsp
#
CAVEATS
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"
SEE ALSO
AUDIO(9) -- Audio on XRouter
BELL(1) -- Set acceptable hours for console sounds.
XROUTER.CFG(8) -- Main Configuration File.
BCAST
BCAST(7) XROUTER REFERENCE MANUAL 23/9/2023
NAME
BCAST -- Destinations for UI Broadcasting.
SYNOPSIS
BCAST=<dest>[,dest]...
AVAILABILITY
Sysop-only.
DESCRIPTION
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!
OPTIONS
The destination addresses must be separated by commas and
there must be no spaces in the list.
EXAMPLE
BCAST=MAIL,ALL
SEE ALSO
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.
BCFROM
BCFROM(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
BCFROM -- Approved UI Broadcasters.
SYNOPSIS
BCFROM=<callsign>[,callsign..]
DESCRIPTION
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).
OPTIONS
The argument to BCFROM is a single callsign, or a comma
separated list of callsigns. There must be no spaces in the
list.
EXAMPLE
BCFROM=GB7PZT,GB7MAX
SEE ALSO
BCAST(7) -- Destinations for UI Broadcasting.
BCAST(9) -- About UI Broadcasting.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
BLEVEL
BLEVEL(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
BLEVEL -- Netrom Budlist de-rate level.
SYNOPSIS
BLEVEL=n (where n is berween 0 and 255)
DESCRIPTION
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.
AVAILABILITY
Sysop-only.
NOTE
A command of the same name can be used at runtime.
SEE ALSO
BLEVEL(1) -- L3 Budlist de-rate level command.
L3EXCLUDE(7) -- Level 3 Exclusion List.
XROUTER.CFG(8) -- Main Configuration File.
BLOGFLAGS
BLOGFLAGS(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
BLOGFLAGS -- Options For Sysop's Blog.
SYNOPSIS
BLOGFLAGS=n (where 0 <= n <= 15)
DESCRIPTION
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.
OPTIONS
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
SEE ALSO
BLOG(1) -- Access Sysop's Blog.
MQTT-SRV(9) -- MQTT Server / Broker
XROUTER.CFG(8) -- Main Configuration File.
BOOTWIN
BOOTWIN(7) XROUTER REFERENCE MANUAL 21/9/2023
NAME
BOOTWIN -- Window to display after bootup.
SYNOPSIS
BOOTWIN=n (where n is 1 to 12 inclusive)
DESCRIPTION
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)
SEE ALSO
BOOTCMDS.SYS(8) -- Commands executed at boot up
XROUTER.CFG(8) -- Main configuration file
CAPTIONCOLOR
CAPTIONCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023
NAME
CAPTIONCOLOR -- Colour For Captions and Headings.
SYNOPSIS
CAPTIONCOLOR=<colour>
DESCRIPTION
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.
OPTIONS
<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.
EXAMPLE
CAPTIONCOLOR=CYAN
SEE ALSO
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.
CFLAGS
CFLAGS(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
CFLAGS -- Connection Control Flags.
SYNOPSIS
CFLAGS=n (n = 0 - 255)
AVAILABILITY
Used in PORT configuration blocks within XROUTER.CFG.
DESCRIPTION
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.
OPTIONS
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.
EXAMPLES
CFLAGS=2 - Allow downlinking only
CFLAGS=5 - Allow only sysops and apps to downlink.
FILES
xrouter.cfg
SEE ALSO
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.
CHANNEL
CHANNEL(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
CHANNEL -- Channel to Use on Interface.
SYNOPSIS
CHANNEL=<letter A to P>
DESCRIPTION
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.
OPTIONS
The argument to CHANNEL is a letter between A and P
inclusive. The default is channel A.
EXAMPLE
CHANNEL=C ; 3rd channel
SEE ALSO
IFACES(6) -- Interfaces in XRouter.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
CHATALIAS
CHATALIAS(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
CHATALIAS -- Alias for Chat Server.
SYNOPSIS
CHATALIAS=<alias>
DESCRIPTION
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.
EXAMPLE
CHATALIAS=IOWCHT
CAVEATS
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.
SEE ALSO
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.
CHATCALL
CHATCALL(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
CHATCALL -- Callsign for Chat Server.
SYNOPSIS
CHATCALL=<callsign>
DESCRIPTION
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.
EXAMPLE
CHATCALL=G8PZT-8
CAVEATS
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.
SEE ALSO
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.
CHATPORT
CHATPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
CHATPORT -- TCP Port for CHAT Server.
SYNOPSIS
CHATPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
COLS
COLS(7) XROUTER REFERENCE MANUAL 19/10/2023
NAME
COLS -- Set Display Width (deprecated).
SYNOPSIS
COLS=n (n = 40-120)
DESCRIPTION
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.
CAVEATS
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.
SEE ALSO
ROWS(7) -- Set Display Height.
XROUTER.CFG(8) -- Main Configuration File.
CONSOLELANG
CONSOLELANG(7) XROUTER REFERENCE MANUAL 29/10/2023
NAME
CONSOLELANG -- Default Language.
SYNOPSIS
CONSOLELANG=<language number>
DESCRIPTION
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..
EXAMPLE
CONSOLELANG=2 -- Sets console language to SPANISH
SEE ALSO
CONSOLES(6) -- About XRouter Consoles.
DEFAULTLANG(7) -- Default language
LANGS.SYS(8) -- Language selection file
XROUTER.CFG(8) -- Main configuration file
CONTACT
CONTACT(7) XROUTER REFERENCE MANUAL 20/9/2023
NAME
CONTACT -- Sysop's contact details.
SYNOPSIS
CONTACT=<email / website / packet / phone etc>
DESCRIPTION
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.
EXAMPLES
[email protected] CONTACT=www.wmpkt.org/contacts CONTACT=PO Box 43, Dudley,West Midlands
SEE ALSO
MAPCOMMENT(7) -- Short text to display on map.
XROUTER.CFG(8) -- Main Configuration File.
CTEXT
CTEXT(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
CTEXT -- Set "Connect Text".
SYNOPSIS
CTEXT
<text>
***
CTEXT=<text>
DESCRIPTION
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".
SEE ALSO
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.
CTFLAGS
CTFLAGS(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
CTFLAGS -- Connection Text Control Flags.
SYNOPSIS
CTFLAGS=n (where n is 0-15)
DESCRIPTION
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).
NOTE
The CTFLAGS *command* allows the texts to be changed "on the
fly".
SEE ALSO
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.
CWID
CWID(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
CWID -- Morse Code Identification.
SYNOPSIS
CWID=<callsign>
DESCRIPTION
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.
OPTIONS
The <callsign> consists of up to 8 characters. Only upper
case alphanumeric characters and forward slash (/) are
acceptable.
EXAMPLES
CWID=GB7PZT
CWID=G8PZT/M
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
DEFAULTLANG
DEFAULTLANG(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
DEFAULTLANG -- Default Language.
SYNOPSIS
DEFAULTLANG=<language number>
DESCRIPTION
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
EXAMPLE
DEFAULTLANG=1 -- Sets default language to FRENCH
SEE ALSO
CONSOLELANG(7) -- Console language
LANGS.SYS(8) -- Language selection file
XROUTER.CFG(8) -- Main configuration file
DHCP
DHCP(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
DHCP -- Obtain Port IP Using DHCP.
SYNOPSIS
DHCP=n (where n is 0 or 1)
DESCRIPTION
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.
SEE ALSO
DHCP(1) -- Display DHCP-obtained IP configuration.
DHCP(9) -- Dynamic Host Configuration Protocol.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
DIGIFLAG
DIGIFLAG(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
DIGIFLAG -- Digipeating Options.
SYNOPSIS
DIGIFLAG=n (where n is a number from 0 to 1023)
DESCRIPTION
DIGIFLAG is an optional PORT configuraton directive which
controls digipeating on that port. (0=none, default=7).
OPTIONS
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)
EXAMPLE
DIGIFLAG=5 ; Digipeat UI + RELAY generic.
NOTES
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.
SEE ALSO
DIGIFLAG(1) -- Display / Set digipeat options.
DIGIPORT(7) -- Destination Port for Digipeating.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
DIGIPORT
DIGIPORT(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
DIGIPORT -- Destination Port for Digipeated Frames.
SYNOPSIS
DIGIPORT=<port_number>
DESCRIPTION
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.
EXAMPLE
DIGIPORT=3 ; Digipeat from this port onto port 3
LIMITATIONS
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.
SEE ALSO
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.
DISCARDPORT
DISCARDPORT(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
DISCARDPORT -- TCP Port for DISCARD Server.
SYNPOSIS
DISCARDPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
DISC-SRV(9) -- Discard Server.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
DXFLAGS
DXFLAGS(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
DXFLAGS -- DX List Control Flags.
SYNOPSIS
DXFLAGS=n (where n is a decimal number)
DESCRIPTION
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)
***
CAVEATS
If XRouter's position has not been defined, the program will
not start.
SEE ALSO
DX(1) -- Show Distant Stations
XROUTER.CFG(8) -- Main Configuration File.
DYNDNS
DYNDNS(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
DYNDNS -- Enable / Disable Dynamic DNS Update Client.
SYNOPSIS
DYNDNS=<0|1>
DESCRIPTION
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.
CAVEATS
This directive most only be used on ONE port. It may crash
XRouter if you try to use it on more than one.
SEE ALSO
DYNDNS(9) -- Dynamic DNS Update Client
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
ECHOPORT
ECHOPORT(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
ECHOPORT -- TCP Port for ECHO Server.
SYNOPSIS
ECHOPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
EXCLUDE
EXCLUDE(7) XROUTER REFERENCE MANUAL 24/9/2023
COMMAND
EXCLUDE -- AX25 Blacklist.
SYNOPSIS
EXCLUDE=<callsign>[,<callsign>...]
DESCRIPTION
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.
EXAMPLE
EXCLUDE=NOCALL,P1RAT ; Ignore these users
SEE ALSO
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.
FEC
FEC(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
FEC -- Enable / disable Forward Error Correction.
SYNOPSIS
FEC=<0|1>
DESCRIPTION
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.
CAVEATS
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.
SEE ALSO
FEC(1) -- Control Forward Error Correction.
CFLAGS(7) -- Connection Control Flags.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
FINGERPORT
FINGERPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
FINGERPORT -- TCP Port for FINGER Server.
SYNOPSIS
FINGERPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
FRACK
FRACK(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
FRACK -- AX25 Frame Acknowledgement Time.
SYNOPSIS
FRACK=<milliseconds>
DESCRIPTION
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.
EXAMPLE
FRACK=7000 ; 7 seconds
SEE ALSO
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.
FREQUENCY
FREQUENCY(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
FREQUENCY -- Radio frequency used by RF port.
SYNOPSIS
FREQUENCY=<radio frequency in Hz>
DESCRIPTION
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.
EXAMPLE
FREQUENCY=144925000 -- 144.925 MHz
SEE ALSO
RADIO(7) -- Rig control block
XROUTER.CFG(8) -- Main Configuration File.
FTPPORT
FTPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
FTPPORT -- TCP Port for FTP Server.
SYNOPSIS
FTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
FTP-SRV(9) -- FTP server.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
FULLDUP
FULLDUP(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
FULLDUP -- Full Duplex.
SYNOPSIS
FULLDUP=<0|1>
DESCRIPTION
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..
EXAMPLE
FULLDUP=1 ; Full duplex
SEE ALSO
FULLDUP(1) -- Display / Set full duplex mode.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
HAAT
HAAT(7) XROUTER REFERENCE MANUAL 20/9/2023
NAME
HAAT -- Antenna Height Above Average Terrain.
SYNOPSIS
HAAT=<metres>
DESCRIPTION
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.
EXAMPLES
HAAT=-15 -- Antenna is 15 metres BELOW averaged terrain.
HAAT=12 -- Antenna is 12 metres ABOVE avareaged terrain.
NOTE
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.
SEE ALSO
ALTITUDE(7) -- Base height of site.
XROUTER.CFG(8) -- Main Configuration File.
HTTPPORT
HTTPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
HTTPPORT -- TCP Port for HTTP Server.
SYNOPSIS
HTTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
ID
ID(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
ID -- Text to Identify Port.
SYNOPSIS
ID=<descriptive text>
DESCRIPTION
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.
EXAMPLE
ID=144.825 MHz 9k6 TCP/IP users
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
IDINTERVAL
IDINTERVAL(7) XROUTER REFERENCE MANUAL 22/10/2023
NAME
IDINTERVAL -- Identification Beacon Interval.
SYNOPSIS
IDINTERVAL=<minutes>
DESCRIPTION
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.
SEE ALSO
IDPATH(7) -- Identification Beacon Path
IDTEXT(7) -- Identification Beacon Text.
XROUTER.CFG(8) -- Main Configuration File.
IDPATH
IDPATH(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
IDPATH -- Destination and Digipeater Path for ID beacons.
SYNOPSIS
IDPATH=<destination>[,digipeater,digipeater...]
DESCRIPTION
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.
EXAMPLE
IDPATH=APRS,RELAY,WIDE
SEE ALSO
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.
IDTEXT
IDTEXT(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
IDTEXT -- Identification Text.
SYNOPSIS
IDTEXT }
<text> } "global" idtext
*** }
IDTEXT=<text> <-- "port" idtext
DESCRIPTION
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.
NOTE
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,
EXAMPLE
IDTEXT=!5224.00N/00215.00W# (Kidder)
SEE ALSO
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.
INITSTR
INITSTR(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
INITSTR -- Modem Initialisation String.
SYNOPSIS
INITSTR=<string of text>
DESCRIPTION
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).
EXAMPLE
INITSTR=ATM0
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
INTERFACENUM
INTERFACENUM(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
INTERFACENUM -- Interface Number.
SYNOPSIS
INTERFACENUM=<interface_number>
DESCRIPTION
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.
EXAMPLE
PORT=7
INTERFACENUM=5 ; Port is attached to interface 5
MTU=256
ENDPORT
SEE ALSO
IFACES(6) -- Interfaces in XRouter.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
INTERLOCK
INTERLOCK(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
INTERLOCK -- Transmitter Interlock.
SYNOPSIS
INTERLOCK=<number>
DESCRIPTION
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.
EXAMPLE
INTERLOCK=4
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
IPADDRESS
IPADDRESS(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
IPADDRESS -- Main or Port IP Address.
SYNOPSIS
IPADDRESS=<ip_address>
DESCRIPTION
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.
EXAMPLE
IPADDRESS=44.131.91.5
CAVEATS
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.
SEE ALSO
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.
IPLINK
IPLINK(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
IPLINK -- Peer Address of a Link.
SYNOPSIS
IPLINK=<ip_address_or_hostname>
DESCRIPTION
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.
EXAMPLES
IPLINK=62.51.67.21
IPLINK=gb7pzt.dyndns.org
SEE ALSO
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.
KEEPALIVE
KEEPALIVE(7) XROUTER REFERENCE MANUAL 22/3/2024
NAME
KEEPALIVE -- AXUDP / AXIP Keepalive interval.
SYNOPSIS
KEEPALIVE=<secs>
DESCRIPTION
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.
EXAMPLE
KEEPALIVE=120 ; 2 minutes between keepalives
SEE ALSO
AXIP(9) -- AX25-over-IP Tunnelling.
AXUDP(9) -- AX25-over-UDP Tunnelling.
KEEPALIVE(1) -- Display / Change Keepalive Interval.
XROUTER.CFG(8) -- Main Configuration File.
L3EXCLUDE
L3EXCLUDE(7) XROUTER REFERENCE MANUAL 4/9/2023
NAME
L3EXCLUDE -- Level 3 Exclusion List.
SYNOPSIS
L3EXCLUDE=callsign[,callsign,callsign...]
DESCRIPTION
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.
EXAMPLE
L3EXCLUDE=N3UOO-5,G9ABC
SEE ALSO
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.
L4T3
L4T3(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
L4T3 -- NetRom Layer 4 link check interval.
SYNOPSIS
L4T3=<seconds>
DESCRIPTION
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.
EXAMPLE
L4T3=600 -- Set link check interval to 10 minutes
SEE ALSO
XROUTER.CFG(8) -- Main Configuration File.
LATITUDE
LATITUDE(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
LATITUDE -- Set XRouter's geographic latitude
SYNOPSIS
LATITUDE=n (where n is between -90.0 and 90.0)
DESCRIPTION
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.
OPTIONS
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.
EXAMPLE
LATITUDE=52.4 -- An imprecise northern latitude
LATITUDE=-77.6342 -- A more precise southern latitude
SEE ALSO
IDTEXT(1) -- Display / Set ID beacon text
LOCATOR(7) -- Maidenhead QTH locator
LONGITUDE(7) -- Geographic longitude
XROUTER.CFG(8) -- Main Configuration File
LEARN
LEARN(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
LEARN -- Learn Unsolicited AX*P Peer Details.
SYNOPSIS
LEARN=1
DESCRIPTION
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".
OPTIONS
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.
SEE ALSO
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
LOCATOR
LOCATOR(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
LOCATOR -- Maidenhead QTH locator
SYNOPSIS
LOCATOR=LLddLL[dd] (where L is a letter and d is a digit)
DESCRIPTION
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.
OPTIONS
The argument to LOCATOR is a 6 or 8 character "Maidenhead"
locator, e.g. "IO82VJ" or "IO75GH65"
EXAMPLE
LOCATOR=IO82VJ -- Kidderminster UK
SEE ALSO
IDTEXT(1) -- Display / Set ID beacon text
LATITUDE(7) -- Geographic latitude
LONGITUDE(7) -- Geographic longitude
XROUTER.CFG(8) -- Main Configuration File
LOG
LOG(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
LOG -- Activity logging options
SYNOPSIS
LOG=n (where n is between 0 and 16383)
DESCRIPTION
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.
OPTIONS
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
EXAMPLES
LOG=7 -- Log session activity, using CRLF line endings
LOG=65 -- Log Netrom L3 only, using LF line endings
SEE ALSO
LOG(1) -- Activity logging control command
XROUTER.CFG(8) -- Main configuration file
LOG(7) END OF DOCUMENT
LONGITUDE
LONGITUDE(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
LONGITUDE -- Set XRouter's geographic longitude
SYNOPSIS
LONGITUDE=n (where n is between -180.0 and 180.0)
DESCRIPTION
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.
OPTIONS
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.
EXAMPLE
LONGITUDE=2.5 -- An imprecise eastern longitude
LONGITUDE=-5.205 -- A more precise western longitude
SEE ALSO
IDTEXT(1) -- Display / Set ID beacon text
LATITUDE(7) -- Geographic latitude
LOCATOR(7) -- Maidenhead QTH locator
XROUTER.CFG(8) -- Main Configuration File
MAPCOMMENT
MAPCOMMENT(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
MAPCOMMENT -- Short text to display on map.
SYNOPSIS
MAPCOMMENT=<text string which may contain spaces>
DESCRIPTION
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.
EXAMPLES
MAPCOMMENT=XRLin (XRouter for x86 Linux) alpha test node
MAPCOMMENT=Beacon Hill, Trunking Only
SEE ALSO
CONTACT(7) -- Sysop's contact details.
XROUTER.CFG(8) -- Main Configuration File
MAPCOMMENT(7) END OF DOCUMENT
MAPSERVADDR
MAPSERVADDR(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
MAPSERVADDR -- Hostname / IP address of mapping server.
SYNOPSIS
MAPSERVADDR=<ip_address_or_hostname_of_mapping_server>
DESCRIPTION
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.
SEE ALSO
MAPCOMMENT(7) -- Short text to display on map.
MAPSERVPORT(7) -- TCP port of mapping server
XROUTER.CFG(8) -- Main configuration file
MAPSERVPORT
MAPSERVPORT(7) XROUTER REFERENCE MANUAL 6/9/2023
NAME
MAPSERVPORT -- TCP port of mapping server.
SYNOPSIS
MAPSERVPORT=n (where n is between 0 and 65535)
DESCRIPTION
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.
SEE ALSO
MAPSERVADDR(7) -- Address of mapping server
XROUTER.CFG(8) -- Main configuration file
MAXFRAME
MAXFRAME(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
MAXFRAME -- Maximum Unacked AX25 Frames.
SYNOPSIS
MAXFRAME=n (where n is in the range 1 to 63)
DESCRIPTION
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.
OPTIONS
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.
EXAMPLE
MAXFRAME=4
SEE ALSO
MAXFRAME(1) -- Display / Set port MAXFRAME value.
PACLEN(7) -- Maximum AX25 Packet Length.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
MAXHOPS
MAXHOPS(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
MAXHOPS -- Set Hopcount Horizon.
SYNOPSIS
MAXHOPS=n (n = 0-30)
AVAILABILITY
Used only in XROUTER.CFG.
DESCRIPTION
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.
CAVEATS
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.
SEE ALSO
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.
MAXLINKS
MAXLINKS(7) XROUTER REFERENCE MANUAL 24/10/2023
NAME
MAXLINKS -- Maximum Simultaneous AX25 L2 links.
SYNOPSIS
MAXLINKS=n (n=0-65535)
DESCRIPTION
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.
EXAMPLE
MAXLINKS=50
SEE ALSO
SESSLIMIT(7) -- Maximum Simultaneous Connections on Port.
XROUTER.CFG(8) -- Main Configuration File.
MAXTT
MAXTT(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
MAXTT -- Maximum Trip Time.
SYNOPSIS
MAXTT=n (n = 0-60000)
AVAILABILITY
Used only in XROUTER.CFG.
DESCRIPTION
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.
CAVEATS
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.
SEE ALSO
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.
MHEARD
MHEARD(7) XROUTER REFERENCE MANUAL 21/9/2023
NAME
MHEARD -- Enable MHeard & set size.
SYNOPSIS
MHEARD=<size> (where <size> is a number between 0 and 50)
DESCRIPTION
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.
EXAMPLES
MHEARD=10 ; Enable MHeard, 10 callsigns max
MHEARD=0 ; Disable MHeard
SEE ALSO
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".
MHFLAGS
MHFLAGS(7) XROUTER REFERENCE MANUAL 18/10/2023
NAME
MHFLAGS -- MHeard option flags.
SYNOPSIS
MHFLAGS=n (where n is a number between 0 and 255)
DESCRIPTION
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.
OPTIONS
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).
EXAMPLES
MHFLAGS=3 ; Directly heard stations & digipeaters only
MHFLAGS=4 ; Digipeated stations only
SEE ALSO
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".
MINQUAL
MINQUAL(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
MINQUAL -- Minimum Quality to Add to Nodes Table.
SYNOPSIS
MINQUAL=n (where n is in the range 0 to 255)
DESCRIPTION
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.
EXAMPLE
MINQUAL=100 ; No nodes less than quality 100
SEE ALSO
MINQUAL(1) -- Display / Set port minimum quality
PORTS(6) -- Ports in XRouter.
QUALITY(7) -- NetRom Quality
XROUTER.CFG(8) -- Main Configuration File.
MINTXQUAL
MINTXQUAL(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
MINTXQUAL -- Minimum Quality to Broadcast.
SYNOPSIS
MINTXQUAL=n (where n is in the range 0 to 255)
DESCRIPTION
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.
EXAMPLE
MINTXQUAL=100 ; Don't broadcast nodes with quality <100
SEE ALSO
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.
MQTTPORT
MQTTPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
MQTTPORT -- TCP Port for MQTT Server/Broker.
SYNPOSIS
MQTTPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
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.
MQTTSERVADDR
MQTTSERVADDR(7) XROUTER REFERENCE MANUAL 23/9/2023
NAME
MQTTSERVADDR -- Hostname / IP address of external MQTT Broker.
SYNOPSIS
MQTTSERVADDR=<ip_address_or_hostname_of_mqtt_broker>
DESCRIPTION
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.
EXAMPLES
MQTTSERVADDR=192.168.1.20
MQTTSERVADDR=test.mosquitto.org
SEE ALSO
MQTT-PUB(9) -- MQTT Publisher.
MQTTSERVPORT(7) -- TCP Port of external MQTT Broker
XROUTER.CFG(8) -- Main configuration file
MQTTSERVPORT
MQTTSERVPORT(7) XROUTER REFERENCE MANUAL 23/9/2023
NAME
MQTTSERVPORT -- TCP Port of External MQTT Broker.
SYNOPSIS
MQTTSERVPORT=n (where n is between 0 and 65535)
DESCRIPTION
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.
EXAMPLE
MQTTSERVADDR=2884
SEE ALSO
MQTT-PUB(9) -- MQTT Publisher.
MQTTSERVADDR(7) -- Hostname / IP of External MQTT Broker.
XROUTER.CFG(8) -- Main configuration file.
NETMASK
NETMASK(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
NETMASK -- Subnet Mask.
SYNOPSIS
NETMASK=<netmask>
DESCRIPTION
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.
EXAMPLE
NETMASK=255.255.255.0
SEE ALSO
IPADDRESS(7) -- Main or Port IP Address.
NETMASK(1) -- Display / Set Port NETMASK.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
NODEALIAS
NODEALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
NODEALIAS -- Primary AX25 / NetRom Alias.
SYNOPSIS
NODEALIAS=<alias>
DESCRIPTION
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.
EXAMPLES
NODEALIAS=KIDDER ; Kidderminster
NODEALIAS=PZTXRP ; G8PZT's XRPi
SEE ALSO
NODECALL(7) -- Primary AX25 / Netrom Callsign.
PORTALIAS(7) -- Additional Alias for a Port.
XROUTER.CFG(8) -- Main Configuration File.
NODECALL
NODECALL(7) XROUTER REFERENCE MANUAL 23/10/2023
NAME
NODECALL -- Primary AX25 / NetRom Callsign.
SYNOPSIS
NODECALL=<callsign>[-ssid]
DESCRIPTION
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.
EXAMPLE
NODECALL=GB7PZT-12
SEE ALSO
NODEALIAS(7) -- Primary AX25 / Netrom Alias.
PORTCALL(7) -- Port Callsign.
XROUTER.CFG(8) -- Main Configuration File.
NODESINT
NODESINT(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
NODESINTERVAL -- Nodes Broadcast Interval.
SYNOPSIS
NODESINTERVAL=<minutes>
DESCRIPTION
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.
OPTIONS
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.
EXAMPLE
NODESINTERVAL=10 ; 10 minues between broadcasts
SEE ALSO
NODESINT(1) -- Display / Set NODESINTERVAL.
PORTS(6) -- Ports in XRouter.
QUALITY(7) -- NetRom Quality
XROUTER.CFG(8) -- Main Configuration File.
PACLEN
PACLEN(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PACLEN -- Maximum Packet Length.
SYNOPSIS
PACLEN=n (where n is in the range 0 to 256)
DESCRIPTION
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.
OPTIONS
If the port PACLEN is set to 0, Xrouter dynamically adapts
PACLEN (and MAXFRAME) to the link conditions, to maximise
throughput.
EXAMPLE
PACLEN=160 ; Allow 160 byte packets
SEE ALSO
MAXFRAME(7) -- Maximum Unacked AX25 Frames.
PACLEN(1) -- Display / Set Paclen.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
PEER
PEER(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
PEER -- Specify AXIP / AXUDP Link Partner.
SYNOPSIS
PEER=<callsign>[:alias] <ipaddress | hostname> <udp_port>
DESCRIPTION
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.
OPTIONS
<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.
EXAMPLES
# 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
SEE ALSO
AXIP(9) -- AX25 over IP
AXUDP(9) -- AX25 over UDP
LEARN(7) -- Learn Unsolicited AX*P Peer Details.
XROUTER.CFG(8) -- Main Configuration File
PERSIST
PERSIST(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PERSIST -- AX25 Probablity to Transmit.
SYNOPSIS
PERSIST=n (n=0-255)
DESCRIPTION
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.
EXAMPLES
PERSIST=25 ; 10% probability / 10 stations
PERSIST=128 ; 50% probability / 2 stations
SEE ALSO
PERSIST(1) -- Display / Set Port Persist.
PORTS(6) -- Ports in XRouter.
SLOTTIME(7) -- CSMA interval timer
XROUTER.CFG(8) -- Main Configuration File.
PIPE
PIPE(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PIPE -- Frame Pipe.
SYNOPSIS
PIPE=<destination_port_number> [callsign,callsign...]
DESCRIPTION
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.
EXAMPLES
PIPE=2 ; Pipe frames from this port to port 2
PIPE=4 GB7PZT,KDRBBS ; Selective pipe to port 4
SEE ALSO
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.
PIPEFLAG
PIPEFLAG(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PIPEFLAG -- Frame Pipe Option Flags.
SYNOPSIS
PIPEFLAG=n (where n is in the range 0 to 1023)
DESCRIPTION
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.
OPTIONS
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
EXAMPLES
PIPEFLAG=5 ; Pipe received UI frames only
PIPEFLAG=517 ; Bi-directional UI pipe
SEE ALSO
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.
PMSALIAS
PMSALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PMSALIAS -- Alias for Personal Mail System.
SYNOPSIS
PMSALIAS=<alias>
DESCRIPTION
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.
EXAMPLES
PMSALIAS=IOWPMS
PMSALIAS=PZTPMS
CAVEATS
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.
SEE ALSO
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.
PMSCALL
PMSCALL(7) XROUTER REFERENCE MANUAL 24/9/2023
NAME
PMSCALL -- Callsign for Personal Message System.
SYNOPSIS
PMSCALL=<callsign>
DESCRIPTION
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.
EXAMPLE
PMSCALL=G8PZT-2
CAVEATS
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.
SEE ALSO
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.
PMSHADDR
PMSHADDR(7) XROUTER REFERENCE MANUAL 29/3/2024
NAME
PMSHADDR -- Hierarchical Address of PMS.
SYNOPSIS
PMSHADDR=<h_address>
DESCRIPTION
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.
EXAMPLE
PMSHADDR=.#24.GBR.EU
SEE ALSO
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.
PMSQUAL
PMSQUAL(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
PMSQUAL -- NetRom Quality for Personal Message System.
SYNOPSIS
PMSQUAL=n (n=0-255)
DESCRIPTION
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.
EXAMPLE
PMSQUAL=50
SEE ALSO
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.
PMSTYPE
PMSTYPE(7) XROUTER REFERENCE MANUAL 29/3/2024
NAME
PMSTYPE -- Set PMS / BBS mode.
SYNOPSIS
PMSTYPE=n (n=0-4)
DESCRIPTION
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.
OPTIONS
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.
EXAMPLES
PMSTYPE=1 - Normal PMS
PMSTYPE=3 - BBS masqurading as a PMS
SEE ALSO
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.
PORTALIAS2
PORTALIAS2(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PORTALIAS2 -- Secondary Alias for a Port.
SYNOPSIS
PORTALIAS2=<alias>
DESCRIPTION
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.
EXAMPLE
PORTALIAS2=KRDIGI
SEE ALSO
PORTALIAS(7) -- Additional Port Alias.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
PORTALIAS
PORTALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PORTALIAS -- Additional Alias for a Port.
SYNOPSIS
PORTALIAS=<alias>
DESCRIPTION
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.
EXAMPLE
PORTALIAS=KDRMIN
SEE ALSO
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.
PORTCALL
PORTCALL(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
PORTCALL -- Additional Callsign for a Port.
SYNOPSIS
PORTCALL=<callsign>[-ssid]
DESCRIPTION
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.
EXAMPLE
PORTCALL=GB7PZT-1
SEE ALSO
NODECALL(7) -- Node Main Callsign.
PORTALIAS(7) -- Port Alias.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
PROMPTCOLOR
PROMPTCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023
NAME
PROMPTCOLOR -- Colour For XRouter Prompts.
SYNOPSIS
PROMPTCOLOR=<colour>
DESCRIPTION
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.
OPTIONS
<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.
EXAMPLE
PROMPTCOLOR=YELLOW
SEE ALSO
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.
PROTOCOL
PROTOCOL(7) XROUTER REFERENCE MANUAL 24/10/2023
NAME
PROTOCOL -- Protocol Used on INTERFACE.
SYNPOSIS
PROTOCOL=<protocol>
DESCRIPTION
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.
OPTIONS
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.
NOTE
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!
SEE ALSO
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.
PROXY
PROXY(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
PROXY -- Proxy Connectivity.
SYNOPSIS
PROXY=<call1>[,call2,...]
PROXY=<call> <alias> <qual> <ax_call> <portnum>
PROXY=<call> <alias> <qual> <ipaddr> <tcp_port> [passwrd]
DESCRIPTION
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).
OPTIONS
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
WARNING
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!
SEE ALSO
PROXIES(9) -- About Proxy Connections.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
QUALADJ
QUALADJ(7) XROUTER REFERENCE MANUAL 18/10/2023
NAME
QUALADJUST -- NetRom Quality Manipulation.
SYNOPSIS
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.
DESCRIPTION
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.
OPTIONS
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.
LIMITATIONS
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.
CAVEATS
This is an experimental feature. Please use it with caution.
SEE ALSO
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.
QUALITY
QUALITY(7) XROUTER REFERENCE MANUAL 25/9/2023
NAME
QUALITY -- Default NetRom Quality.
SYNOPSIS
QUALITY=n (where n is 0 to 255)
DESCRIPTION
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.
EXAMPLE
QUALITY=30
SEE ALSO
QUALITY(1) -- Display / Set default Quality.
QUALADJ(7) -- NetRom Quality Manipulation.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
RADIO
RADIO(7) XROUTER REFERENCE MANUAL 21/9/2023
NAME
RADIO -- Radio control definition block.
SYNOPSIS
RADIO=n (where n is a number between 1 and 5)
DESCRIPTION
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.
OPTIONS
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.
EXAMPLE
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
SEE ALSO
RADIO(1) -- Rig control commands
XROUTER.CFG(8) -- Main configuration file
RESPTIME
RESPTIME(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
RESPTIME -- AX25 Delayed Ack Time.
SYNOPSIS
RESPTIME=<milliseconds>
DESCRIPTION
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.
EXAMPLE:
RESPTIME=2000 ; 2 seconds
SEE ALSO
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.
RETRIES
RETRIES(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
RETRIES -- AX25 Maximum Retry Count.
SYNOPSIS
RETRIES=n (where n is 0 to 100)
DESCRIPTION
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.
EXAMPLE
RETRIES=5
SEE ALSO
RETRIES(1) -- Display / Set Maximum Retries
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
RFBAUDS
RFBAUDS(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
RFBAUDS -- Radio Channel Baud Rate.
SYNOPSIS
RFBAUDS=<baud_rate>
DESCRIPTION
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.
EXAMPLE
RFBAUDS=2400
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
YAM(9) -- YAM ("Yet Another Modem") HDLC Modem.
RHPPORT
RHPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
RHPPORT -- TCP Port for RHP Server.
SYNOPSIS
RHPPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
RHP-SRV(9) -- Remote Host Protocol server.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
RLOGINPORT
RLOGINPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
RLOGINPORT -- TCP Port for Remote Login Service.
SYNOPSIS
RLOGINPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
RLOGIN(9) -- Remote Login Service.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
ROWS
ROWS(7) XROUTER REFERENCE MANUAL 19/10/2023
NAME
ROWS -- Set Display Height.
SYNOPSIS
ROWS=n (n = 25-60)
DESCRIPTION
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.
CAVEATS
If you set ROWS more than 25, you cannot use "full screen"
mode on Windows.
SEE ALSO
COLS(7) -- Set Display Width.
XROUTER.CFG(8) -- Main Configuration File.
SESSLIMIT
SESSLIMIT(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
SESSLIMIT -- Maximum Simultaneous Connections on Port.
SYNOPSIS
SESSLIMIT=n (where n is 0 to 255)
DESCRIPTION
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.
EXAMPLE
SESSLIMIT=5
SEE ALSO
MAXLINKS(7) -- Global Maximum AX25 Connections.
PORTS(6) -- Ports in XRouter.
USERS(7) -- Maximum Users on Port.
XROUTER.CFG(8) -- Main Configuration File.
SLOTTIME
SLOTTIME(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
SLOTTIME -- CSMA Interval Time.
SYNOPSIS
SLOTTIME=<millisecs>
DESCRIPTION
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.
EXAMPLE
SLOTTIME=100 ; 100 millisecs per slot
SEE ALSO
SLOTTIME(1) -- Display / Set CSMA Interval.
PERSIST(7) -- AX25 Probablity to Transmit.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
SOCKSPORT
SOCKSPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
SOCKSPORT -- TCP Port for SOCKS Proxy.
SYNOPSIS
SOCKSPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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).
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
SOCKS(9) -- About the SOCKS Proxy.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
SOFTDCD
SOFTDCD(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
SOFTDCD -- Software Data Carrier Detect.
SYNOPSIS
SOFTDCD=<0|1>
DESCRIPTION
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).
OPTIONS
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.
CAVEATS
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.
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
SYSOP
SYSOP(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
SYSOP -- Description..
SYNOPSIS
SYSOP=<0|1>
DESCRIPTION
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.
SEE ALSO
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
TELNETPORT
TELNETPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
TELNETPORT -- TCP Port for TELNET Access.
SYNOPSIS
TELNETPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
TELNET(9) -- About TELNET Access.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
TELPROXYPORT
TELPROXYPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
TELPROXYPORT -- TCP Port for Telnet Proxy.
SYNOPSIS
TELPROXYPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
TELPROXY(9) -- About the Telnet Proxy.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
TTYLINKPORT
TTYLINKPORT(7) XROUTER REFERENCE MANUAL 27/9/2023
NAME
TTYLINKPORT -- TCP Port for TTYLINK Access.
SYNOPSIS
TTYLINKPORT=n1 [n2] (where n1 and n2 are 0 to 65535)
DESCRIPTION
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.
OPTIONS
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.
CAVEATS
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.
SEE ALSO
CAPFLAGS(6) -- Capability Flags.
TTYLINK(9) -- About TTYLINK.
TCP-PORTS(6) -- TCP Service Ports.
XROUTER.CFG(8) -- Main Configuration File.
TXDELAY
TXDELAY(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
TXDELAY -- Transmit Delay.
SYNOPSIS
TXDELAY=<millisecs>
DESCRIPTION
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.
NOTE
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.
SEE ALSO
TXDELAY(1) -- Display / Set TX Delay.
PORTS(6) -- Ports in XRouter.
TXTAIL(7) -- TX Tail Time
XROUTER.CFG(8) -- Main Configuration File.
TXPORT
TXPORT(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
TXPORT -- Port to Transmit On.
SYNOPSIS
TXPORT=<port_number>
DESCRIPTION
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.
EXAMPLE
TXPORT=5 ; Transmit on port 5
SEE ALSO
TXPORT(1) -- Display / Set Port to Transmit On.
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
TXTAIL
TXTAIL(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
TXTAIL -- Transmitter Turnoff Delay.
SYNOPSIS
TXTAIL=<millisecs>
DESCRIPTION
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.
SEE ALSO
TXTAIL(1) -- Display / Set TX Tail Time.
TXDELAY(7) -- TX Activation Delay
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
UDPLOCAL
UDPLOCAL(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
UDPLOCAL -- Local UDP Port for Link.
SYNOPSIS
UDPLOCAL=<udp_port>
DESCRIPTION
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!
EXAMPLE
UDPLOCAL=7388
CAVEATS
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.
SEE ALSO
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.
UDPREMOTE
UDPREMOTE(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
UDPREMOTE -- Remote UDP Port for Link.
SYNOPSIS
UDPREMOTE=<udp_port>
DESCRIPTION
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).
EXAMPLE
UDPREMOTE=10093
SEE ALSO
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
UNPROTO
UNPROTO(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
UNPROTO -- Path for Unproto Broadcasts.
SYNOPSIS
UNPROTO <destcall>[,digicall,digicall,...]
DESCRIPTION
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.
EXAMPLE
UNPROTO=CQ,G6YAK
SEE ALSO
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.
USERS
USERS(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
USERS -- Maximum Users on Port.
SYNOPSIS
USERS=<0-255>
DESCRIPTION
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".
EXAMPLE
USERS=9
SEE ALSO
PORTS(6) -- Ports in XRouter.
SESSLIMIT(7) -- Maximum Simultaneous Connections on Port.
XROUTER.CFG(8) -- Main Configuration File.
VALIDCALLS
VALIDCALLS(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
VALIDCALLS -- AX25 Whitelist.
SYNOPSIS
VALIDCALLS=<callsign>[,calsign,callsign...]
DESCRIPTION
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.
EXAMPLE
VALIDCALLS=G6YAK,G6AMU ; Accept *only* these callsigns
SEE ALSO
EXCLUDE(7) -- AX25 L2 Exclusions (Budlist).
PORTS(6) -- Ports in XRouter.
XROUTER.CFG(8) -- Main Configuration File.
WALLFLAGS
WALLFLAGS(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
WALLFLAGS -- Options for Message Wall / Guestbook.
SYNOPSIS
WALLFLAGS=n (where 0 <= n <= 15)
DESCRIPTION
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.
OPTIONS
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
SEE ALSO
WALL(1) -- Access Message Wall / Guestbook.
MQTT-SRV(9) -- MQTT Server / Broker
XROUTER.CFG(8) -- Main Configuration File.
WARNCOLOR
WARNCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023
NAME
WARNCOLOR -- Colour For Warnings and Errors.
SYNOPSIS
WARNCOLOR=<colour>
DESCRIPTION
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.
OPTIONS
<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.
EXAMPLE
WARNCOLOR=PINK
SEE ALSO
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.
WXFILE
WXFILE(7) XROUTER REFERENCE MANUAL 26/9/2023
NAME
WXFILE -- Specify Weather Import File.
SYNOPSIS
WXFILE=[path/]<filename]
DESCRIPTION
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..
EXAMPLE
WXFILE=/etc/wxnow.txt
SEE ALSO
WX(1) -- Obtain Weather Information.
WX-SVC(9) -- NetRomX Weather Service
XROUTER.CFG(8) -- Main Configuration File.
WXMAXAGE
WXMAXAGE(7) XROUTER REFERENCE MANUAL 31/10/2024
NAME
WXMAXAGE -- Specify Maximum Age of a Weather Record.
SYNOPSIS
WXMAXAGE=<seconds>
DESCRIPTION
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.
EXAMPLE
WXMAXAGE=3600 - Sets max lifetime to 1 hour
SEE ALSO
WX(1) -- Obtain Weather Information.
WX-SVC(9) -- NetRomX Weather Service
XROUTER.CFG(8) -- Main Configuration File.
WXMAXAGE(7) END OF DOCUMENT
WXMAXRECS
WXMAXRECS(7) XROUTER REFERENCE MANUAL 31/10/2024
NAME
WXMAXRECS -- Specify Maximum Number of Weather Records.
SYNOPSIS
WXMAXRECS=<0-255>
DESCRIPTION
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.
EXAMPLE
WXMAXRECS=25 - Store a maxium of 25 weather records
SEE ALSO
WX(1) -- Obtain Weather Information.
WX-SVC(9) -- NetRomX Weather Service
XROUTER.CFG(8) -- Main Configuration File.
WXMAXRECS(7) END OF DOCUMENT
packet/xrouter/docs/section7-configurationdirectives.txt · Last modified: 2025/04/22 02:32 by m0mzf