packet:xrouter:docs:section8-configurationandsystemfiles
Table of Contents
Section 8 - Configuration and System Files
ACCESS
ACCESS.SYS(8) XROUTER REFERENCE MANUAL 28/2/2025
NAME
ACCESS.SYS -- Telnet Access Control File.
DESCRIPTION
This optional file is read only at bootup. It specifies
TCP/IP access requirements according to the caller's IP
address. If not present, the default action is for
logins to require a valid callsign only.
FORMAT
The entries in ACCESS.SYS are of the form:
<subnet>[/bits] <access_flags>
e.g. "44.0.0.0/8 1"
The <subnet> and [bits] parameters define a range of IP
addresses from whom Telnet connects will be accepted, and
<access_flags> defines the login requirements for that
subnet.
The [bits] parameter specifies how many bits, from left to
right, of the source address should be matched against the
corresponding <subnet> address. For example, 44.131.0.0/16
will test the source IP address against the left-most 16
bits of 44.131.0.0, i.e. it will match any source address
beginning with 44.131. And 0.0.0.0/0 will match any IP
address, which is useful for specifying the default. The
chosen match will be the one with the highest [bits] value.
If [bits] is not specified, it defaults to 32, i.e. an exact
match is required.
The <access_flags> parameter is the sum of these flag values.
1 Valid callsigns only
2 Password required
4 Guest access allowed
8 This IP address [range] is trusted
Typical combinations are as follows:
0 - Any "callsign" longer than 1 character is accepted, and
no password is required. In this context, "callsign"
could be a user name. This is a zero security option,
for use only for the sysop's convenience on physically
secure subnets.
1 - The user is required to enter a valid amateur radio
callsign, i.e. a string containing alphanumeric
characters in the correct format, but no password is
required. This is a low security configuration with
minimal inconvenience, and is suitable for use within
amateur radio subnets which are not connected to the
Internet. This configuration is recommended for callers
who have 44.x.x.x source address, as they are presumed
to have entered the network via radio, or via a
password-protected gateway.
2 - XRouter will accept any "username" longer than one
character, providing a valid password is given. This is
a medium security configuration, suitable for use on
private wire subnets where amateur radio callsigns are
not used.
3 - Both a valid amateur radio callsign and a matching
password must be supplied. This configuration is
recommended for use at the Internet-to-Amprnet interface,
i.e. for all source IP addresses other than 44.x.x.x
4 - Any "callsign" longer than 1 character is accepted, and
no password is requested or required. All users have
guest access, ie they cannot downlink.
5 - The user is required to enter a valid amateur radio
callsign, but no password is requested or required. All
users have guest access, ie they cannot downlink.
6 - Any "callsign" longer than 1 character is accepted.
User is challenged to enter a password, but the option
to use the password "guest" is available. If the user
gives a valid password he gets full access, but if he
answers with "guest" he only gets guest access.
7 - The user is required to enter a valid amateur radio
callsign, and he is challenged to enter a password, but
the option to use the password "guest" is available. If
the user gives a valid password he gets full access, but
if he answers with "guest" he only gets guest access.
This setting is recommended for source addresses which
aren't either private LAN or 44.x.x.x.
8 - The specified address [range] is to be treated in the same
way as a "LAN" address. Used mainly to prevent HTTP, RHP,
AGWHOST etc from requiring authorisation when used via a
VPN. This flag DOES NOT affect Telnet and FTP logins.
EXAMPLE
# Subnet[/bits] flags
# ==============================
#
# HTTP/RHP from this VPN subnet do not require authorisation
207.221.31.0/8 8
#
# Amprnet users need only supply a callsign
44.0.0.0/8 1
#
# LAN users need only supply a callsign
192.168.0.0/24 1
#
# Everyone else must supply callsign and password, but
# "guest" is allowed as a password, giving read-only access.
0.0.0.0/0 7
GUEST ACCESS
Guest access is intented to let people look around, but not
to do anything that would cause a transmission to be made.
Guests are prevented from using the SEND, CHAT and CONNECT
commands, and from sending APRS messages using the APRS
messaging shell. For the TELNET command they are restricted
by the rules in the file TELGUEST.ACL. If that file is not
present, guests are denied access to the TELNET command.
Guests are not necessarily unlicenced people. They may simply
be hams who don't yet have a password for your system.
PASSWORDS
If passwords are required for user access, they should be
located in file USERPASS.SYS, which is used for "normal"
telnet (port 23) logins.
Do not confuse this with PASSWORD.SYS, which is used for
sysop logins via AX25, Rlogin and FTP.
SEE ALSO
PASSWORD.SYS(8) -- Sysop passwords file
TELGUEST.ACL(8) -- Telnet egress control file
USERPASS.SYS(8) -- User passwords file
BADWORDS
BADWORDS.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
BADWORDS.SYS -- Bad Words File for Mailbox.
DESCRIPTION
BADWORDS.SYS is an optional file, used by the mailbox to
check new mail for inapproriate content. If present, it is
located in the PMS subdirectory.
It contains a list of words or part-words, one per line,
which are deemed unacceptable in Packet mail. If any of the
words are matched in the text of a new message, the message
is held for review. Held messages are not forwarded, and are
only visible to sysops.
Wildcards are allowed, but "*" is only allowed at the END of
a word.
Only single words are allowed at present, no phrases. Words
are not case-sensitive.
Comment lines must begin with hash (#) or semicolon (;) in
the leftmost column.
The supplied file dates from the 1990s, and will probably
need updating or replacing with words appropriate to your own
language.
If the file is not present, mail is not checked.
NOTE
False matches sometimes occur. For example "CUNT" appears in
the place name Scunthorpe. This issue may be fixed in a future
version.
SEE ALSO
LH(4) -- List Held Mail
KH(4) -- Kill Held Mail
UH(4) -- Un-hold Mail
PMS(9) -- About the Mailbox
BOOTCMDS
BOOTCMDS.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
BOOTCMDS.SYS -- Commands to Execute at Bootup.
DESCRIPTION
This optional file is read by XRouter at boot time, after
XROUTER.CFG and IPROUTE.SYS. It is mainly used for
configuration commands that have no keywords in XROUTER.CFG,
such as the GNET and PPP commands.
FORMAT
Format is exactly the same as keyboard-entered commands,
with one command per line. Lines beginning with '#' or ';'
are ignored, and may be used for comments.
OPTIONS
Whilst many commands *can* be used in BOOTCMDS.SYS, there is
often no point in doing so, because they duplicate the
function of configuration directives. For example there's no
point including "Paclen 3 120", when it is just as easy to
put PACLEN=120 in the port 3's configuration block. However,
most of the commands listed below can also be used in
CRONTAB.SYS, where they DO have a purpose.
Commands that can be used in BOOTCMDS.SYS are as follows:
ACL, APPLMASK, ARP, BCAST, BELL, BLEVEL, CAPTURE, CFLAGS,
CTEXT, CTFLAGS, CTRL, DIAL, DHCP, DIGIFLAG, DIGIPORT, DNS,
DUN, EXCLUDE, EXIT, FEC, FRACK, FULLDUP, GNET, ID, IDPATH,
IDS, IDTEXT, IFACE, IPADDRESS, IPLINK, LOADNODES, LOG,
MAXFRAME, MDIR, MFROM, MHCLEAR, MHFLAGS, MHSIZE, MINQUAL,
MINTXQUAL, MMASK, MON, MPORT, MQTT, MTO, NAT, NETMASK,
NODESINT, NOTIFY, ODN, PACLEN, PCAP, PEERS, PERSIST, PING,
PIPE, PIPEFLAG, PORT, PPP, QUALITY, RESPTIME, RESTART,
RETRIES, RIP, ROUTE, SAVENODES, SEND, SHELL, SLOTTIME, START,
STATS, STOP, TCP, TSYNC, TXDELAY, TXOK, TXPORT, TXTAIL, UDP,
UDPLOCAL, UDPREMOTE, UNPROTO, USERS, WAIT, WX.
EXAMPLES
# This is a comment line
GNET ADDR 131.91.1.1
GNET ROUTE ADD 147.38.1.1 zl2aqy
SEE ALSO
CRONTAB.SYS(8) -- Event Control File.
XROUTER.CFG(8) -- Main Configuration File.
CRONTAB
CRONTAB.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
CRONTAB.SYS -- Event Control File (optional).
DESCRIPTION
This optional file allows XRouter commands to be executed at
certain times of the day, week, month or year.
A few of the possible uses would be:
- Additional AX25 beacons.
- Beaconning APRS objects, status, bulletins and
announcements.
- Adjusting Netrom / IP routing to account for part-time
neighbours.
- Enabling / disabling transmitters.
- Controlling peripherals via the CTRL port.
- Adjusting parameters to cope with diurnal propogation
changes.
- Loading updated ENCAP.TXT at intervals.
- Enabling / disabling IGATE at certain times of day / week.
- Automatic reboots / restarts / exits for batch file
processing etc.
When commands are executed, all responses from the command
processor are discarded.
OPTIONS
Commands that can be used in CRONTAB.SYS are as follows:
ACL, APPLMASK, ARP, BCAST, BELL, BLEVEL, CAPTURE, CFLAGS,
CTEXT, CTFLAGS, CTRL, DIAL, DHCP, DIGIFLAG, DIGIPORT, DNS,
DUN, EXCLUDE, EXIT, FEC, FRACK, FULLDUP, GNET, ID, IDPATH,
IDS, IDTEXT, IFACE, IPADDRESS, IPLINK, LOADNODES, LOG,
MAXFRAME, MDIR, MFROM, MHCLEAR, MHFLAGS, MHSIZE, MINQUAL,
MINTXQUAL, MMASK, MON, MPORT, MQTT, MTO, NAT, NETMASK,
NODESINT, NOTIFY, ODN, PACLEN, PCAP, PEERS, PERSIST, PING,
PIPE, PIPEFLAG, PORT, PPP, QUALITY, RESPTIME, RESTART,
RETRIES, RIP, ROUTE, SAVENODES, SEND, SHELL, SLOTTIME, START,
STATS, STOP, TCP, TSYNC, TXDELAY, TXOK, TXPORT, TXTAIL, UDP,
UDPLOCAL, UDPREMOTE, UNPROTO, USERS, WAIT, WX.
FILE FORMAT
Each entry is specified on a seperate line. Empty lines,
and lines beginning with '#' or ';' are ignored.
Entries have the following format:
<min> <hour> <date> <month> <day> <command> [args]
0-59 0-23 1-31 1-12 0-6
Fields must be seperated by one or more spaces or tabs.
<command> is executed if <min> <hour> and <month> match
the current time, and either the <date> (day of month)
or <day> (of week) match. [args] specifies the command's
argument(s).
Dates / times may be specified as single numbers, multiple
numbers, ranges, or a mixture thereof, e.g. "0-5,7,9,15-22".
Note there must be no spaces within the string of characters.
Use '*' in any of the first 5 fields to signify "all".
EXAMPLES
; <min> <hour> <date> <month> <day> <command> [args]
; Every 20 mins, advertise the BBS using an APRS symbol
; on port 13
0,20,40 * * * * send 13 APZ179 !5224.00N/00215.00WB GB7PZT
; Every Thursday at 03:05 save nodes table to an archive
5 3 * * 4 SAVENODES PZTNODES.ACV
DEUTSCHE
DEUTSCHE.SYS(8) XROUTER REFERENCE MANUAL 22/10/2023
NAME
DEUTSCHE.SYS -- German Language Texts for XRouter.
DESCRIPTION
DEUTSCHE.SYS is an optional file containing german language
texts for use within XRouter.
If present in the same directory as the XRouter executable,
the contents of this file are read at bootup only, adding
German prompts, headings and responses for those who select
the German language option.
If this file is not present, XRouter defaults to ENGLISH.
If you can improve on the translation, please do so, and
please share your work.
Be careful with modifications, because some of the texts are
used in multiple places, and some of them are column headers
which need to follow a strict format.
Modifications to this file do not affect other languages.
FORMAT
Each text is on a separate line, which begins with a number
corresponding to that text. Following the number is some
whitespace, then the text itself is enclosed in quotes. For
example:
12 "Syntaxfehler\r"
Most texts end with "\r" (carriage return, ASCII 13), but not
all of them do. "Hanging" prompts and individual words don't.
Blank lines, and lines which begin with '#' in the leftmost
column are ignored. The latter can be used for comments.
Some texts contain one or more placeholders such as "%s",
"%d" etc. You may move their position within a text, but if
you change them, you will cause XRouter to crash.
For example, you could safely re-word the following:
73 "Sesión %d No encontrado\r"
to the following:
73 "No puedo encontrar la sesión %d\r"
"%d" is a placeholder for an integer
"%s" is a placehlder for a string of characters
Changes don't take effect unless XRouter is restarted.
Text numbers fall into the following ranges:
1-999 General texts
1000 PZTDOS texts
2000 AX25/NetRom texts
3000 Chat server texts
4000 APRS Messaging System Texts
5000 FTP Client texts
6000 PMS Texts
7000 IDS (Intrusion Detection System) texts
If a required text is not found in the file (e.g. it has
been deleted or commented out), the inbuilt English text is
used instead.
SEE ALSO
CONSOLELANG(7) -- Console language
DEFAULTLANG(7) -- Specify default language
ENGLISH.SYS(8) -- English Language Texts
ESPANOL.SYS(8) -- Spanish Language Texts.
FRANCAIS.SYS(8) -- French Language Texts
LANGS.SYS(8) -- Language selection file
DISTRIB
DISTRIB.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
DISTRIB.SYS -- Mail Distribution File.
DESCRIPTION
Optional file DISTRIB.SYS controls queuing of mail for
delivery to neighbouring mailboxes.
If present, it is located in XRouter's PMS subdirectory. If
the file is absent, mail is not delivered to other mailboxes.
The file is read "live" upon receipt of each item of
"forwardable" mail, which means it can be edited on the fly,
with modificatiions taking immediate effect.
FORMAT
Lines must not exceed 127 characters. Comment lines are
allowed. These must start with '#' or ';' in first column.
DISTRIB.SYS contains "rules" for mail distribution. If there
are no rules, there can be no mail forwarding
Each "rule" consists of a minimum of 4 and a maximum of 5
fields on a single line. The fields, which may be separated
by spaces or tabs, are as follows:
<type> <to> <at> <via> [max_size]
<type> Message type (e.g. P, B or *)
<to> Message recipient or bulletin category (wildcards ok)
If the <to> field starts with a caret '^', it REJECTS
the message if it matches. e.g. "^EQUAKE" prevents
distribution of EQUAKE messages.
<at> Distribution area, e.g. "GB7PZT", "EU" or "#24.GBR".
This is a "sliding match", so EU matches EU and EURO,
GBR matches .#76.GBR.EURO and so on. Wildcards are NOT
alllowed in this field except for "*" by itself,
meaning "match any".
<via> Callsign (minus SSID) of the neighbouring mailbox to
which the item of mail should be sent.
[max_size] is optional. If present, it specifies the maximum
message size in bytes. Messages whose size exceeds
this value are not queued.
OPERATION
Each new message is tested against the rules, looking for a
matching rule. If <type> <to> and <at> all match the fields
of the message, the latter is placed on the queue for the
mailbox specified by <via>. The queue is later processed
according to the rules in FWD.SYS.
Rules are processed in the sequence in which they are
declared. Therefore "reject" entries MUST be declared before
"accept" entries.
Private mail is queued for the FIRST match only.
Bulletins are distributed to ALL matching entries.
EXAMPLE
The organisation of this file is up to you, but the following
method is recommended.
Firstly, route any private mail addressed TO nearby sysops
and users. This ensures delivery even if the hierarchical
address is wrong:
# <type> <to> <at> <via> [max_size]
# --------------------------------------------------
P VA2OM * VE2PKT
P VE2PKT * VE2PKT
P MW0NXT * GB7NXT
Next, handle mail explicitly addressed AT neighbour BBS's.
Again, this guards against incorrect hierarchical addresses.
# <type> <to> <at> <via> [max_size]
# --------------------------------------------------
* * VA2OM VE2PKT
* * VE2PKT VE2PKT
* * GB7NXT GB7NXT
Finally, handle bulletin distribution. In this case, all
EQUAKE bulletins are ignored. All remaining bulls go to
VE2PKT, but only GBR, EU and WW are sent to GB7NXT.
# <type> <to> <at> <via> [max_size]
# --------------------------------------------------
B ^EQUAKE * *
B * * VE2PKT
B * GBR GB7NXT
B * EU GB7NXT
B * WW GB7NXT 5000
SEE ALSO
FWD.SYS(8) -- Mailbox Forwarding Control File
PMS(9) -- About the Mailbox.
DOMAIN
DOMAIN.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
DOMAIN.SYS -- Hostname Resolution File.
DESCRIPTION
This optional file is used to "resolve" host names such as
"g8jvm.ampr.org" and aliases such as "lgsbbs" into their
corresponding IP addresses.
It is the first place XRouter looks when resolving a hostname.
If the file is not present, or the hostname is not found in
in the file, XRouter queries a DNS (Domain Name Server) to
obtain the information (in order for this to work, either
Windows/Linux or XRouter must have a network connection to an
external DNS).
If no DNS is available, and the hostname is not found in
DOMAIN.SYS, you will have to enter the full IP address of
the target host when using the PING, TELNET, TTY, and FINGER
commands.
Name resolution using a radio-based DNS is quite slow, so if
you are using this mode you should add entries to this file
for frequently contacted hosts whose addresses are stable.
Externally resolved names are added automatically to
DOMAIN.SYS at regular intervals, and expired entries are
purged.
FILE FORMAT
Each host is listed on a separate line. Each field must be
separated by one or more spaces or tabs. Comments, spaces,
tabs and blank lines are permissible to aid clarity. The
records are case-insensitive, but most people use lower case
for hostnames. The format of each record is as follows:
<hostname> [ttl] IN A <ip-address>
<alias> [ttl] IN CNAME <hostname>
<hostname> [ttl] IN MX [pref] <hostname>
The first form maps a hostname to an IP address, and the
second and third forms map alternative hostnames to a host
that is already defined.
For example, the IP address for the GB7PZT mailbox is
44.131.91.2 so it would have an Internet Address (IN A)
record like so:
gb7pzt IN A 44.131.91.2
But gb7pzt is also known locally as "pztbbs", and "kdrbbs".
There is nothing to stop you adding further "IN A" records
for gb7pzt, one for each alias, but you could instead use
the second form shown above, the CNAME or "Canonical Name"
record like so:
pztbbs. IN CNAME gb7pzt
kdrbbs. IN CNAME gb7pzt
Thus if the user types "TEL pztbbs" or "TEL kdrbbs", the
gb7pzt record is used. This removes the need to keep
repeating the IP address in multiple "A" records, and makes
it easier if the IP address is changed.
The MX or "Mail Exchange" records are usually used for
defining alternate names for mail servers, but as XRouter is
not concerned with mail you can use them in the same way as
CNAME entries, although there would be no point in doing so.
The format of the additional records would be:
pztbbs. IN MX gb7pzt
kdrbbs. IN MX gb7pzt
The optional "preference" field of MX records is ignored.
The optional [ttl] field in all types of entry is the
"time to live" of the entry in seconds, used to expire
records whose addresses are liable to change. If omitted or
set to zero, the record has an unlimited lifetime.
In order to simplify the file, the ".ampr.org" is usually
omitted from the records, and appended automatically when
the file is read. However, hostnames which contain or end
with a dot will not be extended in this manner. Thus
"gb7pzt" would be extended to "gb7pzt.ampr.org", whereas
"lgs." and "ns.cyberphile.co.uk" would not be modified.
NOTES
Although DOMAIN.SYS was originally designed to be simpler
than the more standard DOMAIN.TXT format, Xrouter is capable
of understanding both formats, so you may use an existing
DOMAIN.TXT simply by renaming it to DOMAIN.SYS.
FILES
DOMAIN.SYS is located in the same directory as XRouter.EXE.
LIMITATIONS
XRouter's DNS server currently responds only to type A
queries.
SEE ALSO
DNS(1) -- DNS Configuration Commands.
DYNDNS
DYNDNS.CFG(8) XROUTER REFERENCE MANUAL 6/9/2023
NAME
DYNDNS.CFG -- Dynamic DNS Update Client Configuration File.
DESCRIPTION
This optional file is used by the Dynamic DNS Update Client,
and contains information about your account, the address(es)
you wish to update, and the method of update.
If you are not using the client, you do not need this file.
EXAMPLES
The following is an example DYNDNS.CFG file:
; DYNDNS.CFG:
; Configuration file for XRouter Dynamic DNS update client
; Do not delete or change the order of entries.
;
; Update server name
members.dyndns.org
;
; IP detection server
checkip.dyndns.org
;
; Account Name (put your own account name here)
test
;
; Account Password (Put your password here)
test
;
; System (dyndns, statdns or custom)
; (The latter two are only available on subscription.)
dyndns
;
; Use external IP detection? (yes / no)
; This should be set to NO if Xrouter is directly connected
; to the Internet or YES if the Internet connection is via
; another router.
NO
;
; Wildcard (ON / OFF)
; If this is set to ON, *.host.domain will be aliased to
; host.domain
ON
;
; Hostname(s) to be updated, separated by commas. No spaces.
; (put your own hostname(s) here)
test.ath.cx,test.dyndns.org,test.dnsalias.net
;
SEE ALSO
DYNDNS(9) -- Dynamic DNS Update Client
DYNDNS.CFG(8) END OF DOCUMENT
ENCAP
ENCAP.TXT(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
ENCAP.TXT -- Amprnet Encapsulated Routing File (optional).
DESCRIPTION
This is *not* an XRouter configuration file, but XRouter
is capable of reading it.
ENCAP.TXT is simply a text file which contains a huge list
of amateur IP routes and the Internet addresses of IPEncap
gateways which handle them.
If this file is present when XRouter boots up, it will read
the routes into its IP routing table.
If you are not running an amprnet "gateway", or have set up
your own encap routes in IPROUTE.SYS, you do not need this
file.
FORMAT
The format of routing entries in ENCAP.TXT is as follows:
route addprivate 44.131.91.0/24 encap 62.31.206.176
The "addprivate" stipulates that the route should be hidden
from users, i.e. not displayed by the IPROUTES command.
The "44.x.x.x/xx" part specifies which amprnet route(s)
this entry applies to.
The "encap" part tells XRouter to use IPEncap protocol,
i.e. it is the same as using routing mode "e".
The final field is the Internet IP address of the gateway
which handles the specified amprnet route(s).
FILES
If required. ENCAP.TXT should be located in same directory
as the XRouter executable.
NOTES
ENCAP.TXT is subject to frequent modification, so you will
need to obtain updated copies from time to time, and use
IP ROUTE LOAD (or restart XRouter) to load them. A batch
file to obtain and edit the ENCAP.TXT can be run by the
Windows / Linux task scheduler, and IP ROUTE LOAD can then
be called afterwards by a suitable entry in CRONTAB.SYS.
CAVEATS
On Windows, it is NOT possible to use "encap" protocol
without using the NDISXPKT driver. Without the driver, XR32
is forced to use the Windows IP stack, instead of its own,
for accessing the Internet. The problem is, Windows no longer
allow IPEncap to pass via it's IP stack. The protocol was
blocked for "security reasons" when Microsoft issued XP
service pack 2. It should work on Windows 2000 and early
versions of XP however. There are no such restrictions on
Linux.
If you are a gateway, you must remove your own entry from
ENCAP.TXT before loading it, otherwise catastrophic
looping will occur (this may have been fixed in later
versions).
ENCAP.TXT contains over 500 entries, and may make your IP
routing slower, because all those routes must be searched
recursively for every single datagram routed by your
system. With a fast computer or low data rate you
probably wouldn't notice the difference however.
BACKGROUND
IPEncap (usually called "encap", but sometimes erroneously
called IPIP) "encapsulates" amateur IP within the payload of
public (Internet) IP datagrams. Thus it is sometimes called
IP-over-IP or IP-within-IP, but should not be called "IPIP",
because that is an older version of the protocol. Encap is
assigned IP protocol number 4, and IPIP is protocol 94.
Encapsulation allows amateur IP (44.x.x.x addresses) to be
"tunnelled" or "wormholed" across the internet, between
amprnet gateways. In order to do this, each gateway needs to
know the Internet addresses of the other gateways, and which
amprnet datagrams shoule be sent to which gateway. That
information is located in ENCAP.TXT.
In order to keep the amprnet secure, the gateway owners need
to prevent their IP addresses from becoming public knowledge.
Thus the contents of ENCAP.TXT are a closely guarded secret.
The file is obtained from an FTP server whose address is
known only to the gateway sysops.
SEE ALSO
IPENCAP(9) -- IP-within-IP Encapsulation.
IPROUTE.SYS(8) -- IP Routing and Configuration File
ENGLISH
ENGLISH.SYS(8) XROUTER REFERENCE MANUAL 22/10/2023
NAME
ENGLISH.SYS -- English Language Texts for XRouter.
DESCRIPTION
ENGLISH.SYS is an optional file containing English Language
Texts which are used within XRouter.
If present, the contents of this file are read at bootup
only, replacing XRouter's inbuilt prompts, headings and
responses.
XRouter's inbuilt language is ENGLISH. If you wish, you may
change the layout and/or wording of most XRouter responses by
installing ENGLISH.SYS in the same directory as XRouter.
XRouter will then use the texts from that file, which you may
modify, instead of the inbuilt ones.
Be careful with modifications, because some of the texts are
used in multiple places, and some of them are column headers
which need to follow a strict format. Installing and
modifying this file is NOT recommended, but it's up to you!
Modifications to this file do not affect other languages.
FORMAT
Each text is on a separate line, which begins with a number
corresponding to that text. Following the number is some
whitespace, then the text itself is enclosed in quotes. For
example:
12 "Syntax error\r"
Most texts end with "\r" (carriage return, ASCII 13), but not
all of them do. "Hanging" prompts and individual words don't.
Blank lines, and lines which begin with '#' in the leftmost
column are ignored. The latter can be used for comments.
Some texts contain one or more placeholders such as "%s",
"%d" etc. You may move their position within a text, but if
you change them, you will cause XRouter to crash.
For example, you could safely re-word the following:
73 "Session %d not found\r"
to the following:
73 "I'm sorry, I can't find session %d\r"
"%d" is a placeholder for an integer
"%s" is a placehlder for a string of characters
Changes don't take effect unless XRouter is restarted.
Text numbers fall into the following ranges:
1-999 General texts
1000 PZTDOS texts
2000 AX25/NetRom texts
3000 Chat server texts
4000 APRS Messaging System Texts
5000 FTP Client texts
6000 PMS Texts
7000 IDS (Intrusion Detection System) texts
If a required text is not found in the file (e.g. it has
been deleted or commented out), the inbuilt text is used
instead.
SEE ALSO
CONSOLELANG(7) -- Console language.
DEFAULTLANG(7) -- Specify default language.
DEUTSCHE.SYS(8) -- German Language Texts.
ESPANOL.SYS(8) -- Spanish Language Texts.
FRANCAIS.SYS(8) -- French Language Texts.
LANGS.SYS(8) -- Language selection file.
ESPANOL
ESPANOL.SYS(8) XROUTER REFERENCE MANUAL 22/10/2023
NAME
ESPANOL.SYS -- Spanish Language Texts for XRouter.
DESCRIPTION
ESPANOL.SYS is an optional file containing Spanish language
texts for use within XRouter.
If present in the same directory as the XRouter executable,
the contents of this file are read at bootup only, adding
Spanish prompts, headings and responses for those who select
the Spanish language option.
If this file is not present, XRouter defaults to ENGLISH.
If you can improve on the translation, please do so, and
please share your work.
Be careful with modifications, because some of the texts are
used in multiple places, and some of them are column headers
which need to follow a strict format.
Modifications to this file do not affect other languages.
FORMAT
Each text is on a separate line, which begins with a number
corresponding to that text. Following the number is some
whitespace, then the text itself is enclosed in quotes. For
example:
12 "Erreur se synthèse\r"
Most texts end with "\r" (carriage return, ASCII 13), but not
all of them do. "Hanging" prompts and individual words don't.
Blank lines, and lines which begin with '#' in the leftmost
column are ignored. The latter can be used for comments.
Some texts contain one or more placeholders such as "%s",
"%d" etc. You may move their position within a text, but if
you change them, you will cause XRouter to crash.
For example, you could safely re-word the following:
73 "Sesión %d No encontrado\r"
to the following:
73 "No puedo encontrar la sesión %d\r"
"%d" is a placeholder for an integer
"%s" is a placehlder for a string of characters
Changes don't take effect unless XRouter is restarted.
Text numbers fall into the following ranges:
1-999 General texts
1000 PZTDOS texts
2000 AX25/NetRom texts
3000 Chat server texts
4000 APRS Messaging System Texts
5000 FTP Client texts
6000 PMS Texts
7000 IDS (Intrusion Detection System) texts
If a required text is not found in the file (e.g. it has
been deleted or commented out), the inbuilt English text is
used instead.
SEE ALSO
CONSOLELANG(7) -- Console language.
DEFAULTLANG(7) -- Specify default language.
DEUTSCHE.SYS(8) -- German Language Texts.
ENGLISH.SYS(8) -- English Language Texts.
FRANCAIS.SYS(8) -- French Language Texts.
LANGS.SYS(8) -- Language selection file.
EXEC
EXEC.HTM(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
EXEC.HTM -- Command Template for HTTP Server.
DESCRIPTION
This optional file is a "template" for use with the HTTP
server.
When the server receives a request whose URL begins with
"/exec?cmd=", e.g. it passes the command to XRouter for
execution, and serves a "template" page displaying the
response to the command. The template serves as a wrapper
for the text.
If you wish to override XRouter's inbuilt HTML template, edit
the file EXEC.HTM, which was supplied with the installation
package, and put it in the XRouter working directory. This
file is not placed within the HTTP directory tree because it
is not intended to be served in the normal way.
If EXEC.HTM exists, the server will serve it in place of the
inbuilt template, replacing the <TEXT> tag with the result of
the executed command. EXEC.HTM does not currently support
Server Side Includes.
SEE ALSO
HTTP-SRV(9) -- HTTP Server.
EXPORT
EXPORT.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
EXPORT.SYS -- Mail Export Control File.
DESCRIPTION
The optional file EXPORT.SYS, which resides in the PMS
subdirectory, controls "exporting" of messages to files.
It is read "live" upon receipt of each new mesaage, so it can
be edited on the fly, and any edits take effect immediately.
Exporting can be used to archive selected messages, or to
create files that can be imported into other mail systems.
FORMAT
Comment lines are allowed. These must begin with a semicolon
or hash in the first column.
Lines beginning with '@' specify the filename to which
messages are to be exported, and the file opening mode to use.
The mode is specified by a single (optional) character, which
follows the filename, after a gap of one or more spaces:
O = overwrite A = Append (default)
Overwrite mode would typically be used when only the most
recent copy of a regular message, e.g. a weather report, was
required
For all other lines, the fields are:
<format> <type> <to> <from> <at> <mid> <subject>
<format> can be one or two characters. The first character
specifies the format of the exported message:
(F = as a file, M = MBL).
The optional second character determines routing
header (R: line) stripping:
H = Include all routing header lines.
R = Include first (originating) R: line only.
None = Don't include any R: lines
<type> specifies the type of message to be exported:
B = Bulletin, P = Private, A = Ack, 7 = 7plus, * = Any
The remaining fields specify which messages are to be
exported, depending on any combination of TO, FROM, AT, MID
or subject.
All fields are case-independent, and wildcards are allowed.
However, the <subject> field behaves slightly differently to
the others. The supplied <subject>, which may contain more
than one word, is tested against all parts of the message
subject, in a "sliding match". For example "news" will match
both "RSGB Main News" and "DX News". The only wildcard allowed
in the subject field is a single "*" (match any subject)
EXAMPLES
The following example exports TECH bulletins sent by G8MNY,
to the file PMS/TECH.SAV in "append" mode, using "MBL" format,
and omitting all R: lines except the one generated by the
original sender's mailbox:
@PMS/TECH.SAV
# <format> <type> <to> <from> <at> <mid> <subject>
#-------------------------------------------------------
MR B TECH G8MNY * * *
The next example appends retro computing bulletins to the
file "retro.txt" in "MBL" mode, omitting all routing headers:
@/home/pi/retro/retro.txt
# <format> <type> <to> <from> <at> <mid> <subject>
#-------------------------------------------------------
MR B CBM * * * *
MR B ATARI * * * *
MR B * * * * VIC20
The final example shows the use of "overwrite" mode, to store
a copy of the latest DX News in the BBS files area as a file
without any MBL headers or R: lines:
@FILES/DXNEWS.TXT O
# <format> <type> <to> <from> <at> <mid> <subject>
#-------------------------------------------------------
F B DXNEWS * * * Latest
SEE ALSO
EXPORT(4) -- Export Message to File.
IMPORT(4) -- Import Message(s) From File.
PMS(9) -- About the Mailbox.
FILES
FILES(8) XROUTER REFERENCE MANUAL 30/10/2023
NAME
FILES -- Files And Directories Used By XRouter.
DESCRIPTION
All files and directories required by the system are located
within a single directory which can be located anywhere and
have any name. For the purposes of this document it will be
called the "root" or "working" directory. All other
directories used by XRouter are sub-directories of the
working directory.
The working directory should contain at least the XRouter
program and XROUTER.CFG. All other files are optional and
the system will run without them.
If you want to grant access to remote sysops you will need to
add a suitably configured PASSWORD.SYS. If you want to route
IP, you will need IPROUTE.SYS. If you want to control TCP/IP
access, add ACCESS.SYS and USERPASS.SYS. If you need to
specify hostnames for fast domain lookup, add DOMAIN.SYS.
If you add any of the above, you must edit them to suit your
requirements. They should be self-documenting, but there is
also a MAN file for each one.
If you want the full HELP system (recommended), create a
sub-directory called HELP and place all the .HLP files into
it. Note that the help for the CHAT server goes in
sub-directory HELP/CHAT, FTP server help goes in HELP/FTP and
the APRS messaging help goes in HELP/AMSG.
If you want an INFO system, create the INFO directory and
populate it with .INF files. There are some sample .INF
files included in the distribution package to give you some
ideas.
If you want the online manual (recommended), create the MAN
directory and put the *.MAN files into it.
Directory Tree
~~~~~~~~~~~~~~
/ - XRouter "root", e.g. C:\XRouter
/FINGER/ - FINGER files
/HELP - English HELP files
/HELP/AMSG/ - Help for APRS messaging
/HELP/CHAT/ - Help for chat server
/HELP/FTP/ - Help for FTP server
/HELP/FR/ - French HELP files
/HELP/NL/ - Dutch HELP files
/HTTP/ - Root for HTTP server (see below)
/INFO/ - INFO files
/LOG/ - Activity log files
/MAN/ - Sysop manual files
The LOG directory is created automatically when XRouter runs.
If logging is enabled, daily log files are created within the
LOG directory. If IDS logging is enabled, the IDS log files
are also written to thr LOG directory.
The HTTP root directory may be relocated (using the HTTPROOT
directive in XROUTER.CFG). This allows the HTML files to be
located somewhere more convenient, even on another drive if
required.
Files in XRouter "root" Directory (* = mandatory)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACCESS.SYS - TCP/IP access control.
BOOTCMDS.SYS - Boot up config commands.
CRONTAB.SYS - Event control.
DEUTSCH.SYS - German language file.
DOMAIN.SYS - TCP/IP hostname resolution.
ENCAP.TXT - IPENCAP routes.
ESPANOL.SYS - Spanish language file.
FRANCAIS.SYS - French language file
HTTP.ACL - HTTP Proxy Egress Control.
HTTP.SYS - HTTP Rewrite / Proxy Control.
HTTPBAN.SYS - HTTP URL block list.
IGATE.CFG - APRS IGATE configuration.
IPROUTE.SYS - IP routes / configuration.
LANGS.SYS - Languages control file.
NEDERLANDS.SYS - Dutch language file.
PASSWORD.SYS - Sysop passwords.
PPPHOST.n - PPP configuration files.
PPPLOG.TXT - PPP activity log.
SOCKS.ACL - SOCKS proxy egress control.
TELGUEST.ACL - Telnet "guest" mode egress control.
TELPROXY.ACL - Telnet proxy egress control.
TELPROXY.MSG - Telnet proxy welcome message.
USERPASS.SYS - User passwords.
* (XRouter) - Executable (xrouter / xr32 / xrpi /xrlin)
XRNODES - NetRom nodes / routes recovery file.
* XROUTER.CFG - XRouter Main Configuration File.
There are detailed MAN pages for each of the above files in
section 8 of the manual.
SEE ALSO
XROUTER.CFG(8) -- Main Configuration File.
IPROUTE.SYS(8) -- IP routes / configuration File.
BOOTCMDS.SYS(8) -- Boot up configuraion Commands.
FRANCAIS
FRANCAIS.SYS(8) XROUTER REFERENCE MANUAL 22/10/2023
NAME
FRANCAIS.SYS -- French Language Texts for XRouter.
DESCRIPTION
FRANCAIS.SYS is an optional file containing French language
texts for use within XRouter.
If present in the same directory as the XRouter executable,
the contents of this file are read at bootup only, adding
French prompts, headings and responses for those who select
the French language option.
If this file is not present, XRouter defaults to ENGLISH.
If you can improve on the translation, please do so, and
please share your work.
Be careful with modifications, because some of the texts are
used in multiple places, and some of them are column headers
which need to follow a strict format.
Modifications to this file do not affect other languages.
FORMAT
Each text is on a separate line, which begins with a number
corresponding to that text. Following the number is some
whitespace, then the text itself is enclosed in quotes. For
example:
12 "Erreur se synthèse\r"
Most texts end with "\r" (carriage return, ASCII 13), but not
all of them do. "Hanging" prompts and individual words don't.
Blank lines, and lines which begin with '#' in the leftmost
column are ignored. The latter can be used for comments.
Some texts contain one or more placeholders such as "%s",
"%d" etc. You may move their position within a text, but if
you change them, you will cause XRouter to crash.
For example, you could safely re-word the following:
73 "Session %d pas trouvé\r"
to the following:
73 "Je ne trouve pas la session %d\r"
"%d" is a placeholder for an integer
"%s" is a placehlder for a string of characters
Changes don't take effect unless XRouter is restarted.
Text numbers fall into the following ranges:
1-999 General texts
1000 PZTDOS texts
2000 AX25/NetRom texts
3000 Chat server texts
4000 APRS Messaging System Texts
5000 FTP Client texts
6000 PMS Texts
7000 IDS (Intrusion Detection System) texts
If a required text is not found in the file (e.g. it has
been deleted or commented out), the inbuilt English text is
used instead.
SEE ALSO
CONSOLELANG(7) -- Console language.
DEFAULTLANG(7) -- Specify default language.
DEUTSCHE.SYS(8) -- German Language Texts.
ENGLISH.SYS(8) -- English Language Texts.
ESPANOL.SYS(8) -- Spanish Language Texts.
LANGS.SYS(8) -- Language selection file.
FTPCLI
FTPCLI.SYS(8) XROUTER REFERENCE MANUAL 8/9/2023
NAME
FTPCLI.SYS -- FTP Client Account File.
DESCRIPTION
The FTPCLI.SYS file contains account and connection info
used for automating logins to FTP servers.
FORMAT
The entries in ACCESS.SYS are of the form:
<name> <host>[:port] [username [passwd [account [timeout]]]]
<name> is a short "handle" for the connection.
<host> is the hostname or IP address of the server.
[port] is the TCP port number of the server. Default 21.
[username] is the the one required by the server. If not
specified here, the server will ask for it.
[passwd] is the password associated with [username]. If
not specified, the server will ask for it.
[account] may be required by some servers.
[timeout] is the maximum number of seconds to wait for a
response to a command. Default is 20.
Use asterisk (*) as a placeholder for empty fields
EXAMPLES
stest speedtest.tele2.net anonymous anon
gb3kc gb3kc.dyndns.org g8pzt password * 10
xrpi 192.168.1.221:31 g8pzt myverylongpassword
SEE ALSO
FTP(1) -- Invoke Fie Transfer Protocol Client.
FWD
FWD.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
FWD.SYS -- Mailbox Forwarding Control File.
DESCRIPTION
The optional file FWD.SYS, which resides in the PMS folder,
controls when & how queued mail is delivered to neighbours.
It is read "live" during each forwarding run, so it can be
edited on the fly, and any edits take effect immediately.
FORMAT
Comment lines are allowed. They must begin with hash (#) or
semicolon (;) in the leftmost column.
There is one "block" of lines controlling the forwarding for
each neighbour BBS.
Each block starts with: "@<bbs> <options>"
<bbs> is the callsign (without SSID) of the target
mailbox. This must exactly match a <send_via>
in DISTRIB.SYS.
<options> are as follows:
F = Forward mail, if we have any to send
P = Poll for mail even if we have none to send
The second line of each block specifies the days of the week
(0=Sunday) on which forwarding to this neighbour is allowed.
For example: "0,3-4,6" (no whitespace)
The third line of each block specifies the hours of the day
during which forwarding to this neighbour is allowed
For example: "4-12,14,17-21" (no whitespace)
Subsequent lines in the block are the "connection script" as
follows:
T <secs> specifies a timeout for the connection
C <call> initiates connection (waits for "Connected to")
S <text> sends <text>
W <text> waits for <text> in the received data
Each "block" must end with a short line of dashes: "-------"
EXAMPLES
# Forward and poll VE2PKT midnight to 8am, weekends only:
#
@VE2PKT FP
0,6
0-8
C KIDDER
C PKTXRP
C VE2PKT
----------
# Forward to GB7NXT any day, any time, but don't poll
@GB7NXT F
0-6
0-23
C KIDDER
C GB7NXT
W NXTNOD:GB7NXT}
S BBS
------
; Forward and poll VA2OM any day, mornings & evenings only:
;
@VA2OM FP
0-6
8-11,17-20
C KIDDER
C VA2OM-14
S PMS
----------
SEE ALSO
FF(4) -- Force Forwarding.
FP(4) -- Force Polling.
SF(4) -- Stop Forwarding.
VF(4) -- View Forwarding.
DISTRIB.SYS(8) -- Mail Distribution Control File.
PMS(9) -- About the Mailbox.
HOLD
HOLD.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
HOLD.SYS -- Control File for Mail Holding.
DESCRIPTION
The optional file HOLD.SYS, which resides in the PMS
subdirectory, controls the "holding" of messages.
It is read "live" upon receipt of each new mesaage, so it can
be edited on the fly, and any edits take effect immediately.
Entries in this file allow messages to be automatically held
for review depending on the contents of its TO, FROM, or AT
fields, and whether or not it was entered locally.
Held messages are not forwarded, and are only visible to
sysops.
FORMAT
Comment lines are allowed. They must begin with a hash (#) or
a semicolon (;) in the leftmost column.
Each "active" line must have exactly 5 fields as follows:
<source> <type> <to> <from> <at>
<source> can be 'L' for "locally entered", or '*'.
<type> is the message type, e.g. 'P'", 'B', 'A', 'T' etc.
<to> is the addressee of a private message or the
"category" of a bulletin.
<from> is the callsign of the message creator.
<at> is the callsign of the destination mailbox (personal
mail and "targeted" bulletins), or the "distribution
area for a bulletin, e.g. "GBR".
OPERATION
Rules are processed in the sequence in which they are
declared in the file.
If all 5 fields of any rule match characteristics of a
message, that message is held.
EXAMPLES
The first example holds all bulletins addressed to PORN, and
all locally-entered mail of any type:
# Source Type To From At
# ==========================
* B PORN * *
L * * * *
The next example holds locally entered bulletins, except those
with a blank AT field. This allows users to post bulletins
which stay on this bbs with no interference:
# Source Type To From At
# ==========================
L B * * ?*
The next example holds all bulls from LU9DCE, and demomstrates
the use of semicolons instead of hashes for comment lines:
; Source Type To From At
; ==================================
* B * LU9DCE *
Finally, hold all private mail addresed to "g9pzt":
; Source Type To From At
; ==================================
* P G9PZT * *
SEE ALSO
HOLD(4) -- Hold a Message.
KH(4) -- Kill Held Mail.
LH(4) -- List Held Mail.
UH(4) -- Un-hold Messages.
PMS(9) -- Avout the Mailbox.
HTTP
HTTP.ACL(8) XROUTER REFERENCE MANUAL 16/10/2023
NAME
HTTP.ACL -- HTTP Proxy Egress Control File (Optional).
DESCRIPTION
The HTTP.ACL file contains "rules" to control which
destinations are allowed to be accessed via the HTTP
proxy/tunnel.
The rules allow you to specify which destination IP
addresses and TCP ports may be accessed by specified
source IP ranges.
If the file is not present, or contains no valid rules,
all destinations are blocked, and the "403 Forbidden"
error page is returned to anyone who tries to use the
proxy or tunnel.
Egress control is vital to prevent miscreants using your
HTTP server as a proxy to hide their IP address.
FORMAT
The format of the entries in HTTP.ACL is the same as
other .ACL (Access Control List) files.
Each "rule" is specified on a separate line. Blank lines,
or lines beginning with ';' or '#' are ignored. The
maximum line length is 255 characters.
Within each rule, fields must be separated by one or
more spaces or tabs. The fields are as follows:
<action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>
The fields have the following meaning:
<action> PERMIT Allow egress
DENY Prevent egress
<src_ip> Source IP address (uplinked user).
<dst_ip> Destination IP address (target system).
[mask] Optional field.
Either: No. of bits (0-32) of address to
match from left to right,
Or: Subnet mask in form n.n.n.n
<port(s)> One or more TCP service numbers (0-65535) on
the target system. Allowed formats are "n",
"n,n,n", "n-n" or combination thereof.
In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
"all addresses".
NOTE
Rule testing stops at the *first* matching "permit" or
"deny" statement, so it is vital that the list is ordered
correctly. For instance, to allow Internet users to
access all LAN ports except 513 it would be ok to use:
deny 0.0.0.0/0 192.168.0.0/24 513
permit 0.0.0.0/0 192.168.0.0/24 1-65535
but if the entries were reversed, the "permit" rule would
match every case and the "deny" rule wouldn't be actioned.
EXAMPLES
; Allow LAN users to tunnel to anyone:
PERMIT 192.168.0.0/24 0.0.0.0/0 0-65535
;
; Allow Internet users to tunnel only to certain
; ports on the node machine:
PERMIT 0.0.0.0/0 192.168.0.245 23,87,1448,3600
;
; Allow Internet users to tunnel only to ports 23
; and 80 on the BBS machine:
PERMIT 0.0.0.0/0 192.168.0.4 80,23
;
; Allow Amprnet users to access any Amprnet destination
PERMIT 44.0.0.0/8 44.0.0.0/8 0-65535
FILES
If required, HTTP.ACL must be located in the same
directory as the XRouter executable.
SEE ALSO
HTTP.SYS(8) -- HTTP Rewrite / Proxy Control File
SOCKS.ACL(8) -- SOCKS Proxy Egress Control File
TELPROXY.ACL(8) -- Telnet Proxy Egress Control File
HTTPBAN
HTTPBAN.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
HTTPBAN.SYS -- Blocks Malicious HTTP Requests (Optional).
DESCRIPTION
XRouter's HTTP server doesn't suffer from the usual Windows
vulnerabilites, so malicious HTTP requests designed to
exploit them are simply a bandwidth-wasting nuisance
rather than a real threat. You can frustrate the hackers
by deploying this optional file.
The HTTPBAN.SYS file contains "signatures" or "templates"
of typical malicious request URL's. For example a request
for "default.ida" is part of a Code Red Worm attack, whilst
requests for "cmd.exe" are an attempt to locate vulnerable
Windows servers.
Each template is specified on a seperate line, can be up
to 127 characters long, and must start in the leftmost
column. The templates are compared in a sliding match with
each requested URL.
If any part of the first 256 bytes of the URL matches a
template, the sender's IP address is entered into a ban
list and all further IP datagrams from that host are
ignored until XRouter is restarted.
Up to 20 hosts can be banned simultaneously.
OPTIONS
The file may contain comments, which must begin with
'#' or ';' in the left-most column.
If a template is preceded by the word ANYCASE, a case
independent match is performed, otherwise the match is
case-sensitive. There must be one or more spaces between
the word ANYCASE and the template.
EXAMPLES
default.ida
ANYCASE cmd.exe
/contac.php
FILES
If required, HTTPBAN.SYS must be located in the same
directory as the XRouter executable.
SEE ALSO
HTTP.ACL(8) -- Egress Control for HTTP Proxy / Tunnel
HTTP.SYS(8) -- HTTP Rewrite / Proxy rules
HTTP
HTTP.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
HTTP.SYS -- HTTP Rewrite / Proxy Control File (Optional).
DESCRIPTION
HTTP.SYS is an optional file. If present, it contains
REWRITE rules for the HTTP server, and settings for the
HTTP proxy server.
URL rewriting modifies the URL's of incoming requests,
according to a set of REWRITE rules. This can be used to
organise widely-dispersed resources into a logical
directory tree.
The resources may be located on the same PC or even on
different servers, but can be made to look as if they are
all in the same tree on your server. This is done by
replacing parts of the requested URL with alternative
strings of characters.
The PROXY commands configure XRouter's HTTP proxy to use a
"downstream" proxy to reach certain IP address ranges.
FORMAT
Each command or rule must be on a separate line, and may be
up to 255 characters long. Lines beginning with ';' or '#'
are ignored, and may be used for comments. Commands and
rules are not case sensitive, and their fields must be
separated by one or more spaces or tabs. Blank lines are
ignored.
The commands and rules are as follows:
REWRITE <old_string> <new_string>
PROXY <ipaddr> <port> <subnet_mask>
PROXYTIMEOUT <secs>
These are discussed in more detail below...
REWRITE
The REWRITE rules have the following syntax:
REWRITE <old_string> <new_string>
<old_string> is a template which is compared with an equal
number of characters from the start of the
requested URL when an HTTP request is received.
The comparison is case-insensitive.
<new string> is the character sequence which replaces
<old_string> if there is a match.
Example: REWRITE /bbs /systems/gb7pzt
This would replace "/bbs" at the start of the URL with
"/systems/gb7pzt". Thus a request for "/bbs/msgs.htm" would
be rewritten to "/systems/gb7pzt/msgs.htm".
There are no validity checks, so you must be careful not to
inadvertently remove / characters from the rewritten string.
e.g. the entry "rewrite /bbs/ http://192.168.0.4" would cause
"/bbs/index.htm" to rewrite as "http://192.168.0.4index.htm",
which will clearly fail.
You can use rewriting to organise your resources into a neat,
logical and compact directory tree, regardless of where they
are actually located.
<new_string> may also contain a URL, which invisibly invokes
the HTTP proxy. For example:
REWRITE /bbs http://192.168.0.4:85
This would replace "/bbs" at the start of the URL with
"http://192.168.0.4:85", so that a URL like:
/bbs/cgi-bin/menu.pz becomes:
http://192.168.0.4:85/cgi-bin/menu.pz
The resulting URL then treated as if it was a proxy request.
When rewriting to proxy another system, the new URL must
begin with "http://<address>[:port]" where <address> can be
either a hostname or IP address.
rewrite http://g8pzt.ath.cx/bbs http://192.168.0.4
PROXY
The PROXY command allows XRouter's HTTP proxy to pass certain
traffic to a downstream proxy. The format of the command is:
PROXY <ipaddr> <port> <subnet_mask>
e.g. "proxy 44.131.91.245 80 255.0.0.0"
<ipaddr> is the IP address of the downstream proxy.
<port> is the TCP port number of the downstream proxy.
<subnet_mask> when combined with the proxy address specifies
the range of addresses which are on the same
subnet as the proxy. These addressess will
bypass the proxy, i.e. XRouter's proxy will
connect directly to them instead of via the
next proxy.
This kludge allows 44-net systems to use a further proxy to
gain a public (Internet) IP address when connecting non-44
websites. This is necessary because 44-net routing is
unreliable at best, i.e. if a 44-net browser tries to
connect directly to Google, the reply probably won't get
routed back.
For example, imagine a mobile station, consisting of a web
browser and XRouter, with an IP/AX25 link to a nearby gateway,
but no Internet connection. The IP address used over the
radio link is 44.131.91.3. The browser has been configured
to use XRouter's HTTP proxy, which means the IP source address
for all HTTP traffic from this station is 44.131.91.3.
Via the nearby gateway, whose IP address is 44.131.91.245,
the mobile station can happily browse 44-net (amprnet)
websites. But when it tries to use Google, the replies
aren't routed back.
However, if the local gateway has been set up with the
above PROXY command, the 44.x.x.x sites will be connected
directly by the mobile XRouter's proxy, whilst the non-44
sites will be passed to the gateway's HTTP proxy, where they
will gain a 62.31.206.176 source address, which is reliably
routable and doesn't rely on the co-operation of others in
the amprnet.
The PROXYTIMEOUT command specifies the maximum time in
seconds to wait for a proxied connection. If a connection
takes longer than this to establish, an error is returned.
The default is 30 secs, but may need to be longer on a
slow radio channel.
FILES
If required, HTTP.SYS must be located in the same
directory as XRouter.EXE.
SEE ALSO
HTTP.ACL(8) -- HTTP Proxy Egress Control File
HTTPBAN.SYS(8) -- Blocks Malicious HTTP Requests
IGATE
IGATE.CFG(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
IGATE.CFG -- IGATE Configuration File.
DESCRIPTION
IGATE.CFG is the configuration file for the APRS IGATE daemon,
therefore you do not need it if you are not using IGATE. It
is a plain text file read each time the daemon is started.
FORMAT
IGATE.CFG is a plain text file. Each configuration keyword
is specified on a separate line. Blank lines, or lines
beginning with ';' or '#' are ignored. The maximum line
length is 80 characters.
Within each directive, fields must be separated by one or
more spaces or tabs. The fields are as follows:
The following keywords are accepted:
IFILTER <from> <to> <text> Internet->Packet filter rules
LOG <0-255> Activity logging level
MAXTRIES <n> Max. server connect attempts.
PAUSE <seconds> Interval between retries.
PFILTER <from> <to> <text> Packet->Internet filter rules
SERVER <ipaddr:port> Internet server to use
SKIP <seconds> Blacklist time after failure
WAIT <seconds> Time to wait for connection
These are fully documented in the section relating to IGATE.
EXAMPLE
Abbreviated example file:
; APRS IGATE Configuration file for XRPi
;
; You can list as many servers as you like.
; They are tried in rotation.
SERVER 213.180.75.122:2023
;
; Wait up to 60 secs for connection before trying next server
WAIT 60
;
; Wait 60 secs between successive attempts to same server
PAUSE 60
;
; Max connect attempts before blacklisting the server
MAXTRIES 10
;
; If blacklisted, don't try the server for 1 hour
SKIP 3600
;
; IFILTER controls gating from internet to packet:
;
; IFILTER From To Text
; -------------------------------------
IFILTER G#* * *
;
; PFILTER statements control gating from packet to internet:
;
; PFILTER From To Text
; ------------------------------------
PFILTER G* AP* *
PFILTER MB7* AP* *
;
; Radius of Interest
;
RADIUS 150
;
; Activity logging
;
LOG 255
FILES
If required, IGATE.CFG should be located in the same
directory as the XRouter executable.
SEE ALSO
IGATE(9) -- APRS Internet Gateway.
IPBAN
IPBAN.SYS(8) XROUTER REFERENCE MANUAL 13/6/2019
NAME
IPBAN.SYS -- Banned IP addresses file.
DESCRIPTION
This optional file is read at bootup. It stores the list of
"banned" IP addresses, plus "honeypot" ports.
If the file doesn't exist, it is created at closedown or by
the "IP BAN SAVE" command, if there are any entries to save.
That comand may also be used in CRONTAB.SYS to save the list
ar regular intervals.
The ban and honeypot lists can be viewed and edited during
run-time using the "IP BAN" command and its sub-commands.
IP Banning
~~~~~~~~~~
If XRouter's IDS (Intrusion Detection System) detects
malicious activity on its own TCP/IP stack, it will "ban" the
originator's IP address. Any further packets from that IP
address are be ignored, as long as the ban lasts.
If malicious activity is detected on any Linux TCP or UDP
port that is currently "owned" by XRouter, that also causes
a ban. In this case, TCP connections are terminated, and any
further connections of UDP frames are ignored.
There is no time limit on IP bans. Up to 200 IP addresses can
be banned at once. A larger table would become unwieldy. When
a new address is added, the oldest one is dropped. In
practice this isn't usually a problem because the oldest
aggressor has usually given up long ago, and is unlikely to
come back.
Honeypots
~~~~~~~~~
In this context, a honeypot a sticky trap, set up on popular
TCP or UDP ports, for catching internet low-life.
Hackbots generally start their attacks by probing for open
TCP ports, and to save time they often start with the most
popular ones - telnet, SSH, HTTP, VNC and so on. If they find
an open port, they tend to inform each other, then they all
concentrate their attacks on that port.
Unless you have a particular service port open, the chances
are that anyone who tries to connect to it is up to no good.
So the honeypot is a mitigation measure. It LOOKS like an
attractive open port, but it's not! Anyone who connects to it
gets their IP address logged and banned. After that they
can't do any more attacking unless they change their IP
address.
It's not foolproof. Nation states and sophisticated hackers
have access to virtually unlimited IP addresses. But it slows
them down, and the IDS alerts you that there is a problem.
FORMAT
IPBAN.SYS is a text file, so it can be viewed and edited with
any text editor, although there should be no need to do so.
Each "entry" in the file is on a separate line.
There are TWO types of entry in IPBAN.SYS, one for banned IP
addresses, and the other for honeypot definitions. The
banned IP entries are of the form:
<ipaddr> <netmask> <type> <hits> <last-hit>
Where:
<ipaddr> is the IP address being banned.
<netmask> specifies how much of the IP address to match
<type> is the type of ban: A=automatic, M=manual
<hits> is the number of times the IP has been seen
<last-hit> is the date/time of the last "hit".
"Automatic" bans are the ones added automatically by XRouter
when it detects malicious activity. "Manual" bans are those
added by the sysop using the "IP BAN" command.
Honeypot entries have the form:
<start> <end> <protocols> <hits> <last-hit>
Where:
<start> is the first TCP/UDP port in the trap range
<end> is the last TCP/UDP port in the trap range
<protocols> are the protocols to trap:
(1=TCP, 2=UDP, 3=both)
<hits> is the number of times the trap was sprung
<last-hit> is the date/time iof the last activation
Date/time is a decimal number representing the number of
seconds since 1/1/1970.
EXAMPLES
; Manual ban for 22.33.44.55 with 123 hits
22.33.44.55 255.255.255.255 M 123 456789012
; Manual ban for 33.22.0.0/16 with no hits yet
33.22.33.11 255.255.0.0 M 0 0
; Automatic ban for 80.193.161.2, seen 789 times
80.193.161.2 255.255.255.255 A 789 324565789
; Honeypot on UDP port 211, no hits yet
211 211 2 0 0
; Honeypot on VNC ports 5900-5999, both TCP and UDP
5900 5999 3 0 0
SEE ALSO
IP(1) -- IP related commands
CRONTAB.SYS(8) -- Time dependent comands
IPROUTE
IPROUTE.SYS(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
IPROUTE.SYS -- IP Router Configuration File (optional).
DESCRIPTION
This optional file is only required if you wish to route IP
traffic, or use any of XRouter's IP facilities such as Telnet,
Ping, Traceroute, HTTP server etc. I.e. it is not required
if you are operating a pure AX25 / Netrom system, although
you are urged to route amateur IP if possible.
The file is read only at boot-up, or by an "IP ROUTE LOAD"
command so if you make changes to it, they won't take
effect until you reboot or use that command. XRouter does
not write to this file.
If IPROUTE.SYS is present, it saves you having to enter
the IP routing manually. To reduce the number of
configuration files, this file also contains the permanent
ARP (Address Resolution Protocol), NAT (Network Address
Translation), RIP (Routing Information Protocol) entries,
and IP filtering rules.
FILE FORMAT
IPROUTE.SYS is a text file. Within the file, each entry
must be on a separate line, and there must be one or more
spaces or tabs between each field. Entries are not case
sensitive. Comments are allowed, providing they are on a
line beginning with a semicolon ';' or hash '#'. Blank
lines are ignored and lines may be up to 255 characters
long.
Commands accepted in this file are as follows:
ACL <PERMIT | DENY>
ARP <ADD | PUBLISH>
DUN <ADD | LOG>
IP <CMD | ROUTE ADD | ROUTE DEFAULT | QUIET | TTL>
NAT <ADD>
RIP <ADD | LEARN | REFUSE | TIMEOUT>
ACL commands control the Access Control List, which
specifies the IP addresses which are allowed to access
and be accessed by XRouter.
ARP commands are used to add "static" entries to the ARP
table. These are mainly used for slow RF links.
DUN commands are used to configure "dial-up" routing.
IP commands are used to add routes to the IP routing table
and to configure the TTL, stealth level, and
availability of the IPROUTE command.
NAT commands add Network Address Translation entries to the
NAT table.
RIP commands control the RIP98 and RIP2 automatic route
learning system.
All of these commands are described in more detail in their
own section 1 MAN pages (see below).
FILES
If present, IPROUTE.SYS must be located in the same
directory as the XRouter executable.
SEE ALSO
ACL(1) -- IP Access Control List Commands.
ARP(1) -- Address Resolution Protocol Commands.
DUN(1) -- Dial-up Networking Commands.
IP(1) -- IP Routing / Configuration Commands.
IP-PRIMER(9) -- IP Addressing / Routing Primer.
IPROUTE(1) -- Display IP Routes
NAT(1) -- Network Address Translation Commands.
RIP(1) -- Routing Interface Protocol Commands.
LANGS
LANGS.SYS(8) XROUTER REFERENCE MANUAL 10/9/2023
NAME
LANGS.SYS -- Language Control File.
DESCRIPTION
This optional file is read only at bootup. It controls which
language is used for a caller's session, based on their
callsign.
By default, XRouter uses ENGLISH. If you want to support
additional languages, install the relevant language file(s)
as follows:
French - FRANCAIS.SYS
Spanish - ESPANOL.SYS
German - DEUTSCH.SYS
Dutch - NEDERLANDS.SYS
Language files are read only at bootup.
All sessions use ENGLISH by default, UNLESS you install
LANGS.SYS, which tells XRouter which language to use for a
given callsign.
FORMAT
The entries in LANGS.SYS are of the form:
<callsign_mask> <language_number>
The <callsign_mask> field specifies which callsign(s) will
use the <language_number>. It can be a single callsign e.g.
"F1OTJ" or a wildcard match, e.g. "F*".
<language_number> is a pre-defined index number for the
language to be used. These numbers are fixed, no matter how
many language files are installed: English is always number
0, French is always number 1 and so on.
Comment lines beginning with "#" or ";" in the leftmost
column are allowed.
If you refer to a language nuber, you MUST install that
language file.
EXAMPLE
# LANGS.SYS
#
# Language selection file for XRouter v502
#
# Line format: <callsign_mask> <language_number>
#
# Language numbers:
#
# 0 English
# 1 Francais
# 2 Espanol
# 3 Deutsche
# 4 Nederlandse
#
# The default language for any callsign prefix not in the
# list below is set by DEFAULTLANG in XROUTER.CFG.
#
2* 0
3A* 1
EA* 2
F* 1
G* 0
H* 1
M* 0
ON1K* 1
ON4* 1
ON5* 1
ON6* 1
ON7* 1
ON8* 1
ON9* 1
PA* 4
PB* 4
PC* 4
PD* 4
PE* 4
PF* 4
PH* 4
PH* 4
PI* 4
TK* 1
TU* 1
VA2* 1
VE2* 1
CAVEAT
When BBS software is making connections for forwarding, it
expects to see the English words "CONNECTED TO". If this is a
problem, e.g. the BBS is French you have two options. The first
option is to "comment out" text no. 94 in FRANCAIS.SYS,
allowing it to revert to English for that text only. The second
option is to add an exception for that BBS into this file,
assigning its language to English, e.g. "F1BBS 0". The
exception should be added BEFORE any wildcard entries for that
group pf caallgigns.
NOTES
XRouter's inbuilt language is ENGLISH. If you wish, you may
change the layout and/or wording of most XRouter responses by
installing ENGLISH.SYS in the same directory as XRouter.
XRouter will then use the texts from that file, which you may
modify, instead of the inbuilt ones.
Be careful with modifications, because some of the texts are
used in multiple places, and some of them are column headers
which need to follow a strict format. Installing and modifying
this file is NOT recommended, but it's up to you!
Similar comments apply to the other language files. If you can
improve on them, please do so, and share the results.
If your language is not (yet) one of the supported ones, and
you don't need English, translate ENGLISH.SYS into your own
language. That will become the default language.
SEE ALSO
LANG(1) -- Display / Set Session Language
CONSOLELANG(7) -- Console language
DEFAULTLANG(7) -- Specify default language
XROUTER.CFG(8) -- Main configuration file
PASSWORD
PASSWORD.SYS(8) XROUTER REFERENCE MANUAL 18/10/2023
NAME
PASSWORD.SYS -- Sysop Password File (Optional).
DESCRIPTION
This optional file contains the sysop passwords for AX25
remote access, RLOGIN and FTP. If the file is not present,
these forms of access will not be possible.
These passwords are for SYSOPS only (passwords for users
are stored in USERPASS.SYS).
FORMAT
There should be one entry for each sysop, and each entry
must be on a separate line, Blank lines, or lines beginning
with ';' or '#' are ignored. The maximum line length is 80
characters.
Entries must consist of two fields separated by one or more
spaces or tabs as follows:
<callsign> <password>
<callsign> is the remote sysop's callsign without SSID.
<password> is the password string. Must not contain spaces.
For example: G8PZT thisispaulaspassword
G1LOA thisisrobertspassword
Fields are not case sensitive.
NOTE
You should try to choose a password that you can easily
remember, but others would find hard to guess. It should
preferably be longer than 5 characters, to reduce the
chances of someone guessing it by observing the password
grid and your responses.
The longer you make the password, the more secure it will
be. Try to avoid using well known words or names, because
these are the favourite weapons of attack-bots. If you
can't resist the urge to use the names of your family or
pets, string them together to make a composite word.
A random string is the most secure, because even if
someone works out part of it, they won't be able to guess
the remainder. However you must strike a balance between
security and convenience, because while the password itself
is never sent over the air for AX25 logins, it must be
entered in full for an RLOGIN session.
You may have a different password for each sysop, or you
might choose to give all sysops the same password.
Obviously the former is the most secure, but it's
completely up to you.
FILES
If present, PASSWORD.SYS must be located in the same
directory as the XRouter executable.
SEE ALSO
AXSCTRL(9) -- TCP/IP Access Control.
USERPASS.SYS(8) -- User Passwords File.
PMS
PMS.CFG(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
PMS.CFG -- PMS / BBS Configuration File.
DESCRIPTION
PMS.CFG is an optional configuration file for the inbuilt
mailbox. If present, it is located in the PMS folder. It is
read only when the program starts.
It is a text file containing directives of the general form
<keyword>=<value>, each on a separate line. Keywords are
not case sensitive, and they may be specified in any order.
Blank lines and comment lines are allowed. The latter must
begin with a semicolon (;) or hash (#) in the leftmost
column. Lines must not exceed 255 characters.
If PMS.CFG is not present, the mailbox uses default values.
OPTIONS
The options currently recognised are as follows:
SysopCallsign
Sysop's callsign (defaults to PMSCALL without SSID)
HousekeepInterval
Hours between "housekeeping" sessions (default 24).
Housekeeping removes old messages, optionally re-numbers
the messages to remove gaps, and generates WP updates.
ForwardInterval
Seconds between Forwarding "runs" (default 900)
If set to 0, forwarding is triggered only upon receipt of
mail
FwdKickOnRcv
If set to 1 (default) a forwarding "run" is triggered
immediately upon receipt of new mail. If set to 0,
forwarding is deferred until next "run" is due
AutoRenumber
Controls re-numbering of messages at housekeep time.
If it is non-zero, messages are renumbered if the highest
message number exceeds the specified value. e.g. a value
of 5000 means that messages are not renumbered until the
highest number is equal to, or greater than 5000.
After renumbering, message numbers start at 1 with no
gaps. Default is 0 = no renumbering.
MaxAgeB
Maximum lifefime in days for a bulletin (default 30)
MaxAgePR
Maximum lifetime for private mail that has been read.
(default 180)
MaxAgeMid=30
Maximum lifetime for message identifiers (default 30)
WpUpdateTo
Callsign (without SSID) of neighbour BBS to whom WP
updates are to be sent. Can be used multiple times, to
specify more than one BBS. The default is none, i.e.
don't send WP updates.
EXAMPLES
ForwardInterval=3600
FwdKickOnRcv=0
WpUpdateTo=GB7PZT
SEE ALSO
PMS(1) -- Access Personal Message System(s).
PMS(9) -- About the PMS.
XROUTER.CFG(8) -- Main Configuration File.
PPPHOST
PPPHOST.n(8) XROUTER REFERENCE MANUAL 18/10/2023
NAME
PPPHOST.n -- PPP Configuration File(s) (Optional).
DESCRIPTION
This optional file is required only if a PSTN modem is
connected to XRouter and auto-answer is enabled.
It is read only when a modem caller issues the command
"XLINK PPP", and may contain PPP commands to override the
default PPP configuration for the duration of the call. It
may also contain NAT commands.
The default configuration is probably OK for most purposes,
but you may for example wish to change the inactivity
timeout or the IP address.
There may be several of these files, one for each modem
port. The "n" represents the port number on which the
caller has accessed XRouter.
FORMAT
Each command must be on a separate line, Blank lines, or
lines beginning with ';' or '#' are ignored. The maximum
line length is 127 characters.
See the PPP MAN page for details of the PPP commands.
FILES
If required, this file must be located in the same
directory as the XRouter executable.
SEE ALSO
NAT(1) -- Network Address Translation Commands.
PPP(1) -- PPP Configuration Commands.
PSTN(9) -- PSTN Modem Support.
REJECT
REJECT.SYS(8) XROUTER REFERENCE MANUAL 29/3/2024
NAME
REJECT.SYS -- Mail Rejection Control File.
DESCRIPTION
The optional file REJECT.SYS, which resides in the PMS
subdirectory, controls the "rejecting" of messages. It is
used to reject unwanted types or categories of mail when they
are offered (proposed) by other mailboxes.
The file is read "live" upon receipt of each proposal, so it
can be edited on the fly, and changes take effect immediately.
FORMAT
REJECT.SYS contains "rules" which control rejection of mail.
Each rule must occupy a separate line. Blank lines and comment
lines are allowed. The latter must begin with '#' or ';' in
the leftmost column.
Each rule consists of exactly 5 fields as follows:
<type> <to> <from> <at> <size>
<type> is the message type, i.e. P, B, A, E, T, * etc.
<to> is the destination callsign or bulletin category.
<from> is the sender's callsign.
<at> is the destination BBS or distribution area
<size> is the maximum message size in bytes.
Rules are case-independent, and wildcards are allowed.
The exception is the <size> field where 0 = "don't care".
If <size> is non-zero and the proposed message size is smaller
than <size>, the message is allowed even if all the other
fields match.
Note that only FBB proposals include size, MBL ones don't.
If the <at> field starts with a caret '^', it inverts the
meaning of that field. e.g. "^GBR" rejects all "at" fields
EXCEPT GBR.
OPERATION
Incoming message proposals are tested against each rule in
turn. If a rule matches all the message fields, the message is
rejected.
EXAMPLE
# Reject earthquake bulls of any size, from anyone:
# type to from at size
# --------------------------------
B EQUAKE * * 0
SEE ALSO
HOLD.SYS(8) -- Message Holding Control File.
PMS(9) -- About the Mailbox.
SOCKS
SOCKS.ACL(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
SOCKS.ACL -- SOCKS Proxy Egress Control File (Optional).
DESCRIPTION
The SOCKS.ACL file contains "rules" to control which
destinations are allowed to be accessed via the SOCKS
proxy.
The rules allow you to specify which destination IP
addresses and TCP ports may be accessed by specified
source IP ranges.
If the file is not present, or contains no valid rules,
all destinations are blocked. Attempting to access
a blocked destination causes the proxy to return an
"access denied" code.
FORMAT
The format of the entries in SOCKS.ACL is the same as
other .ACL (Access Control List) files.
Each "rule" is specified on a separate line. Blank lines,
or lines beginning with ';' or '#' are ignored. The
maximum line length is 255 characters.
Within each rule, fields must be separated by one or
more spaces or tabs. The fields are as follows:
<action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>
The fields have the following meaning:
<action> PERMIT Allow egress
DENY Prevent egress
<src_ip> Source IP address (uplinked user).
<dst_ip> Destination IP address (target system).
[mask] Optional field.
Either: No. of bits (0-32) of address to
match from left to right,
Or: Subnet mask in form n.n.n.n
<port(s)> One or more TCP service numbers (0-65535) on
the target system. Allowed formats are "n",
"n,n,n", "n-n" or combination thereof.
In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
"all addresses".
NOTE
Rule testing stops at the *first* matching "permit" or
"deny" statement, so it is vital that the list is ordered
correctly. For instance, to allow Internet users to
access all LAN ports except 513 it would be ok to use:
deny 0.0.0.0/0 192.168.0.0/24 513
permit 0.0.0.0/0 192.168.0.0/24 1-65535
but if the entries were reversed, the "permit" rule would
match every case and the "deny" rule wouldn't be actioned.
EXAMPLES
; Allow LAN users to tunnel to anyone:
PERMIT 192.168.0.0/24 0.0.0.0/0 0-65535
;
; Allow Internet users to tunnel only to certain
; ports on the node machine:
PERMIT 0.0.0.0/0 192.168.0.245 23,87,1448,3600
;
; Allow Internet users to tunnel only to ports 23
; and 80 on the BBS machine:
PERMIT 0.0.0.0/0 192.168.0.4 80,23
;
; Allow Amprnet users to access any Amprnet destination
PERMIT 44.0.0.0/8 44.0.0.0/8 0-65535
FILES
If required, SOCKS.ACL must be located in the same
directory as the XRouter executable.
SEE ALSO
TELGUEST.ACL(8) -- Telnet Egress Control for Guest Users.
TELPROXY.ACL(8) -- Telnet Proxy Egress Control File
HTTP.ACL(8) -- HTTP Proxy Egress Control File
TELGUEST
TELGUEST.ACL(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
TELGUEST.ACL -- TELNET Guest Egress Control File (Optional).
DESCRIPTION
The TELGUEST.ACL file contains "rules" to control which
destinations are allowed to be accessed by "guest" users
using the TELNET command.
The rules allow you to specify which destination IP
addresses and TCP ports may be accessed by specified
source IP ranges.
If the file is not present, or contains no valid rules,
all destinations are blocked. Attempting to access
a blocked destination causes the "Access Denied" response.
If the facility is enabled by suitable entries in
ACCESS.SYS, "Guest" users are those who access XRouter via
Telnet, using the password "guest". As it is not known if
they are genuine Radio Hams, they are prevented from
downlinking to any AX25 or NetRom destination, but the
sysop may choose to allow them to access certain other
destinations using this file.
FORMAT
The format of the entries in TELGUEST.ACL is the same as
other .ACL (Access Control List) files.
Each "rule" is specified on a separate line. Blank lines,
or lines beginning with ';' or '#' are ignored. The
maximum line length is 255 characters.
Within each rule, fields must be separated by one or
more spaces or tabs. The fields are as follows:
<action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>
The fields have the following meaning:
<action> PERMIT Allow egress
DENY Prevent egress
<src_ip> Source IP address (uplinked user).
<dst_ip> Destination IP address (target system).
[mask] Optional field.
Either: No. of bits (0-32) of address to
match from left to right,
Or: Subnet mask in form n.n.n.n
<port(s)> One or more TCP service numbers (0-65535) on
the target system. Allowed formats are "n",
"n,n,n", "n-n" or combination thereof.
In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
"all addresses".
NOTE
Rule testing stops at the *first* matching "permit" or
"deny" statement, so it is vital that the list is ordered
correctly. For instance, to allow Internet users to
access all LAN ports except 513 it would be ok to use:
deny 0.0.0.0/0 192.168.0.0/24 513
permit 0.0.0.0/0 192.168.0.0/24 1-65535
but if the entries were reversed, the "permit" rule would
match every case and the "deny" rule wouldn't be actioned.
EXAMPLES
; Allow LAN users to telnet to anyone:
PERMIT 192.168.0.0/24 0.0.0.0/0 0-65535
;
; Allow Internet users to telnet only to ports 23
; and 80 on the BBS machine:
PERMIT 0.0.0.0/0 192.168.0.4 80,23
;
; Allow Amprnet users to access any Amprnet destination
PERMIT 44.0.0.0/8 44.0.0.0/8 0-65535
FILES
If required, TELGUEST.ACL must be located in the same
directory as the XRouter executable.
SEE ALSO
ACCESS.SYS(8) -- Telnet Access Control File.
HTTP.ACL(8) -- HTTP Proxy Egress Control File
SOCKS.ACL(8) -- SOCKS Proxy Egress Control File
TELPROXY.ACL(8) -- Telnet Proxy Egress Control file.
TELPROXY
TELPROXY.ACL(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
TELPROXY.ACL -- TELNET Proxy Egress Control File (Optional).
DESCRIPTION
The TELPROXY.ACL file contains "rules" to control which
destinations are allowed to be accessed via the Telnet
proxy.
The rules allow you to specify which destination IP
addresses and TCP ports may be accessed by specified
source IP ranges.
If the file is not present, or contains no valid rules,
all destinations are blocked. Attempting to access
a blocked destination causes the proxy session to
disconnect.
If the rules in ACCESS.SYS are such that your Telnet proxy
is accessible without password, then egress control is vital,
to prevent miscreants using your telnet proxy to access other
systems while hiding their IP address.
FORMAT
The format of the entries in TELPROXY.ACL is the same as
other .ACL (Access Control List) files.
Each "rule" is specified on a separate line. Blank lines,
or lines beginning with ';' or '#' are ignored. The
maximum line length is 255 characters.
Within each rule, fields must be separated by one or
more spaces or tabs. The fields are as follows:
<action> <src_ip>[/mask] <dst_ip>[/mask] <port(s)>
The fields have the following meaning:
<action> PERMIT Allow egress
DENY Prevent egress
<src_ip> Source IP address (uplinked user).
<dst_ip> Destination IP address (target system).
[mask] Optional field.
Either: No. of bits (0-32) of address to
match from left to right,
Or: Subnet mask in form n.n.n.n
<port(s)> One or more TCP service numbers (0-65535) on
the target system. Allowed formats are "n",
"n,n,n", "n-n" or combination thereof.
In the <src_ip> and <dst_ip> fields, 0.0.0.0/0 specifies
"all addresses".
NOTE
Rule testing stops at the *first* matching "permit" or
"deny" statement, so it is vital that the list is ordered
correctly. For instance, to allow Internet users to
access all LAN ports except 513 it would be ok to use:
deny 0.0.0.0/0 192.168.0.0/24 513
permit 0.0.0.0/0 192.168.0.0/24 1-65535
but if the entries were reversed, the "permit" rule would
match every case and the "deny" rule wouldn't be actioned.
EXAMPLES
; Allow LAN users to tunnel to anyone:
PERMIT 192.168.0.0/24 0.0.0.0/0 0-65535
;
; Allow Internet users to tunnel only to certain
; ports on the node machine:
PERMIT 0.0.0.0/0 192.168.0.245 23,87,1448,3600
;
; Allow Internet users to tunnel only to ports 23
; and 80 on the BBS machine:
PERMIT 0.0.0.0/0 192.168.0.4 80,23
;
; Allow Amprnet users to access any Amprnet destination
PERMIT 44.0.0.0/8 44.0.0.0/8 0-65535
FILES
If required, TELPROXY.ACL must be located in the same
directory as the XRouter executable
SEE ALSO
SOCKS.ACL(8) -- SOCKS Proxy Egress Control File
TELGUEST.ACL(8) -- Telnet Egress Control for Guest Users.
HTTP.ACL(8) -- HTTP Proxy Egress Control File
TELPROXY
TELPROXY.MSG(8) XROUTER REFERENCE MANUAL 17/10/2023
NAME
TELPROXY.MSG -- Telnet Proxy Logon Message File (Optional).
DESCRIPTION
This optional file is only required if you are using the
Telnet Proxy feature. It contains text which is sent to
the user upon uplink connection to the proxy.
If the file is NOT present, the following default text is
displayed:
Use: Tel[net] <ipaddr> [port]
Ready
>
If the TELPROXY.MSG file is present, its contents are sent
to the user in place of the default text. Therefore you may
customise the logon text to suit your clientele.
EXAMPLE
This is an example of what the TELPROXY.MSG file might
contain:
--------------------- example starts --------------
To connect to another system, use "TEL[net] <ipaddr> [port]"
e.g. Tel 44.131.91.2 7777
Type HELP for any other help
---------------------- example ends -----------------
NOTES
By default, the telnet proxy listens on TCP port 2323. This
may be reassigned or disabled using the TELPROXYPORT
directive in XROUTER.CFG.
FILES
If present, TELPROXY.MSG must be located in the same
directory as the XRouter program.
The associated TELPROXY.ACL file controls which
destinations are available to users, based on their source
IP addresses.
SEE ALSO
TELPROXY.ACL(8) -- Telnet Proxy Egress Control Rules.
USERPASS
USERPASS.SYS(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
USERPASS.SYS -- User Passwords File (Optional).
DESCRIPTION
The entries in this optional file are used, if dictated
by entries in ACCESS.SYS, to control normal Telnet
(port 23) logins, Telnet Proxy (port 2323), and APRS
server (port 1448) logins. They are not used for sysop
logins, RLOGIN or FTP.
Passwords are not required for normal AX25 / NetRom access.
FORMAT
There should be one entry for each user, and each entry
must be on a separate line, Blank lines, or lines beginning
with ';' or '#' are ignored. The maximum line length is 80
characters.
Entries must consist of two fields separated by one or more
spaces or tabs as follows:
<callsign> <password>
<callsign> is the user's callsign without SSID.
<password> is the password string. Must not contain spaces.
Fields are not case-sensitive.
EXAMPLE
; USERPASS.SYS for Xrouter
;
; This file contains passwords for Telnet and Modem logins.
;
; Fields are: <callsign> <password>
; Callsigns should not include SSID
;
G8PZT amazon
G7CXZ drvxcdfre
;
NOTE
For extra security, it is advisable for sysops to use
different passwords for telnet and RLOGIN.
FILES
If present, USERPASS.SYS must be located in the same
directory as XRouter itself.
SEE ALSO
PASSWORD.SYS(8) -- Sysop Password File.
XENCAP
XENCAP.TXT(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
XENCAP.TXT -- Amprnet Encapsulated Routing File (optional).
DESCRIPTION
This experimental file is similar to ENCAP.TXT, except that it
allows encapsulation modes other than "encap" to be specified.
It is thus an e(X)tended version of ENCAP.TXT. Its purpose is
to allow those XRouter sysops who are unable to handle IPEncap
(protocol number 4) to act as amprnet gateways by means of
other protocols, such as IPIP (protocol 94) or IPUDP.
If this file is present when XRouter boots up, it will read
the routes into its IP routing table.
If you are not running an amprnet "gateway", or have set up
your own encap routes in IPROUTE.SYS, you do not need this
file.
FORMAT
The format of routing entries in XENCAP.TXT is almost
identical to those in ENCAP.TXT, with the exception that the
word "encap" may be replaced by other modes:
route addprivate 44.131.91.0/24 <mode> 62.31.206.176
The "addprivate" stipulates that the route should be hidden
from users, i.e. not displayed by the IPROUTES command.
The "44.x.x.x/xx" part specifies which amprnet route(s)
this entry applies to.
The "<mode>" part tells XRouter which encapsulation mode to
use as follows:
encap - IP-over-IP protocol 4
ipip - IP-over IP protocol 94
ipudp - IP-over-UDP
The final field is the Internet IP address of the gateway
which handles the specified amprnet route(s).
FILES
If required. XENCAP.TXT should be located in same directory
as the XRouter executable.
CAVEATS
This file is experimental, and the format is likely to change
to accommodate more features in the future.
SEE ALSO
ENCAP.TXT(8) -- Encapsulated Routing File.
IPROUTE.SYS(8) -- IP Routing and Configuration File
XRNODES
XRNODES(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
XRNODES -- Routes / Nodes Recovery File.
DESCRIPTION
The XRNODES file contains a list of the known NetRom
routes and nodes, and is used to populate the nodes table
when XRouter boots. This allows XRouter to be stopped and
restarted without losing the nodes table. Without this
file, it would take several hours to rebuild the nodes
table from received broadcasts.
The nodes and routes tables are saved to this file every
NODESINTERVAL, at close-down, and whenever the SAVENODES
command is used (unless a different filename is specified).
The file is created by XRouter, but may be edited by the
sysop. Apart from the lack of .TXT extension, it is an
ordinary plain text file.
FORMAT
The ROUTE entries are specified first, and have the
following format:
ROUTE ADD <call> <port> <qual> [!] [VIA call ...] [options]
<call> is the callsign of the neighbour node.
<port> is the port on which the neighbour is reached.
<qual> is a "quality" between 0 and 255 indicating how
"good" the route is.
[!] indicates a locked route (i.e. one which will not expire).
[VIA] indicates that the neighbour is reached via
digipeater(s). Digipeater callsigns are separated by
exactly ONE space, with the end of the list marked by
exactly TWO spaces.
[options] are "non-standard" parameters which can override
the port defaults for that route as follows:
[maxframe [frack [paclen [maxtt [maxhops]]]]]
For example:
ROUTE ADD W7XCV 1 100
ROUTE ADD G8UYL 2 240 ! 5 7000 120
ROUTE ADD G7DIG 5 ! VIA M7FRT M3RED 2
The first line shows unlocked neighbour W7XCV on port 1
with quality of 100. The second line shows neighbour
G8UYL locked in on port 2 with a quality of 240,
maxframe of 3, frack of 7000, and paclen 120. The
third line shows neighbour G7DIG locked in using a
digipeated path via M7FRT and M3RED, with maxframe of 2.
Following the ROUTE entries, the remainder of the file
consists of NODE entries, one per line. The format is as
follows:
NODE ADD <alias:call> <r1> <p1> <q1> [!] [<r2> ...]
<alias:call> is the alias and callsign of the distant node.
<r1> is the callsign of the primary route to that node,
for which there must exist a ROUTE entry.
<p1> is the port used to reach the neighbour.
<q1> is the quality of the route to the node via that
neighbour.
[!] indicates a locked entry.
There can be up to 3 different routes listed for each node.
For example:
NODE ADD #TLFRD:GB7IPT-7 G8PZT 1 142 ! G8UYL 2 139
NODE ADD BRUM:GB7BM G8PZT 1 94 G8UYL 2 92
NODE ADD BUXTON:GB7DAD-8 G8PZT 1 22 G8UYL 2 21
FILES
XRNODES is located in the same directory as XRouter.
CAVEATS
If XRouter is closed down for more than a few hours, the
network may change, and the XRNODES file will become out
of date. This could re-introduce expired nodes back into
the tables when XRouter is started. In this case it would be
better to delete XRNODES before booting up, and let XRouter
rebuild the tables from broadcasts.
SEE ALSO
LOADNODES(1) -- Load the nodes and routes tables.
SAVENODES(1) -- Save the nodes and routes tables.
XROUTER
XROUTER.CFG(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
XROUTER.CFG -- Main Configuration File (Mandatory).
DESCRIPTION
This file is mandatory, and contains most of the
configuration info for XRouter. It is read only when the
program starts.
It is a text file containing directives of the general form
<keyword>=<value>, each on a separate line. Keywords are
not case sensitive, and in general they may be specified
in any order, but interfaces MUST be defined before the
ports that reference them.
Blank lines are allowed, and comment lines must begin with
a semicolon (;) or hash (#) in the leftmost column. Lines
must not exceed 255 characters.
The sections of the file outside the INTERFACE, PORT, RADIO,
CONSOLE, APPL and ROUTES blocks, are considered "global",
i.e. this is where the keywords with global action can be
used. E.g. this is where the node callsign and alias are
specified.
Some of the keywords, e.g. IPADDRESS and PACLEN may be
used globally (to set defaults) and within PORT definition
blocks (to set port-specific overrides).
In the following sections, '*' indicates the mandatory
parameters. Additional parameters (e.g. IPADDRESS) may need
to be specified to enable full operation. Remaining
parameters have sensible defaults built into the program.
Defaults are indicated in brackets ().
GLOBAL KEYWORDS
The following keywords are accepted in the GLOBAL section:
ACTIONCOLOR Text colour for pending actions (yellow)
AGWPORT TCP port for AGWPE emulator (8000)
ALTITUDE Site altitude above mean sea level (0)
APPL Begins an application definition block
APPLQUAL Default NetRom quality for applications (150)
APRSCALL Callsign used by Igate
APRSPORT TCP port for APRS server (1448)
AUDIODEVICE Audio output device name
BELL Allowed times for console bells (0800-2200)
BLEVEL Netrom Budlist de-rate level.
BOOTWIN Window to display after bootup (6)
CHATALIAS Chat server alias
CHATCALL Chat server callsign
CHATLINKS Callsigns of linked chat servers
CHATLOG Controls logging of chat server activity (0)
CHATPORT TCP port for Chat server (3600)
CHATQUAL Chat server Netrom quality to bcast (150)
COMMAND Creates a custom command.
CONSOLE Begins a CONSOLE definition block.
CONTACT Sysop's contact details.
CTEXT Text sent to a users upon connection
CTFLAGS Flags which control sending of CTEXT (9)
CTRLADDR Hex address of hardware control port (378)
DEFAULTLANG Default language number (0)
DCACHE Size of domain cache (10)
DISCARDPORT TCP port for Discard server (9)
DNS Domain Name Server to use (internal)
DOMAIN Domain suffix (ampr.org.)
DXFLAGS Controls the DX heard display (0)
ECHOPORT TCP port of Echo server (7)
ENABLE_LINKED Controls who may use "*** LINKED AS"
EXCLUDE AX25 L2 callsign Blacklist
FINGERPORT TCP port of Finger server (79)
FTPPORT TCP port for FTP server (21)
HAAT Antenna Height Above Average Terrain (0)
HAMLIBPORT TCP Port for Hamlib emulation server
HIDENODES Controls visibility of '#' nodes (0)
HOSTNAME Host name for TCP/IP operations
HTTPPORT TCP port for HTTP server (80)
HTTPROOT HTTP server's root directory (HTTP)
IDINTERVAL Minutes between IDTEXT broadcasts (15)
IDLETIME Idle link shutdown time in secs (900)
IDTEXT ID beacon sent every IDINTERVAL
IGATE Controls whether Igate starts at boot up (0)
INFOTEXT Text sent in response to "I" command
INPBCINTERVAL Secs between scheduled INP3 unicasts (600)
INTERFACE * Begins Interface definition block
IPADDRESS Main (amprnet) IP address (0.0.0.0)
IPENCAP Enable/disable IPENCAP protcol 4 (0)
IPIP Enable/disable IPIP protocol 94 (0)
IPTTL IP Time to live (255)
IPUDPPORT UDP port for rcving IPUDP traffic (94)
KILONFWD Kill PMS message after forwarding (0)
L3BUDLEVEL Leakage level (0-255) for L3EXCLUDE (0)
L3EXCLUDE Callsigns whose L3 traffic is disrupted
L3RTTINTERVAL Secs between L3RTT checks (300)
L3TTL NetRom layer 3 Time To Live (25)
L4DELAY NetRom layer 4 delay in secs (3)
L4RETRIES NetRom layer 4 retries (3)
L4T3 L4 link check interval in secs (840)
L4TIMEOUT NetRom layer 4 timeout in secs (120)
L4WINDOW NetRom layer 4 window (10)
LATITUDE Latitude in decimal degrees (999)
LOCATOR Maidenhead QTH locator (empty)
LOG Controls activity logging level (0)
LONGITUDE Longitude in decimal degrees (999)
MAPCOMMENT Short text to display on nodes map
MAPSERVADDR Hostname / IP address of nodes map server
MAPSERVPORT TCP port of nodes map server (80)
MAXARP Max size of ARP table (20)
MAXCIRCUITS Max concurrent NetRom L4 circuits (20)
MAXHOPS Max acceptable hop count (30)
MAXLINKS Max simultaneous AX25 L2 connections (30)
MAXNODES Max size of NetRom nodes table (200)
MAXROUTES Max NetRom neighbour routes (30)
MAXSESSIONS Max simultaneous sessions (20)
MAXTCP Max simultaneous TCP connections (20)
MAXTT Maximum Trip Time in secs (500)
MINQUAL Minimum NetRom quality in nodes table (10)
MQTTSERVADDR Hostname / IP addr of external MQTT broker
MQTTSERVPORT TCP port of external MQTT broker (1883)
NFTPROOT Root directory for Netrom FTP
NODEALIAS * AX25/NetRom alias of this node
NODECALL * AX25/NetRom callsign of this node
NODESINTERVAL Mins between nodes broadcasts (60)
NUMCONOLES Number of consoles (3)
OBSINIT NetRom obsolescence initial value (5)
OBSMIN NetRom obsolescence min to broadcast (3)
PACLEN AX25 default / NetRom packet length (120)
PMSALIAS AX25/NetRom alias of integral PMS
PMSCALL AX25/NetRom callsign of integral PMS
PMSHADDR PMS hierarchical address
PMSQUAL PMS NetRom quality to broadcast (0)
PORT * Begins a port definition block
PROMPTCOLOR Text colour for normal prompts (cyan)
PROXY Defines a NetRom proxy
QUALADJUST Derates NetRom quality by callsign (255)
QTH Location of this node (empty)
RADIO Begins a RADIO definition block
RHPPORT Remote Host Protocol server TCP port (9000)
RIGSRVPORT TCP port for radio server
RLOGINPORT TCP port for Rlogin server (513)
ROUTES Specifies locked-in NetRom routes
ROWS Vertical size of display in rows (25)
SESSLIMIT Max sessions per user (10)
SOCKSPORT TCP port for SOCKS proxy server (1080)
SORTBYCALL Sort nodes table by callsign not alias (0)
SYNCACHELIFE Lifetime in seconds of a cached TCP SYN (10)
SYNCACHESIZE Number of SYN cache slots (1000)
T3 AX25 link check timer in secs (180)
TELNETPORT TCP port for Telnet server (23)
TELPROXYPORT TCP port for Telnet Proxy server (2323)
TEXTCOLOR Text colour for normal text (white)
TTYLINKPORT TCP port for TTYLINK server (87)
UIFLOOD APRS N-n digipeating (WIDE)
UITRACE APRS N-n digipeating (TRACE)
WARNCOLOR Text colour for warnings & errors (cerise)
WXFILE Weather import file name
APPL KEYWORDS
The following keywords are accepted in the APPL blocks:
APPLALIAS Aplication alias
APPLCALL Application callsign
APPLFLAGS Flags which control application
APPLNAME Application name
APPLQUAL Application NetRom qulity to broadcast
APPLTYPE Type of application (for TCP only)
ENDAPPL * Ends application definition block
CONSOLE KEYWORDS
The following keywords are accepted in CONSOLE blocks:
ACTIONCOLOR Text colour for confirming actions (yellow)
BOTWINBGCOLOR Background for menu bar (cyan)
BOTWINTXTCOLOR Text colour for menu bar (white)
CAPTIONCOLOR Text colour for captions (lime)
CMDWINBGCOLOR Background color for command line (navy)
CMDWINTXTCOLOR Text colour for command line (yellow)
CONSOLECALL Callsign for console operations
CONSOLELANG Language number for console ops (0=English)
ECHOCOLOR Colour for text echoed from cmd line (yellow)
ENDCONSOLE * Ends console definition block
MIDWINBGCOLOR Background for central window (black)
MIDWINTXTCOLOR Text colour for central window (white)
MMASK Flags specifying protocols to trace (3f8)
MPORTS Ports to monitor by default (all)
PROMPTCOLOR Text colour for prompts (cyan)
REVIEW No. of lines of scrollback (400)
RXCOLOR Text color for RX tracing (lime)
TOPWINBGCOLOR Status line background colour (cyan)
TOPWINTXTCOLOR Status line text colour (white)
TXCOLOR Text colour for TX tracing (pink)
WARNCOLOR Text colour for warning/error msgs (cerise)
INTERFACE KEYWORDS
The following keywords are accepted in INTERFACE blocks:
APPLNUM Application number (DEDHOST only)
CHANNEL Channel on multi-channel hardware
CHANNELS No. of TNC channels (DEDHOST only)
COM COM number
CONFIG Hardware-specfic coonfig options
ENDINTERFACE * Ends interface definition block
ETHADDR Ethernet address (NdisXpkt only)
FLOW Flow control options (async only)
ID Interface identification string
INTNUM Was interrupt number, now multi-purpose
IOADDR Was I/O address, now multi-purpose
KISSOPTIONS Options for KISS interfaces only
MTU * Maximum Transmission Unit
PROTOCOL Protocol used on this interface
RADIO Radio number associated with interface
SPEED Serial (async) or RF (SCC) baud rate
TYPE * Type of hardware
PORT KEYWORDS
The following keywords are accepted in PORT blocks:
APPLMASK Controls which applications are visible
APRSPATH Default digipeater path for APRS
BCAST List of destinations for "broadcasting"
BCFROM Callsigns who may broadcast
CFLAGS Controls AX25 up/downlinking
CHANNEL Channel to use on interface (A)
CHATALIAS Port override for global chatalias
CHATCALL Port override for global chatcall
CTEXT Port override for global ctext
CTFLAGS Port override for global ctflags
CWID Text to send in CW every 30' (SCC only)
DHCP Enables / disables DHCP client (0)
DIGIFLAG Controls digipeating
DIGIPORT Port to digipeat on (this port)
DYNDNS Enable / disable Dynamic DNS update client
ENDPORT * Ends port definition block
EXCLUDE List of callsigns not allowed to connect
FEC Enable / disable Forward Error Correction (0)
FRACK AX25 Frame Acknowledgement time ms (7000)
FREQUENCY Radio frequency in Hz (0)
FULLDUP Allow simultaneous TX/RX (SCC only)
ID * Text to identify port on ports display
IDPATH Dest & digi path for ID beacons ("ID")
IDTEXT Port override for global IDTEXT
INITSTR Modem initialisation string (modem only)
INTERFACENUM * Interface number this port is bound to
INTERLOCK Prevents simultaneous TX on SCC cards
IPADDRESS Port override for global IP address
IPLINK IP address / hostname of AXIP/AXUDP peer
MAXFRAME Max outstanding AX25 L2 frames (3)
MAXHOPS Port override for global MAXHOPS
MAXTT Port override for global MAXTT
MHEARD Enable / disable MHeard on this port
MHFLAGS Controls contents of MHeard list (255)
MINQUAL Port override for global MINQUAL
MINTXQUAL Min NetRom quality to broadcast
NETMASK Subnet mask used with IPADDRESS
NODESINTERVAL Port override for global NODESINTERVAL
PACLEN Port override for global PACLEN
PERSIST Probability to transmit 0-255 (64)
PIPE Creates a "frame pipe" to another port
PIPEFLAG Controls frame piping (3)
PMSALIAS Port override for global PMSALIAS
PMSCALL Port override for global PMSCALL
PORTALIAS Port override for global NODEALIAS
PORTALIAS2 Secondary alias for digipeating only.
PORTCALL Port override for global NODECALL
PROXY NetRom systems to tunnel AX25 to
QUALITY Default NetRom neighbour quality (10)
RESPTIME AX25 delayed ack timer in ms (2000)
RETRIES Max connect/disconnect/resent attempts (10)
RFBAUDS RF baud rate (1200)
SESSLIMIT Max simultaneous connections per user (255)
SLOTTIME CSMA interval timer (millisecs) (100)
SOFTDCD Use software DCD (SCC only) (0)
SYSOP If 1, all users on this port are sysops (0)
TXDELAY Delay (ms) between PTT and start of data (300)
TXPORT Port on which to TX if not this one (0)
TXTAIL Delay (ms) between data end and PTT drop (100)
UDPLOCAL RX UDP port for AXUDP operations (93)
UDPREMOTE TX UDP port / Partners AXUDP RX port (93)
UNPROTO Dest & digi calls for unproto broadcasts
USERS Max simultaneous users on this port (255)
VALIDCALLS Only these callsigns allowed to connect.
RADIO KEYWORDS
The following keywords are accepted in RADIO blocks:
BAUDS Baud rate for the TTY (not for Hamlib).
COM TTY device name / IP address:port
ENDRADIO End RADIO definition block.
FREQUENCY Initial receive frequency in Hz.
MODE Initial modulation mode.
NAME Name / Description for the radio
OFFSET Radio's frequency error in PPM
PTTMETHOD How the PTT is controlled
RXAUDIODEV Device for receiving audio from radio
SQUELCH Initial squuelch level
STOPBITS Number of "stop" bits on the serial data
TXFREQ Initial TX frequency (if different to RX)
TYPE Type number of radio
VOLUME Initial volume level
FILES
XROUTER.CFG must be located in the same directory as the
XRouter executable.
SEE ALSO
APPLS(9) -- Application Support.
IFACES(6) -- Interfaces in XRouter.
PORTS(6) -- PORTS in XRouter.
RADIO(7) -- Radio Control Definition Block.
XWEB
XWEB.CLASS(8) XROUTER REFERENCE MANUAL 19/10/2023
NAME
XWEB.CLASS -- Java Applet.
DESCRIPTION
(The following is also in the HTTP-SRV manual page)
The Java applet XWEB.CLASS can be used to connect to XRouter
with a web browser.
The distribution archive contains the applet file, plus 3
rudimentary .HTM pages for you to examine or experiment with.
CONNECT.HTM is the menu page for 3 types of connection, and
would typically be accessed via a "connect" link on the main
page. You may however wish to put the 3 connect options
directly on the main page - it's up to you.
CONN23.HTM uses the Java applet to perform a normal telnet
connect to port 23. The port number is configurable (see
below), so you could clone the page for use with your chat
server.
CONN80.HTM uses the Java applet to perform a "tunnelled"
connection, which can be used via corporate firewalls which
block normal Telnet.
If you wish to the above files and the applet, they must be
located within the HTTP tree.
You can change the applet colours and font, the number of
rows and columns displayed, and the connection mode (normal
TELNET, or HTTP tunnel), using <PARAM> tags in the HTML file.
For example: <PARAM NAME="font" VALUE="Courier">.
The parameters which can be specified are as follows:
Param name Default Description
rows 22 No. of rows in text window
cols 80 No. of columns in text window
bgcolour Dark grey Applet background colour.
borderColour Light grey Applet framework colour.
textBackground Black Background for text/cmd windows.
textColour White Colour of sent / rcvd text.
font Times Font style for sent / rcvd text
port 9999 TCP port number for connections.
mode Normal Connection mode (normal / proxy).
The only mandatory parameter is "port". This should normally
be 23 for a normal telnet connect or 80 for an http-tunnelled
connect, but you may use other values if you have moved or
translated your Telnet or HTTP ports.
Colours should be specified as a 24 bit hexadecimal number in
'C' style, e.g. 0xEECCFF, where the first 2 digits represent
the RED value, the second two digits represent the GREEN
value and the last two digits represent the BLUE value. Some
browsers can only display 216 discrete colours, so you should
preferably use the "browser-safe" values, which are all
formed from combinations of 00, 33, 66, 99, CC and FF.
The default font is quite small, and the characters are not
of a constant width, which means tables sent by XRouter will
not line up correctly. You may use the "font" parameter to
override the default. The recommended font is "Courier",
which is slightly larger and uses constant width characters.
Note: if the chosen font is not found on the client's device,
their default font will be used, so stick to the common ones.
You may need to reduce the number of rows or columns
displayed by the applet if you find it won't fit on a 640*480
screen. It fits nicely on 800*600, but you may wish to
optimise it for another screen size, or even offer users the
choice.
If you change the font, rows or cols, you may need to tweak
the WIDTH and HEIGHT attributes in the APPLET tag to prevent
parts of the applet from being obscured.
SEE ALSO
HTTP-SRV(9) -- HTTP Server.
packet/xrouter/docs/section8-configurationandsystemfiles.txt · Last modified: 2025/04/22 02:32 by m0mzf