======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: [/bits] e.g. "44.0.0.0/8 1" The and [bits] parameters define a range of IP addresses from whom Telnet connects will be accepted, and 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 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 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: [args] 0-59 0-23 1-31 1-12 0-6 Fields must be seperated by one or more spaces or tabs. is executed if and match the current time, and either the (day of month) or (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** ; [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: [max_size] Message type (e.g. P, B or *) Message recipient or bulletin category (wildcards ok) If the field starts with a caret '^', it REJECTS the message if it matches. e.g. "^EQUAKE" prevents distribution of EQUAKE messages. 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". 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 and all match the fields of the message, the latter is placed on the queue for the mailbox specified by . 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: # [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. # [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. # [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: [ttl] IN A [ttl] IN CNAME [ttl] IN MX [pref] 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 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: 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 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 field behaves slightly differently to the others. The supplied , 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 # #------------------------------------------------------- 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 # #------------------------------------------------------- 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 # #------------------------------------------------------- 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: [:port] [username [passwd [account [timeout]]]] is a short "handle" for the connection. 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: "@ " is the callsign (without SSID) of the target mailbox. This must exactly match a in DISTRIB.SYS. 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 specifies a timeout for the connection C initiates connection (waits for "Connected to") S sends W waits for 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: can be 'L' for "locally entered", or '*'. is the message type, e.g. 'P'", 'B', 'A', 'T' etc. is the addressee of a private message or the "category" of a bulletin. is the callsign of the message creator. 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: [/mask] [/mask] The fields have the following meaning: PERMIT Allow egress DENY Prevent egress Source IP address (uplinked user). 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 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 and 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 PROXY PROXYTIMEOUT These are discussed in more detail below... **REWRITE** The REWRITE rules have the following syntax: REWRITE 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. is the character sequence which replaces 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. 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://
[:port]" where
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 e.g. "proxy 44.131.91.245 80 255.0.0.0" is the IP address of the downstream proxy. is the TCP port number of the downstream proxy. 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 Internet->Packet filter rules LOG <0-255> Activity logging level MAXTRIES Max. server connect attempts. PAUSE Interval between retries. PFILTER Packet->Internet filter rules SERVER Internet server to use SKIP Blacklist time after failure WAIT 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: Where: is the IP address being banned. specifies how much of the IP address to match is the type of ban: A=automatic, M=manual is the number of times the IP has been seen 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: Where: is the first TCP/UDP port in the trap range is the last TCP/UDP port in the trap range are the protocols to trap: (1=TCP, 2=UDP, 3=both) is the number of times the trap was sprung 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 ARP DUN IP NAT RIP 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: The field specifies which callsign(s) will use the . It can be a single callsign e.g. "F1OTJ" or a wildcard match, e.g. "F*". 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: # # 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: is the remote sysop's callsign without SSID. 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 =, 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: is the message type, i.e. P, B, A, E, T, * etc. is the destination callsign or bulletin category. is the sender's callsign. is the destination BBS or distribution area is the maximum message size in bytes. Rules are case-independent, and wildcards are allowed. The exception is the field where 0 = "don't care". If is non-zero and the proposed message size is smaller than , the message is allowed even if all the other fields match. Note that only FBB proposals include size, MBL ones don't. If the 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: [/mask] [/mask] The fields have the following meaning: PERMIT Allow egress DENY Prevent egress Source IP address (uplinked user). 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 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 and 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: [/mask] [/mask] The fields have the following meaning: PERMIT Allow egress DENY Prevent egress Source IP address (uplinked user). 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 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 and 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: [/mask] [/mask] The fields have the following meaning: PERMIT Allow egress DENY Prevent egress Source IP address (uplinked user). 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 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 and 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] [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] [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: is the user's callsign without SSID. 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: ; 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 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 "" 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 [!] [VIA call ...] [options] is the callsign of the neighbour node. is the port on which the neighbour is reached. 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 [!] [ ...] is the alias and callsign of the distant node. is the callsign of the primary route to that node, for which there must exist a ROUTE entry. is the port used to reach the neighbour. 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 =, 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 tags in the HTML file. For example: . 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. ----