======Section 7 - Configuration Directives====== ===== ACTIONCOLOR ===== ACTIONCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023 **NAME** ACTIONCOLOR -- Colour For XRouter Actions and Events. **SYNOPSIS** ACTIONCOLOR= **DESCRIPTION** ACTIONCOLOR is an optional directive that can be used both in the "global" section of XROUTER.CFG, and within CONSOLE definition blocks. It specifies the colour used by XRouter for reporting "actions" such as "Pinging 8.9.8.9", and "events" such as "G9YAK is yelling". If used in the "global" section of XROUTER.CFG, the setting is inherited by all CONSOLEs subsequently defined. If used within a CONSOLE definition block, it applies only to that console, overriding any inherited setting. The default ACTIONCOLOR is YELLOW. Default colours have been carefully chosen for good visibility against a BLACK background. **OPTIONS** should be one of the 16 colour names described in COLOURS(6), but please note that some colour combinations have very poor visibility. In general, the lighter the background colour, the smaller the choice of foreground colours that will work with it. **EXAMPLE** ACTIONCOLOR=PINK **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#ANSI| ANSI(1) -- Enquire/set ANSI colour mode]] \\ [[packet:xrouter:docs:MAN6#COLOURS| COLOURS(6) -- XRouter Display Colours.]] \\ [[packet:xrouter:docs:MAN6#CONSOLES| CONSOLES(6) -- About XRouter Consoles.]] \\ [[packet:xrouter:docs:MAN7#CAPTIONCOLOR| CAPTIONCOLOR(7) -- Colour For Captions and Headings.]] \\ [[packet:xrouter:docs:MAN7#PROMPTCOLOR| PROMPTCOLOR(7) -- Colour For XRouter Prompts.]] \\ [[packet:xrouter:docs:MAN7#WARNCOLOR| WARNCOLOR(7) -- Colour For warnings and Errors.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== AGWPORT ===== AGWPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** AGWPORT -- TCP Port for AGW Emulator. **SYNOPSIS** AGWPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** AGWPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the AGW emulator. If not present, the default is 8000. The AGW emulator enables suitable AGW clients, such as UI-View, to use XRouter instead of AGW Packet Engine. **OPTIONS** If a single argument is supplied, e.g. "AGWPORT=8000", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "AGWPORT=8000 9000", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting AGWPORT to zero on a stack prevents TCP connections to the AGW emulator via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN6#AGWHOST| AGWHOST(6) -- AGW Emulator. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== ALTITUDE ===== ALTITUDE(7) XROUTER REFERENCE MANUAL 20/9/2023 **NAME** ALTITUDE -- Site altitude above mean sea level. **SYNOPSIS** ALTITUDE= **DESCRIPTION** ALTITUDE is an optional directive that may be used anywhere in the "global" section of XROUTER.CFG. If present, it specifies the height of the node site in metres above mean sea level. At present ALTITUDE is reported on the INFO pages for interest purposes only, but may be used for node mapping or APRS in future. **EXAMPLE** ALTITUDE=46 -- Site is 46 metres above mean sea level. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#HAAT| HAAT(7) -- Antenna Height Above Average Terrain.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== APPLMASK ===== APPLMASK(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** APPLMASK -- Application Connectivity Mask. **DESCRIPTION** APPLMASK is an optional PORT configuration keyword, whose purpose is to control which applications are connectible at AX25 L2 on the port. In this context, "applications" refers to programs which use XRouter to provide their connectivity with the outside world. APPLMASK is used only if XRouter is hosting applications, e.g. via the DEDHOST interface. If you want an application to be directly connectible on a particular port, the application must have an APPLCALL, an APPLALIAS or both, and the corresponding bit in that port's APPLMASK must be set. APPLMASK specifies which applications will be directly connectible on a given port. The default is 255, which allows all applications. The value is made up by adding together the desired selection from the following numbers: 1 - Enable Application 1 2 - Enable Application 2 4 - Enable Application 3 8 - Enable Application 4 16 - Enable Application 5 32 - Enable Application 6 64 - Enable Application 7 128 - Enable Application 8 For example, if a port's definition contains "APPLMASK=9", it will only allow direct connections to applications 1 and 4 on that port, providing those applications have either an APPLCALL or an APPLALIAS. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#APPLMASK| APPLMASK(1) -- APPLMASK Command ]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter. ]] \\ [[packet:xrouter:docs:MAN9#APPLS| APPLS(9) -- Application Support. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== APRSPATH ===== APRSPATH(7) XROUTER REFERENCE MANUAL 23/9/2023 **NAME** APRSPATH -- Default Digipeater Path for APRS. **SYNOPSIS** APRSPATH=[,digipeater[,digipeater...]] **DESCRIPTION** APRSPATH is an optional directive, used in PORT configuration blocks within XROUTER.CFG. If present, it specifies the default digipeater path for APRS frames originated by the APRS messaging shell and IGATE. If you omit this, the frames will be sent without digipeaters. APRS messaging shell users may override this path during run-time. **EXAMPLE** APRSPATH=RELAY,WIDE **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#AMSG| AMSG(1) -- APRS Mesaging Mode.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== APRSPORT ===== APRSPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** APRSPORT -- TCP Port for APRS Server. **SYNOPSIS** APRSPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** APRSPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the APRS server. If not present, the default is 1448. The APRS server, enables suitable APRS clients, such as UI-View, to connect to it on the LAN and exchange APRS traffic with each other, with RF and via the IGATE. **OPTIONS** If a single argument is supplied, e.g. "APRSPORT=1234", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "APRSPORT=1234 5678", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting APRSPORT to zero on a stack prevents TCP connections to the server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. The APRS server is also available as NetRomX service 14. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#APRS-SRV| APRS-SRV(9) -- APRS server. ]] \\ [[packet:xrouter:docs:MAN9#APRS-SVC| APRS-SVC(9) -- NetRomX APRS Service. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== AUDIODEVICE ===== AUDIODEVICE(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** AUDIODEVICE -- Specify audio device name. **SYNOPSIS** AUDIODEVICE= **AVAILABILITY** Used only in XROUTER.CFG. **DESCRIPTION** AUDIODEVICE is a global configuration keyword used in XROUTER.CFG to specify the audio device to use for console sounds such as warning bells. If AUDIODEVICE is not specified, sound output is via the PC speaker, if one is fitted. XRouter uses OSS (Open Sound System) (a) because OSS has been found to work much better than ALSA, and (b) because ALSA requires the host machine to have the "libasound" library installed. The XRouter philosophy is to avoid dependencies where possible. Having said that, XRouter can be supplied in "with-ALSA" versions if required. **EXAMPLE** # Audio device for sound output: # Default OSS device is /dev/dsp (/dev/audio on Rasp pi) # AUDIODEVICE=/dev/dsp # **CAVEATS** Linux has been gradually trying to force the use of ALSA by making it more difficult to access OSS. In this case XRouter can be run inside a "wrapper" progream such as AOSS as follows: "aoss /home/pi/xrouter/xrpi" **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AUDIO| AUDIO(9) -- Audio on XRouter ]] \\ [[packet:xrouter:docs:MAN1#BELL| BELL(1) -- Set acceptable hours for console sounds. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== BCAST ===== BCAST(7) XROUTER REFERENCE MANUAL 23/9/2023 **NAME** BCAST -- Destinations for UI Broadcasting. **SYNOPSIS** BCAST=[,dest]... **AVAILABILITY** Sysop-only. **DESCRIPTION** BCAST is an optional PORT configuration directive. It specifies a list of AX25 L2 destination addresses for "UI broadcasting". Received non-digipeater UI frames, addressed to one of these destinations, will be re-broadcasted on all ports which have a matching address in their BCAST list. If no matching ports are found, the frame is broadcast only on the port upon which it is received. This would be used for example to broadcast mail-for beacons or unproto headers from a BBS on one port, onto several other ports. Note: There is also a BCAST *command*, which has a completely different function! **OPTIONS** The destination addresses must be separated by commas and there must be no spaces in the list. **EXAMPLE** BCAST=MAIL,ALL **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#BCAST| BCAST(1) -- Trigger a Nodes Broadcast.]] \\ [[packet:xrouter:docs:MAN7#BCFROM| BCFROM(7) -- Approved UI Broadcasters.]] \\ [[packet:xrouter:docs:MAN9#BCAST| BCAST(9) -- About UI Broadcasting.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== BCFROM ===== BCFROM(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** BCFROM -- Approved UI Broadcasters. **SYNOPSIS** BCFROM=[,callsign..] **DESCRIPTION** BCFROM is an optional PORT configuration directive. If present, it specifies a callsign or list of callsigns who are allowed to use the "UI broadcast" facility (see BCAST). If BCFROM is NOT present, the BCAST facility is unrestricted. BCFROM applies only to frames *directly* received on the port for which it is specified (i.e. not via digipeaters). **OPTIONS** The argument to BCFROM is a single callsign, or a comma separated list of callsigns. There must be no spaces in the list. **EXAMPLE** BCFROM=GB7PZT,GB7MAX **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#BCAST| BCAST(7) -- Destinations for UI Broadcasting.]] \\ [[packet:xrouter:docs:MAN9#BCAST| BCAST(9) -- About UI Broadcasting.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== BLEVEL ===== BLEVEL(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** BLEVEL -- Netrom Budlist de-rate level. **SYNOPSIS** BLEVEL=n (where n is berween 0 and 255) **DESCRIPTION** BLEVEL is an optional global XROUTER.CFG directive. It sets the L3 "budlist level". This is the leakage level (0-255) for L3EXCLUDE. The default is 0 (allow no packets). This allows trafic from "troublesome" users to be "choked" to a greater or lesser degree. This has been found to be more effective than an outright ban, which usually results in more aggressive attacking. The miscreant simply assumes that the network is slow, and he doesn't get to do much. A BLEVEL of 0 blocks all NetRom L3 packets from the stations budlisted by L3EXCLUDE. At the other extreme, 255 allows all packets. The allow-rate is BLEVEL/256, so for example a BLEVEL of 64 would allow roughly 1 in 4 packets through. **AVAILABILITY** Sysop-only. **NOTE** A command of the same name can be used at runtime. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#BLEVEL| BLEVEL(1) -- L3 Budlist de-rate level command. ]] \\ [[packet:xrouter:docs:MAN7#L3EXCLUDE| L3EXCLUDE(7) -- Level 3 Exclusion List. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== BLOGFLAGS ===== BLOGFLAGS(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** BLOGFLAGS -- Options For Sysop's Blog. **SYNOPSIS** BLOGFLAGS=n (where 0 <= n <= 15) **DESCRIPTION** BLOGFLAGS is an optional directive used only in XROUTER.CFG. It controls whether or not the sysop's blog is enabled, whether or not the sysop is notified of new "likes" and replies, and whether or not the activity is published via the MQTT broker. If BLOGFLAGS is omitted, the blog is disabled. **OPTIONS** The argument to BLOGFLAGS is a decimal number, which is the sum of the desired options from the following list: 1 - Enable blog 2 - Notify sysop (via PMS) of new replies 4 - Notify sysop (via PMS) of new "likes" 8 - Publish new posts / replies via MQTT **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#BLOG| BLOG(1) -- Access Sysop's Blog.]] \\ [[packet:xrouter:docs:MAN9#MQTT-SRV| MQTT-SRV(9) -- MQTT Server / Broker]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== BOOTWIN ===== BOOTWIN(7) XROUTER REFERENCE MANUAL 21/9/2023 **NAME** BOOTWIN -- Window to display after bootup. **SYNOPSIS** BOOTWIN=n (where n is 1 to 12 inclusive) **DESCRIPTION** BOOTWIN is an optional directive that can be used anywhere in the "global" section of XROUTER.CFG. If present, BOOTWIN specifies the window number to be displayed immediately after bootup. If not specified, or the number is out of range, it defaults to window 6, the "overview" window. Even if BOOTWIN is specified, if MON ON is used in BOOTCMDS.SYS, the first console is displayed instead. The window numbers in v503 are as follows. Note that the "consoles" are optional, and the number of consoles present is specified at bootup: 1 Sysop chat 2 Chat monitor 3 Session monitor 4 Nodes monitor 5 Routes monitor 6 Status overview 7 Security monitor 8 Console 1 (if present) 9 Console 2 (if present) 10 Console 3 (if present) 11 Console 4 (if present) 12 Console 5 (if present) **SEE ALSO:** \\ [[packet:xrouter:docs:MAN8#BOOTCMDS.SYS| BOOTCMDS.SYS(8) -- Commands executed at boot up]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CAPTIONCOLOR ===== CAPTIONCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023 **NAME** CAPTIONCOLOR -- Colour For Captions and Headings. **SYNOPSIS** CAPTIONCOLOR= **DESCRIPTION** CAPTIONCOLOR is an optional directive that can be used both in the "global" section of XROUTER.CFG, and within CONSOLE definition blocks. It specifies the colour used by XRouter for displaying captions, such as those in PING progress reports, and table headings, such as those in session lists. If used in the "global" section of XROUTER.CFG, the setting is inherited by all CONSOLEs subsequently defined. If used within a CONSOLE definition block, it applies only to that console, overriding any inherited setting. The default CAPTIONCOLOR is LIME. Default colours have been carefully chosen for good visibility against a BLACK background. **OPTIONS** should be one of the 16 colour names described in COLOURS(6), but please note that some colour combinations have very poor visibility. In general, the lighter the background colour, the smaller the choice of foreground colours that will work with it. **EXAMPLE** CAPTIONCOLOR=CYAN **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#ANSI| ANSI(1) -- Enquire/set ANSI colour mode]] \\ [[packet:xrouter:docs:MAN6#COLOURS| COLOURS(6) -- XRouter Display Colours.]] \\ [[packet:xrouter:docs:MAN6#CONSOLES| CONSOLES(6) -- About XRouter Consoles.]] \\ [[packet:xrouter:docs:MAN7#ACTIONCOLOR| ACTIONCOLOR(7) -- Colour For XRouter Actions and Events.]] \\ [[packet:xrouter:docs:MAN7#PROMPTCOLOR| PROMPTCOLOR(7) -- Colour For XRouter Prompts.]] \\ [[packet:xrouter:docs:MAN7#WARNCOLOR| WARNCOLOR(7) -- Colour For warnings and Errors.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CFLAGS ===== CFLAGS(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** CFLAGS -- Connection Control Flags. **SYNOPSIS** CFLAGS=n (n = 0 - 255) **AVAILABILITY** Used in PORT configuration blocks within XROUTER.CFG. **DESCRIPTION** CFLAGS is a port configuration keyword, whose primary function is to control whether or not AX25 level 2 uplinking and/or downlinking is allowed on the port. A command of the same name allows the value to be changed on the fly. A typical use may be to prevent users from uplinking and downlinking on APRS-only ports. It also allows the sysop to control whether or not L3RTT frames are generated on inter-node links, and whether or not AX25 level 2 fragmentation is allowed on the port. **OPTIONS** Add together the decimal values of the desired options from this list: Bit Dec Function --------------------------------------------------------- 0 1 - Allow incoming connections (uplinks). 1 2 - Allow outgoing connections (downlinks). 2 4 - Applications may downlink unconditionally. 3 8 - Suppress L3RTT generation. 4 16 - Allow L2 fragmentation. The default value is 3, i.e. unconditional use of the port. Irrespective of the setting of CFLAGS, the Sysop can always downlink. Bit 2 allows applications to downlink unconditionally, i.e. even if users are prevented from downlinking. Bit 3 was provided to keep the Luddites happy, but its use is strongly deprecated. Setting this flag prevents L3RTT frames from being originated by the port if it is carrying an inter-node link. It will not prevent XRouter from trying to hold inter-node links open, as that is too much of a retrograde step! This bit is not set by default. Note that L3RTT may also be suppressed if a route's MAXTT is 65535. Bit 4 allows AX25 layer 2 fragmentation if it is set. This is required if Forward Error Correction (FEC) is in use, to allow big L3 frames to be sent. **EXAMPLES** CFLAGS=2 - Allow downlinking only CFLAGS=5 - Allow only sysops and apps to downlink. **FILES** xrouter.cfg **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#CFLAGS| CFLAGS(1) -- Display / Set Connection Flags ]] \\ [[packet:xrouter:docs:MAN9#L2FRAG| L2FRAG(9) -- AX25 Layer 2 Fragmentation. ]] \\ [[packet:xrouter:docs:MAN9#L3RTT| L3RTT(9) -- Layer 3 Round Trip Time. ]] \\ [[packet:xrouter:docs:MAN1#FEC| FEC(1) -- Forward Error Correction. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CHANNEL ===== CHANNEL(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** CHANNEL -- Channel to Use on Interface. **SYNOPSIS** CHANNEL= **DESCRIPTION** CHANNEL is an optional PORT configuration directive. If present, it specifies the "channel" to use on a multi- channel interface. It is required only on certain types of interface, e.g. KISS. Not required on AXIP, AXUDP, or AXTCP interfaces. **OPTIONS** The argument to CHANNEL is a letter between A and P inclusive. The default is channel A. **EXAMPLE** CHANNEL=C ; 3rd channel **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#IFACES| IFACES(6) -- Interfaces in XRouter.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CHATALIAS ===== CHATALIAS(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** CHATALIAS -- Alias for Chat Server. **SYNOPSIS** CHATALIAS= **DESCRIPTION** CHATALIAS is a directive that can be used in XROUTER.CFG, both "globally" and within PORT definition blocks. It specifies an "alias", i.e. a sort of memorable alternative "callsign" for the chat server, e.g. "IOWCHT" (Isle of Wight Chat). This can be used interchangeably with the CHATCALL; i.e. the chat server will respond to either. The is a string of up to 6 uppercase ASCII characters and numbers. It is suggested that it should end with "CHT", and begin with something geographically relevant, e.g. BHMCHT for Birmingham, LDSCHT for Leeds etc., so it can be easily identified in node tables. If used "globally", it specifies the "primary" chat alias, used for AX25, NetRom and TCP operations. This is also the chat server's "identity", as displayed on chat messages. Any PORTs declared further down XROUTER.CFG "inherit" this alias for AX25 Layer 2 chat server operation on that port, UNLESS overridden by the use of CHATALIAS within that PORT's definition block. If CHATALIAS is used within a PORT definition block, it replaces the "global" chat alias for that port only. **EXAMPLE** CHATALIAS=IOWCHT **CAVEATS** Omitting the global CHATALIAS, or setting it IDENTICAL to NODEALIAS disables chat server connectivity, but the server can still be used "standalone" via the CHAT command. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#CHAT| CHAT(1) -- Start Chat Session.]] \\ [[packet:xrouter:docs:MAN9#CHAT-SRV| CHAT-SRV(9) -- Chat Server.]] \\ [[packet:xrouter:docs:MAN7#CHATCALL| CHATCALL(7) -- Chat Server Callsign.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CHATCALL ===== CHATCALL(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** CHATCALL -- Callsign for Chat Server. **SYNOPSIS** CHATCALL= **DESCRIPTION** CHATCALL is a directive that can be used in XROUTER.CFG, both "globally" and within PORT definition blocks. It specifies the AX25/NetRom callsign for the chat server. This can be used interchangeably with the CHATALIAS; i.e. the chat server will respond to either. If used "globally", it specifies the "primary" chat callsign, used for AX25 and NetRom operations. This can be the same as NODECALL, but must use a different SSID. A SSID of -8 is the de-facto standard for XRchat systems. Any PORTs declared further down XROUTER.CFG "inherit" this callsign for AX25 Layer 2 chat server operation on that port, UNLESS overridden by the use of CHATCALL within that PORT's definition block. If CHATCALL is used within a PORT definition block, it replaces the "global" chat callsign for that port only. **EXAMPLE** CHATCALL=G8PZT-8 **CAVEATS** Omitting the global CHATCALL, or setting it IDENTICAL to NODECALL (including the SSID) disables chat server connectivity, but the server can still be used "standalone" via the CHAT command. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#CHAT| CHAT(1) -- Start Chat Session.]] \\ [[packet:xrouter:docs:MAN9#CHAT-SRV| CHAT-SRV(9) -- Chat Server.]] \\ [[packet:xrouter:docs:MAN7#CHATALIAS| CHATALIAS(7) -- Chat Server Alias.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CHATPORT ===== CHATPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** CHATPORT -- TCP Port for CHAT Server. **SYNOPSIS** CHATPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** CHATPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the CHAT server. If not present, the default is 3600. The CHAT server, allows groups of users to hold live multi-way conversations without having to manage several TNC streams at once. The CHAT server is also available as NetRomX service 8, plus via CHATCALL/CHATALIAS and the CHAT command. **OPTIONS** If a single argument is supplied, e.g. "CHATPORT=3600", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "CHATPORT=3600 3601", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting CHATPORT to zero on a stack prevents TCP connections to the chat server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#CHAT-SRV| CHAT-SRV(9) -- CHAT Server. ]] \\ [[packet:xrouter:docs:MAN9#CHAT-SVC| CHAT-SVC(9) -- NetRomX CHAT Service. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== COLS ===== COLS(7) XROUTER REFERENCE MANUAL 19/10/2023 **NAME** COLS -- Set Display Width (deprecated). **SYNOPSIS** COLS=n (n = 40-120) **DESCRIPTION** COLS is an optional configuration directive, used only in the "global" section of XROUTER.CFG. It sets the display width in columns or characters of text. The default display width for XRouter is 80 columns, which is a legacy from the 80x25 DOS days. With XR32 running in a Windows "command" window, this setting allows the use of retro "full screen" mode, using the ALT-RETURN key combination. As XRouter, like most packet systems, is intended for a display width of 80 columns, all its responses are designed to fit within that width. The only thing that might exceed 80 columns is monitored traffic, which simply wraps. So increasing the display width merely reduces the amount of wrapping on monitored data, whilst reducing the width may cause wrapping and corruption of displays such as the status bar, nodes tables, table headings and so on. Whereas Windows resizes the containing window to fit the dimensions specified by XRouter, Linux does not. On Linux, the width of the containing terminal window must be equal to of greater than COLS, otherwise the display is corrupted *** Therefore the use of COLS is strongly deprecated *** If you really *must* fiddle, use the COLS directive near the start of XROUTER.CFG, before any CONSOLE definitions. As an example, for a 90-column display use COLS=90. **CAVEATS** If you set COLS less than 80, the bottom menu bar will be corrupt or blank. If you set it less than 79, fields on the Route monitor window will wrap. If you set it less than 76, the top status bar disappears. If you set it less than 30, XRouter will segfault when you exit. If you set COLS more than 80, you cannot use "full screen" mode on Windows. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#ROWS| ROWS(7) -- Set Display Height. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CONSOLELANG ===== CONSOLELANG(7) XROUTER REFERENCE MANUAL 29/10/2023 **NAME** CONSOLELANG -- Default Language. **SYNOPSIS** CONSOLELANG= **DESCRIPTION** CONSOLELANG is an optional directive used in XROUTER.CFG. It can be used globally, and/or in each CONSOLE definition block. If present, it specifies the default language for console operations. If not present, the console inherits DEFAULTLANG. The language for any session can changed at any time using the LANG command. If the relevant language file is not present, it has no effect is as follows: 0 - English 1 - French 2 - Spanish 3 - German 4 - Dutch You may set each CONSOLE to a different language if you wish, but please be aware that the language of the FIRST console is the one that is used for all the other windows (chat, nodes, routes...) and their help menus etc.. **EXAMPLE** CONSOLELANG=2 -- Sets console language to SPANISH **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CONSOLES| CONSOLES(6) -- About XRouter Consoles. ]] \\ [[packet:xrouter:docs:MAN7#DEFAULTLANG| DEFAULTLANG(7) -- Default language ]] \\ [[packet:xrouter:docs:MAN8#LANGS.SYS| LANGS.SYS(8) -- Language selection file ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CONTACT ===== CONTACT(7) XROUTER REFERENCE MANUAL 20/9/2023 **NAME** CONTACT -- Sysop's contact details. **SYNOPSIS** CONTACT= **DESCRIPTION** CONTACT is an optional directive, used in XROUTER.CFG. If present, it specifies an email or packet address, phone number, or web site etc, to be sent to the mapping server. Although not currently displayed on the map, this data may eventually be used to allow sysops to contact each other, or for the map server owner to contact you in the event of problem. Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's association between callsigns and IP addresses. The mapping server displays nodes and links on a MAP. CONTACT may be used (once only) anywhere in the "global" section of XROUTER.CFG. **EXAMPLES** CONTACT=g9dum@wmpkt.org CONTACT=www.wmpkt.org/contacts CONTACT=PO Box 43, Dudley,West Midlands **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MAPCOMMENT| MAPCOMMENT(7) -- Short text to display on map.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CTEXT ===== CTEXT(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** CTEXT -- Set "Connect Text". **SYNOPSIS** CTEXT *** CTEXT= **DESCRIPTION** The CTEXT directive, used in XROUTER.CFG, specifies a "connect text", which is a single or multi-line text that can be sent to a caller when they connect to XRouter. The directive has two possible forms, one for specifying the "global" CTEXT, the other for specifying a port-specific one. The companion directive CTFLAGS controls which callers receive the text. If a port-specific CTEXT exists, it overrides the global CTEXT, on that port only. The GLOBAL connect text is specified in a multi-line block which starts with CTEXT and ends with a line containing only "***", like this: CTEXT This is the first line if the connection text This is the second line And so on *** A PORT connection text is specified *differently*. The following form is used within a PORT definition block: CTEXT=Single line of text, or a filename Upon bootup, if a port CTEXT is not specified, XRouter looks for the file CTEXTn.SYS, whcre n is the port number. If the file is found, its contents are loaded. Otherwise the global ctext (if any) is inherited by the port. In PORT blocks only, if specifies a filename, the contents of that file are read "live" every time someone connects, which may be of use in EMCOMM scenarios. The specified file could for instance be updated by another program, such as an extreme weather detector. If the filename starts with the 5 characters "CTEXT", e.g. "ctext-news", that file will be read from the current directory. If it is a fully qualified path starting with "." or "/", there are no restrictions on where the file resides, so long as XRouter is allowed to access it. For example, using the CTEXT command: CTEXT ctext-news.txt CTEXT /etc/weather/latest.txt The CTEXT *command* allows the texts to be changed "on the fly". **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#CTEXT| CTEXT(1) -- Display / Set Connection Text. ]] \\ [[packet:xrouter:docs:MAN1#CTFLAGS| CTFLAGS(1) -- Display / Set Connection Text Flags ]] \\ [[packet:xrouter:docs:MAN7#CTFLAGS| CTFLAGS(7) -- Connection Text Control Flags. ]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CTFLAGS ===== CTFLAGS(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** CTFLAGS -- Connection Text Control Flags. **SYNOPSIS** CTFLAGS=n (where n is 0-15) **DESCRIPTION** The CTFLAGS directive, used in XROUTER.CFG, controls which callers are sent a "connect text" when they connect to XRouter. If CTFLAGS is used in the GLOBAL section of XROUTER.CFG, its value is "inherited" by any PORTs that are subsequently defined. If used within a PORT block, the value overrides the global value, for that port only. The argument is the sum of the desired options from the following list (only options 1 and 2 are valid in a PORT): 1 - Send CTEXT upon connection to NODEALIAS / PORTALIAS. 2 - Send CTEXT upon connection to NODECALL / PORTCALL. 4 - Send CTEXT to NetRom L4 callers. 8 - Sent CTEXT to TELNET caller. The default value is 9 (Alias and Telnet only). **NOTE** The CTFLAGS *command* allows the texts to be changed "on the fly". **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#CTEXT| CTEXT(1) -- Display / Set "Connect Text" ]] \\ [[packet:xrouter:docs:MAN7#CTEXT| CTEXT(7) -- Connect Text configuration directive ]] \\ [[packet:xrouter:docs:MAN1#CTFLAGS| CTFLAGS(1) -- Display / set Ctext control flags ]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== CWID ===== CWID(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** CWID -- Morse Code Identification. **SYNOPSIS** CWID= **DESCRIPTION** CWID is an optional PORT configuration directive, which is valid only for SCC ports at present. It specifies a callsign to be sent every 30 minutes using Morse code. If omitted, no cwid is sent. **OPTIONS** The consists of up to 8 characters. Only upper case alphanumeric characters and forward slash (/) are acceptable. **EXAMPLES** CWID=GB7PZT CWID=G8PZT/M **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DEFAULTLANG ===== DEFAULTLANG(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** DEFAULTLANG -- Default Language. **SYNOPSIS** DEFAULTLANG= **DESCRIPTION** DEFAULTLANG is an optional directive used in XROUTER.CFG. If present, it specifies the default language for all sessions that are NOT assigned a language by entries in LANGS.SYS. If DEFAULTLANG is not present, the default language is English. The setting is inherited by all CONSOLES, but it can be overridden by CONSOLELANG, either globally or in each CONSOLE definition block. The language for any session can changed at any time using the LANG command. If the relevant language file is not present, it has no effect is as follows: 0 - English 1 - French 2 - Spanish 3 - German 4 - Dutch **EXAMPLE** DEFAULTLANG=1 -- Sets default language to FRENCH **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#CONSOLELANG| CONSOLELANG(7) -- Console language ]] \\ [[packet:xrouter:docs:MAN8#LANGS.SYS| LANGS.SYS(8) -- Language selection file ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DHCP ===== DHCP(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** DHCP -- Obtain Port IP Using DHCP. **SYNOPSIS** DHCP=n (where n is 0 or 1) **DESCRIPTION** DHCP is an optional PORT configuration directive. If present, it specifies whether or not the port IP address should be obtained dynamically using DHCP (DHCP=1) or specified statically (DHCP=0). The default is 0. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#DHCP| DHCP(1) -- Display DHCP-obtained IP configuration.]] \\ [[packet:xrouter:docs:MAN9#DHCP| DHCP(9) -- Dynamic Host Configuration Protocol.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DIGIFLAG ===== DIGIFLAG(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** DIGIFLAG -- Digipeating Options. **SYNOPSIS** DIGIFLAG=n (where n is a number from 0 to 1023) **DESCRIPTION** DIGIFLAG is an optional PORT configuraton directive which controls digipeating on that port. (0=none, default=7). **OPTIONS** Options are enabled by adding together the following numbers: Value Option --------------------------------------------------- 1 Digipeat UI frames 2 Digipeat non-UI frames 4 Enable RELAY generic digipeating (deprecated). 8 Enable TRACE generic digipeating (deprecated). 16 Enable WIDE generic digipeating (deprecated). 32 Allow APRS 3rd party digi via L4. 64 Allow digipeating to Internet (IGate). 128 Allow digipeating from Internet (IGate). 256 Enable UITRACE digipeating (e.g. WIDEn-n) 512 Enable UIFLOOD digipeating (e.g. GBRn-n) **EXAMPLE** DIGIFLAG=5 ; Digipeat UI + RELAY generic. **NOTES** UITRACE and UIFLOOD are two special addresses that are suffixed with pseudo-SSID's, e.g. "TRACE4-4" and "WIDE2-2". These addresses can digipeat several times. The first digit specifies the maximum number of hops, and the second is the hop counter, which is decremented each time the frame is digipeated. These two addresses behave slightly differently however. When a frame is digipeated on the address specified by UITRACE, each digipeater inserts its own callsign in the digipeater list and decrements the "SSID". Frames digipeated on the UIFLOOD address have their SSIDs decremented, but the digi doesn't insert its own callsign. For the sake of consistency with UI-View, UITRACE defaults to "TRACE", giving TRACEn-n digipeating, and UIFLOOD defaults to WIDE, giving WIDEn-n digipeating. However, according to the APRS "New Paradigm", RELAY, TRACE and WIDE are deprecated, UITRACE should be set to "WIDE", and UIFLOOD should be set to a "state" code (e.g. "GBR" for the UK). These addressses may be specified in XROUTER.CFG. One of the main justifications for the new paradigm was the fact that some of the older digipeaters would repeat the same packets over and over. This does not happen with XRouter, due to its duplicate prevention measures. Not everyone agrees with the "New Paradigm, so the choice of which features to enable is left you you. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#DIGIFLAG| DIGIFLAG(1) -- Display / Set digipeat options.]] \\ [[packet:xrouter:docs:MAN7#DIGIPORT| DIGIPORT(7) -- Destination Port for Digipeating.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DIGIPORT ===== DIGIPORT(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** DIGIPORT -- Destination Port for Digipeated Frames. **SYNOPSIS** DIGIPORT= **DESCRIPTION** DIGIPORT is an optional directive used in PORT configuration blocks within XROUTER.CFG. It specifies the port number on which digipeated frames are transmitted. The default is 0, i.e. the current port. **EXAMPLE** DIGIPORT=3 ; Digipeat from this port onto port 3 **LIMITATIONS** Frames may be digipeated to ONE port only, therefore it is not possible for a BBS on one port to broadcast unproto headers to several ports at once using DIGIPORT. However, it is possible using BCAST. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#BCAST| BCAST(9) -- One to many digipeating]] \\ [[packet:xrouter:docs:MAN1#DIGIPORT| DIGIPORT(1) -- Display / Set port to digipeat on.]] \\ [[packet:xrouter:docs:MAN7#DIGIFLAG| DIGIFLAG(7) -- Digipeating Options.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DISCARDPORT ===== DISCARDPORT(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** DISCARDPORT -- TCP Port for DISCARD Server. **SYNPOSIS** DISCARDPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** DISCARDPORT is an optional GLOBAL configuration directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number for the DISCARD server. If not present, the default is 9. The DISCARD server is a "sink" session, whereby XRouter ignores (discards) everything sent to it. This is a useful tool for testing connections, throughput etc. **OPTIONS** If a single argument is supplied, e.g. "DISCARDPORT=99", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "DISCARDPORT=99 9999", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting DISCARDPORT to zero on a stack prevents TCP connections to the server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#DISC-SRV| DISC-SRV(9) -- Discard Server. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DXFLAGS ===== DXFLAGS(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** DXFLAGS -- DX List Control Flags. **SYNOPSIS** DXFLAGS=n (where n is a decimal number) **DESCRIPTION** The DXFLAGS directive is used in XROUTER.CFG to control the DX list. The flags are made up as follows: 1 - Record digipeated stations (defaults off). 2 - Enable logging of DX exceeding specified distance. 4 - Log frame contents of qualifying DX If logging is enabled Bits 3 - 14 specify the minimum distance which will be logged, from 4Km to 32764Km in 8Km steps, e.g. DXFLAGS=502 enables DX logging, with a threshold of 500Km. If logging is not enabled, bits 3-14 are ignored. If DX logging is enabled, any received APRS positions which exceed the threshold distance are logged to LOG/DXLOG.TXT. XRouter's position is defined in XROUTER.CFG, either by using LOCATOR (which gives a coarse position), or using LATITUDE LONGITUDE, or by including an APRS position string in the IDTEXT, for example: IDTEXT !5224.00N/00215.00W Kidderminster Router (KIDDER) *** **CAVEATS** If XRouter's position has not been defined, the program will not start. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#DX| DX(1) -- Show Distant Stations ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== DYNDNS ===== DYNDNS(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** DYNDNS -- Enable / Disable Dynamic DNS Update Client. **SYNOPSIS** DYNDNS=<0|1> **DESCRIPTION** DYNDNS is an optional PORT configuration directive, used in XROUTER.CFG. It specifies whether or not the dynamic DNS update client is active on that port (1=active 0=not active). This is a relic from XR16 (DOS XRouter), when almost no-one had domestic Internet routers. It may be of little use now most home routerc havetheir own dynamic DNS client. **CAVEATS** This directive most only be used on ONE port. It may crash XRouter if you try to use it on more than one. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#DYNDNS| DYNDNS(9) -- Dynamic DNS Update Client]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== ECHOPORT ===== ECHOPORT(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** ECHOPORT -- TCP Port for ECHO Server. **SYNOPSIS** ECHOPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** ECHOPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the ECHO server. If not present, the default is 7. **OPTIONS** If a single argument is supplied, e.g. "ECHOPORT=7777", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "ECHOPORT=7777 8888", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting ECHOPORT to zero on a stack prevents TCP connections to the server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN1#ECHO| ECHO(1) -- Start an Echo session. ]] \\ [[packet:xrouter:docs:MAN9#ECHO-SRV| ECHO-SRV(9) -- Echo server. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== EXCLUDE ===== EXCLUDE(7) XROUTER REFERENCE MANUAL 24/9/2023 **COMMAND** EXCLUDE -- AX25 Blacklist. **SYNOPSIS** EXCLUDE=[,...] **DESCRIPTION** EXCLUDE is an optional directive used in XROUTER.CFG. It specifies a list of one or more callsigns from whom AX25 frames are ignored, and is this the opposite of VALIDCALLS. . It would typically be used on a user-access port to prevent connections from trouble-makers, pirates or other nodes, e.g. for preventing CB nodes from interconnecting with ham radio nodes and vice versa. If used within the "global" section of XROUTER.CFG, the exclusion is "inherited" by any PORTs subsequently defined. If used within a PORT definition block, the exclusion applies to that port only. Multiple callsigns must be separated by commas, and the list must not include any spaces. Exclusions can be changed during run-time using the EXCLUDE command. **EXAMPLE** EXCLUDE=NOCALL,P1RAT ; Ignore these users **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#EXCLUDE| EXCLUDE(1) -- AX25 L2 exclusion command ]] \\ [[packet:xrouter:docs:MAN7#L3EXCLUDE| L3EXCLUDE(7) -- NetRom Layer 3 exclusions ]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter. ]] \\ [[packet:xrouter:docs:MAN7#VALIDCALLS| VALIDCALLS(7) -- AX25 Whitelist. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FEC ===== FEC(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** FEC -- Enable / disable Forward Error Correction. **SYNOPSIS** FEC=<0|1> **DESCRIPTION** FEC is an optional PORT configuration directive, used in XROUTER.CFG. It controls whether or not Reed-Solomon Forward Error Correction is enabled on that port. In order to make use of FEC, the port needs to be using a KISS TNC with the CRC check disabled (PASSALL ON), an SCC card or YAM modem. The default is 0, i.e. disabled. Forward error correction is useful on links with high BER (bit-error-rates). Up to 8 erroneous bytes per frame may be automatically corrected, at the expense slightly larger frames. FEC is not required on links with very low BER. FEC is normally disabled by default, and is enabled by including the FEC=1 directive in the appropriate PORT configuration block in XROUTER.CFG. It can then be turned on and off at will from the command line. If FEC is used, the "allow L2 fragmentation" bit must be set in the port CFLAGS, to allow XRouter to fragment large L3 frames which might otherwise exceed the reduced L2 Paclen. **CAVEATS** Frames containing FEC look like garbage to "normal" AX25 systems. Thus in order to use FEC on a link, BOTH ends of the link must be FEC-capable. Future versions may allow one way FEC. Stations who are not running FEC may interpret FEC-encoded frames incorrectly, leading either to a failure to decode or possibly to corrupt node broadcasts or inaccurate APRS positioning. Therefore FEC should not be used on a shared channel. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#FEC| FEC(1) -- Control Forward Error Correction.]] \\ [[packet:xrouter:docs:MAN7#CFLAGS| CFLAGS(7) -- Connection Control Flags.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FINGERPORT ===== FINGERPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** FINGERPORT -- TCP Port for FINGER Server. **SYNOPSIS** FINGERPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** FINGERPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the FINGER server. If not present, the default is 79. The FINGER server allows users to "put a finger on" (i.e. find information about) other users. The server is also available on NetRomX service 79. **OPTIONS** If a single argument is supplied, e.g. "FINGERPORT=79", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "FINGERPORT=79 89", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting FINGERPORT to zero on a stack prevents TCP connections to the finger server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. FINGER is expected to be on port 79. If you "move" the finger port, other people's finger clients will not be able to connect to your server. This directive is provided ONLY for controlling availablity on each stack. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#FING-SRV| FING-SRV(9) -- FINGER server. ]] \\ [[packet:xrouter:docs:MAN9#FING-SVC| FING-SVC(9) -- NetRomX FINGER Service. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FRACK ===== FRACK(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** FRACK -- AX25 Frame Acknowledgement Time. **SYNOPSIS** FRACK= **DESCRIPTION** FRACK is an optional PORT configuration directive, used in XROUTER.CFG. If present, it specified the AX25 "T1" timeout, i.e. FRame ACKnowledgement time in milliseconds. If not present, the default FRACK is 7000. The value can be changed during run- time using the FRACK command. After sending an AX25 packet, FRACK is the amount of time XRouter will wait for an "ack" before considering the packet to be lost. The T1 timer starts when the link layer dispatches the packet to the MAC (Media Access Control) layer, so you must allow at least enough time for (MAXFRAME * PACLEN) packets to be sent, plus an ack packet to be received, plus the other end's RESPTIME, plus both end's TXDELAYs, plus a generous allowance for channel congestion. A frack no less than 7000 millisecs is recommended for average 1200 baud simplex RF links. Setting this figure too low is antisocial, achieves nothing, wastes airtime, and could result in the link retrying out. However, on fast, wired (e.g. AXUDP) links, 7 secs is excessive, and a figure more like 2000 (2 secs) should be used. **EXAMPLE** FRACK=7000 ; 7 seconds **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#FRACK| FRACK(1) -- Display / Set FRACK for a port.]] \\ [[packet:xrouter:docs:MAN7#MAXFRAME| MAXFRAME(7) -- Maximum Unacked Frames.]] \\ [[packet:xrouter:docs:MAN7#PACLEN| PACLEN(7) -- Maximum Packet Length.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#RESPTIME| RESPTIME(7) -- AX25 Delayed Ack Time.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FREQUENCY ===== FREQUENCY(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** FREQUENCY -- Radio frequency used by RF port. **SYNOPSIS** FREQUENCY= **DESCRIPTION** FREQUENCY is an optional directive that may be used anywhere in a PORT block within XROUTER.CFG. If present, it specifies the radio frequency in Hz. If the port is a radio port, this value is reported to the node mapping server, if reporting is enabled. There are some port types (e.g. AXUDP) where this directive is meaningless. In a RADIO control block, this specifies the transmit and receive frequency if simplex, or the receive frequency if duplex. **EXAMPLE** FREQUENCY=144925000 -- 144.925 MHz **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#RADIO| RADIO(7) -- Rig control block]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FTPPORT ===== FTPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** FTPPORT -- TCP Port for FTP Server. **SYNOPSIS** FTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** FTPPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the FTP server. If not present, the default is 21. The FTP server is mainly intended for use by sysops. **OPTIONS** If a single argument is supplied, e.g. "FTPPORT=21", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "FTPPORT=21 31", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting FTPPORT to zero on a stack prevents TCP connections to the server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#FTP-SRV| FTP-SRV(9) -- FTP server. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== FULLDUP ===== FULLDUP(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** FULLDUP -- Full Duplex. **SYNOPSIS** FULLDUP=<0|1> **DESCRIPTION** FULLDUP is an optional PORT directive, used in XROUTER.CFG. If FULLDUP=1, it allows simultaneous TX/RX, the DCD is ignored and the hardware will transmit whenever it has anything to send, without waiting for the other end to stop. The default is 0 (simplex / half duplex). Used only by hardware which is capable of simultaneous transmission and reception, such as full duplex radio or wire links, KISS TNCs, SCC cards, and YAM modems.. **EXAMPLE** FULLDUP=1 ; Full duplex **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#FULLDUP| FULLDUP(1) -- Display / Set full duplex mode.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== HAAT ===== HAAT(7) XROUTER REFERENCE MANUAL 20/9/2023 **NAME** HAAT -- Antenna Height Above Average Terrain. **SYNOPSIS** HAAT= **DESCRIPTION** HAAT is an optional directive that may be used anywhere in the "global" section of XROUTER.CFG. If present, it specifies the height of the antenna in metres above "average terrain". This is a value widely used in APRS to estimate the radio range. The value is obtained by calculating the average terrain heights along a series of typically 10 or 20 "radials" from the site, then averaging those values. If there are surrounding hills, it is not uncommon for the HAAT to be negative. There is a calculator on the FCC website that allows you to easily calculate your HAAT. At present the HAAT is only displayed on the HTML "info" page, but it might eventually be sent to the mapping server. **EXAMPLES** HAAT=-15 -- Antenna is 15 metres BELOW averaged terrain. HAAT=12 -- Antenna is 12 metres ABOVE avareaged terrain. **NOTE** Although HAAT is currently a "global" parameter, it is acknowledged that some PORTS may have antennas at different heights. Therefore a per-port override will be added in a future version. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#ALTITUDE| ALTITUDE(7) -- Base height of site.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== HTTPPORT ===== HTTPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** HTTPPORT -- TCP Port for HTTP Server. **SYNOPSIS** HTTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** HTTPPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the HTTP server. If not present, the default is 80. The HTTP server serves HTML files and provides a browser- -based user/sysop interface to XRouter. The server is also available via NetRomX service 80. **OPTIONS** If a single argument is supplied, e.g. "HTTPPORT=80", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "HTTPPORT=80 8080", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting HTTPPORT to zero on a stack prevents TCP connections to the HTTP server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#HTTP-SRV| HTTP-SRV(9) -- HTTP server. ]] \\ [[packet:xrouter:docs:MAN9#HTTP-SVC| HTTP-SVC(9) -- NetRomX HTTP Service. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== ID ===== ID(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** ID -- Text to Identify Port. **SYNOPSIS** ID= **DESCRIPTION** ID is a *mandatory* PORT directive used in XROUTER.CFG. It specifies a text to identify the port on the "PORTS" display. It may contain spaces. Please make it informative. **EXAMPLE** ID=144.825 MHz 9k6 TCP/IP users **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== IDINTERVAL ===== IDINTERVAL(7) XROUTER REFERENCE MANUAL 22/10/2023 **NAME** IDINTERVAL -- Identification Beacon Interval. **SYNOPSIS** IDINTERVAL= **DESCRIPTION** IDINTERVAL is an optional GLOBAL configuration directive used in XROUTER.CFG. If present, it specifies the interval in minutes between broadcasts of IDTEXT (the ID beacon) on each port. The default is 15 (minutes). A setting of 0 disables ID beacons. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#IDPATH| IDPATH(7) -- Identification Beacon Path]] \\ [[packet:xrouter:docs:MAN7#IDTEXT| IDTEXT(7) -- Identification Beacon Text.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== IDPATH ===== IDPATH(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** IDPATH -- Destination and Digipeater Path for ID beacons. **SYNOPSIS** IDPATH=[,digipeater,digipeater...] **DESCRIPTION** IDPATH is an optional PORT configuraton directive, used in XROUTER.CFG. If present, it specifies the AX25 destination and optional digipeater path for routine "ID" (identification) beacons. The default AX25 destination and path is "ID" with no digipeaters. You may wish to modify this, for example on APRS ports, to digipeat your beacon. The part can be changed during run-time using the IDPATH command. **EXAMPLE** IDPATH=APRS,RELAY,WIDE **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#IDINTERVAL| IDINTERVAL(7) -- Identification Beacon Interval]] \\ [[packet:xrouter:docs:MAN1#IDPATH| IDPATH(1) -- Display / Set ID Path]] \\ [[packet:xrouter:docs:MAN7#IDTEXT| IDTEXT(7) -- Identification Beacon]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== IDTEXT ===== IDTEXT(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** IDTEXT -- Identification Text. **SYNOPSIS** IDTEXT } } "global" idtext *** } IDTEXT= <-- "port" idtext **DESCRIPTION** IDTEXT is a configuration directive that can be used both "globally" and within PORT definition blocks in XROUTER.CFG. It specifies a single line of text to be broadcast via AX25 every IDINTERVAL, to a destination path specified by IDPATH. If used within the "global" section of XROUTER.CFG, the value is "inherited" by any PORTs defined further down, UNLESS there is an IDTEXT in that PORT block. If used in a PORT block, IDTEXT overrides the "global" value, on that port only. The is specified differently for the global and port cases. In the global case, IDTEXT begins a 3 line block, with on the second line and "***" on the third line, which is a BPQ legacy. In a PORT block, is specified using a single line. Only one line of text (248 characters max.) may be specified. The text may be changed during run-time using the IDTEXT command. **NOTE** If the global includes and APRS-format static position code, starting within the first 40 characters, XRouter will be visible on APRS maps and the MHeard function will record distances to heard stations, if they are broadcasting their positions. The position code format is "!ddmm.mmN/dddmm.mmE" where dd represents degrees of latitude or longitude and mm.mm represents minutes to two decimal places. "N" and "E" may be replaced by "S" and "W" as appropriate. It is highly recommended that you include your position, **EXAMPLE** IDTEXT=!5224.00N/00215.00W# (Kidder) **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#IDINTERVAL| IDINTERVAL(7) -- Identification Beacon Interval]] \\ [[packet:xrouter:docs:MAN7#IDPATH| IDPATH(7) -- Identification Beacon Path]] \\ [[packet:xrouter:docs:MAN1#IDTEXT| IDTEXT(1) -- Display / Set Identification Beacon]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== INITSTR ===== INITSTR(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** INITSTR -- Modem Initialisation String. **SYNOPSIS** INITSTR= **DESCRIPTION** INITSTR is an optional PORT configuration directive used in XROUTER.CFG. It specifies a "modem initialisation string", which is a string of characters sent to the modem when Xrouter is started (modem ports only). **EXAMPLE** INITSTR=ATM0 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== INTERFACENUM ===== INTERFACENUM(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** INTERFACENUM -- Interface Number. **SYNOPSIS** INTERFACENUM= **DESCRIPTION** INTERFACENUM is a *mandatory* PORT configuration directive, used in XROUTER.CFG. It specifies the number of the INTERFACE that the port is bound (attached) to. **EXAMPLE** PORT=7 INTERFACENUM=5 ; Port is attached to interface 5 MTU=256 ENDPORT **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#IFACES| IFACES(6) -- Interfaces in XRouter.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== INTERLOCK ===== INTERLOCK(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** INTERLOCK -- Transmitter Interlock. **SYNOPSIS** INTERLOCK= **DESCRIPTION** INTERLOCK is an optional PORT configuration directive, used in XROUTER.CFG. If a non-zero INTERLOCK value is specified, no two ports with the same interlock number will transmit at the same time. Note that this is not necessarily a port number (although it could be), it is just a number that is common to a group of ports that are not allowed to transmit at the same time, for example because they all share one power supply. If not specified, the default is 0. Used only by SCC cards, because KISS TNC's make their own decisions about when to transmit, and XRouter has no control over that process. **EXAMPLE** INTERLOCK=4 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== IPADDRESS ===== IPADDRESS(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** IPADDRESS -- Main or Port IP Address. **SYNOPSIS** IPADDRESS= **DESCRIPTION** IPADDRESS is a directive used in XROUTER.CFG. It can be used both "globally" and within a PORT configuration block. If used in the "global" section, it specifies the "core" IP address, inherited by all ports. If used within a PORT definition block, it specifies an additional IP address that is used instead of the global IP address for all TCP/IP operations on that port. The "core" IP address is used as the "inner" address for tunneled IP, e.g. for IPIP, IPENCAP, IPUDP etc. If you have an AMPRNET address, it is therefore important that you use that as the CORE address, and use your private LAN address in the approriate PORT block. It doesn't have to be amprnet of course - you may wish to establish a private network on another address range. **EXAMPLE** IPADDRESS=44.131.91.5 **CAVEATS** If you set the global IPADDRESS to 0.0.0.0 or leave it undefined, *all* IP activity is disabled, including AXUDP, AXTCP, AXIP, HTTP, FTP etc on BOTH stacks! This is a deliberate security feature (it may be changed in future). Therefore at present, if you don't have an amprnet address, and you want to use any IP services, it is suggested that you set a non-zero dummy IP address such as 10.1.1.1 for the core. A common mistake is to use a LAN address for the core IP, and amprnet addresses for AXUDP operations. This is very bad practice, because it forces the packets to traverse the IP stack several times, which is not only ineffficient, but can lead to death-loops. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#IP-STACKS| IP-STACKS(6) -- IP Stacks in XRouter.]] \\ [[packet:xrouter:docs:MAN9#IP-PRIMER| IP-PRIMER(9) -- IP Primer.]] \\ [[packet:xrouter:docs:MAN7#NETMASK| NETMASK(7) -- Port Subnet Mask.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== IPLINK ===== IPLINK(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** IPLINK -- Peer Address of a Link. **SYNOPSIS** IPLINK= **DESCRIPTION** IPLINK is a PORT configuration directive used in XROUTER.CFG, which is mandatory for AXIP and AXUDP ports. for other types of port it has no meaning, and is ignored. IPLINK specifies the IP address or hostname of an AXIP or AXUDP link partner. If the partner has a static IP address, it is more efficient to specify the IP address here, otherwise it may be necessary to use the hostname. A special case, "IPLINK=0.0.0.0" allows the PORT to be used in "Multiple-Links-Per-Port" mode, whereby one PORT supports several links. In this mode, formal links are specified using PEER commands, instead of the usual IPLINK/UDPREMOTE. The IPLINK address can be changed during run-time using the IPLINK *command*, but a run-time change to or from "0.0.0.0" is not allowed. **EXAMPLES** IPLINK=62.51.67.21 IPLINK=gb7pzt.dyndns.org **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AXIP| AXIP(9) -- AX25-over-IP Tunnelling.]] \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25-over-UDP Tunnelling.]] \\ [[packet:xrouter:docs:MAN1#IPLINK| IPLINK(1) -- Display / Set Port IPLINK Address.]] \\ [[packet:xrouter:docs:MAN7#PEER| PEER(7) -- Specify AXIP / AXUDP Link Partner]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== KEEPALIVE ===== KEEPALIVE(7) XROUTER REFERENCE MANUAL 22/3/2024 **NAME** KEEPALIVE -- AXUDP / AXIP Keepalive interval. **SYNOPSIS** KEEPALIVE= **DESCRIPTION** KEEPALIVE is an optional PORT configuration directive used in XROUTER.CFG. It is only used by AXIP and AXUDP ports, and is ignored for other types of port. If present, KEEPALIVE specifies the interval in seconds between the sending of "keep alive" packets to the link partner. The purpose of keepalive packets is to maintain dynamic NAT entries in intermediate routers (including CGNAT), when traffic is light. They are not required when static NAT (aka "port forwarding") is used, provided the ISP doesn't use CGNAT. If KEEPALIVE is not specified, or is zero, no keep alive packets are sent. **EXAMPLE** KEEPALIVE=120 ; 2 minutes between keepalives **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AXIP| AXIP(9) -- AX25-over-IP Tunnelling.]] \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25-over-UDP Tunnelling.]] \\ [[packet:xrouter:docs:MAN1#KEEPALIVE| KEEPALIVE(1) -- Display / Change Keepalive Interval.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== L3EXCLUDE ===== L3EXCLUDE(7) XROUTER REFERENCE MANUAL 4/9/2023 **NAME** L3EXCLUDE -- Level 3 Exclusion List. **SYNOPSIS** L3EXCLUDE=callsign[,callsign,callsign...] **DESCRIPTION** L3EXCLUDE is an optional global XROUTER.CFG directive. If present, it specifies a list of callsigns from whom NetRom level 3 traffic is blocked or restricted. The callsigns to be blocked are the "user" part of the L3 "user@node" source address. In combination with BLEVEL, this can be used to control troublesome users. It should only be used in exceptional circumstances! Depending on the BLEVEL setting, traffic can be disrupted by randomly dropping packets to cause L4 retries, or blocked altogether. **EXAMPLE** L3EXCLUDE=N3UOO-5,G9ABC **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#BLEVEL| BLEVEL(1) -- L3 Budlist de-rate level command. ]] \\ [[packet:xrouter:docs:MAN1#EXCLUDE| EXCLUDE(1) -- AX25 L2 exclusion command ]] \\ [[packet:xrouter:docs:MAN7#BLEVEL| BLEVEL(7) -- L3 Budlist de-rate level directive. ]] \\ [[packet:xrouter:docs:MAN7#EXCLUDE| EXCLUDE(7) -- AX25 L2 exclusion directive. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== L4T3 ===== L4T3(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** L4T3 -- NetRom Layer 4 link check interval. **SYNOPSIS** L4T3= **DESCRIPTION** L4T3 is an optional directive, used in XROUTER.CFG. If present, it specifies the number of seconds between NetRom layer 4 "link check" frames. If not specified, the default is (IDLETIME-60) (usually 840 seconds = 14 minutes). Setting this to 0 disables the link check. The purpose of the link check is to detect "failed" links, i.e. those where one end has switched off or rebooted, or where the routing is no longer viable. Most sessions have an inactivity timeout (IDLETIME), but some, such as chat do not. Without a link check, those sessions would persist forever in the absence of any activity, hogging resources. **EXAMPLE** L4T3=600 -- Set link check interval to 10 minutes **SEE ALSO:** \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== LATITUDE ===== LATITUDE(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** LATITUDE -- Set XRouter's geographic latitude **SYNOPSIS** LATITUDE=n (where n is between -90.0 and 90.0) **DESCRIPTION** LATITUDE is an optional directive, used in XROUTER.CFG. If present, it specifies XRouter's geographic latitude. LATITUDE is not needed if (a) LOCATOR is specified, or (b) a valid APRS position string is present at the start of IDTEXT. In either case, LATITUDE is deduced from the supplied values. However if LATITUDE and LONGITUDE are supplied and LOCATOR isn't, the latter is calculated. XRouter uses position information to calculate distances and directions to other nodes, as displayed in the MHeard and DX lists, and to calculate sunrise and sunset times etc. Whilst not vital, these things make node-hopping more interesting. Therefore XRouter will not run unless some form of position is supplied. Unless disabled by the sysop, position information is also reported to a mapping server, in an attempt to draw a near real-time network map. Positional precision is left to the sysop. There is rarely a need to know EXACTLY where a node is, its approximate location being sufficient for most purposes. Latitude is currently stored with a MAXIMUM precision of a hundredth of a minute, ie around 22 metres, so there is no point trying to supply a LATITUDE of greater precision. Within reason, a false location may be supplied, but if the position is an obvious mismatch for the nodecall, XRouter won't run. **OPTIONS** The argument to LATITUDE is a decimal number of degrees between -90.0 (South Pole) and 90.0 (North Pole). Note that this is DECIMAL DEGREES, not degrees, minutes and seconds. Southern latitudes are specified using NEGATIVE numbers. You should not append N or S after the number. **EXAMPLE** LATITUDE=52.4 -- An imprecise northern latitude LATITUDE=-77.6342 -- A more precise southern latitude **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#IDTEXT| IDTEXT(1) -- Display / Set ID beacon text]] \\ [[packet:xrouter:docs:MAN7#LOCATOR| LOCATOR(7) -- Maidenhead QTH locator]] \\ [[packet:xrouter:docs:MAN7#LONGITUDE| LONGITUDE(7) -- Geographic longitude]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== LEARN ===== LEARN(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** LEARN -- Learn Unsolicited AX*P Peer Details. **SYNOPSIS** LEARN=1 **DESCRIPTION** LEARN is an optional directive that is used only in one type of PORT block within XROUTER.CFG. It enables "learning" of AXIP / AXUDP routing information for unsolicited peers, i.e. those for whom no PEER statement exists. This allows return packets to be routed to the caller for a limited time. If the connection is not used for 10 minutes, the details are purged. As the normal AX25 T3 "link check" interval is 5 minutes, purging only happens after the link has been dead for a while. LEARN is only valid if the PORT has "IPLINK=0.0.0.0" and is attached to an INTERFACE which has "TYPE="AXUDP". Only one such PORT can exist, but it can co-exist with "normal" AXIP and AXUDP ports, i.e. those which have IPLINK that is not "0.0.0.0". **OPTIONS** The argument for LEARN can be either zero or non-zero. The former is the default condition if the directive is not present. Any non-zero argument enables learning. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AD-HOC| AD-HOC(9) -- Ad-Hoc Networking.]] \\ [[packet:xrouter:docs:MAN9#AXIP| AXIP(9) -- AX25 over IP]] \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25 over UDP]] \\ [[packet:xrouter:docs:MAN7#PEER| PEER(7) -- Specify AXIP / AXUDP Link Partner]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== LOCATOR ===== LOCATOR(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** LOCATOR -- Maidenhead QTH locator **SYNOPSIS** LOCATOR=LLddLL[dd] (where L is a letter and d is a digit) **DESCRIPTION** LOCATOR is an optional directive, used in XROUTER.CFG. If present, it specifies XRouter's Maidenhead QTH locator. LOCATOR is not needed if (a) LATITUDE and LONGITUDE are specified, or (b) a valid APRS position string is present at the start of IDTEXT. In either case, LOCATOR is deduced from the supplied values. However if LOCATOR is supplied, but LATITUDE and LONGITUDE are not, the latter are calculated. XRouter uses position information to calculate distances and directions to other nodes, as displayed in the MHeard and DX lists, and to calculate sunrise and sunset times etc. Whilst not vital, these things make node-hopping more interesting. Therefore XRouter will not run unless some form of position is supplied. Unless disabled by the sysop, position information is also reported to a mapping server, in an attempt to draw a near real-time network map. Positional precision is left to the sysop. There is rarely a need to know EXACTLY where a node is, its approximate location being sufficient for most purposes. A 6-character LOCATOR puts the node in the middle of a 1KM square. An 8 character locator defines a square of 15 secs of latitude by 30 secs of longitude. Within reason, a false location may be supplied, but if the position is an obvious mismatch for the nodecall, XRouter won't run. **OPTIONS** The argument to LOCATOR is a 6 or 8 character "Maidenhead" locator, e.g. "IO82VJ" or "IO75GH65" **EXAMPLE** LOCATOR=IO82VJ -- Kidderminster UK **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#IDTEXT| IDTEXT(1) -- Display / Set ID beacon text]] \\ [[packet:xrouter:docs:MAN7#LATITUDE| LATITUDE(7) -- Geographic latitude]] \\ [[packet:xrouter:docs:MAN7#LONGITUDE| LONGITUDE(7) -- Geographic longitude]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== LOG ===== LOG(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** LOG -- Activity logging options **SYNOPSIS** LOG=n (where n is between 0 and 16383) **DESCRIPTION** The optional LOG directive, used in XROUTER.CFG, controls the logging of XRouter activity, such as connections, disconnections, errors, user commands etc. If the directive is omitted, or is set to 0, no logging is done. **OPTIONS** The argument to LOG is a decimal value between 0 and 16383 formed by summing the values of the desired options from the table below: Value Function --------------------------------------------------- 1 Enable logging to disk 2 Use CRLF instead of LF line endings 4 Log session activity 8 Log TCP/UDP events 16 Log Netrom layer 4 events 32 Log IP/ICMP layer events 64 Log Netrom layer 3/inp3 128 Log ODN activity. 256 Log IDS activity to IDS log 512 Generate PCAP file (use with caution) 1024 Log daemon process events 2048 Log AX25 over TCP 4096 Log AX25 connections etc 8192 Log interface layer events **EXAMPLES** LOG=7 -- Log session activity, using CRLF line endings LOG=65 -- Log Netrom L3 only, using LF line endings **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#LOG| LOG(1) -- Activity logging control command]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== LONGITUDE ===== LONGITUDE(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** LONGITUDE -- Set XRouter's geographic longitude **SYNOPSIS** LONGITUDE=n (where n is between -180.0 and 180.0) **DESCRIPTION** LONGITUDE is an optional directive, used in XROUTER.CFG. If present, it specifies XRouter's geographic longitude. LONGITUDE is not needed if (a) LOCATOR is specified, or (b) a valid APRS position string is present at the start of IDTEXT. In either case, LONGITUDE is deduced from the supplied values. However if LATITUDE and LONGITUDE are supplied, and LOCATOR isn't, the latter is calculated. XRouter uses position information to calculate distances and directions to other nodes, as displayed in the MHeard and DX lists, and to calculate sunrise and sunset times etc. Whilst not vital, these things make node-hopping more interesting. Therefore XRouter will not run unless some form of position is supplied. Unless disabled by the sysop, position information is also reported to a mapping server, in an attempt to draw a near real-time network map. Positional precision is left to the sysop. There is rarely a need to know EXACTLY where a node is, its approximate location being sufficient for most purposes. Longitude is currently stored with a MAXIMUM precision of a hundredth of a minute, ie around 22 metres, so there is no point trying to supply a LONGITUDE of greater precision. Within reason, a false location may be supplied, but if the position is an obvious mismatch for the nodecall, XRouter won't run. **OPTIONS** The argument to LONGITUDE is a decimal number of degrees between -180.0 (far West) and 180.0 (far East). Note that this is DECIMAL DEGREES, not degrees, minutes and seconds. Western longitudes are specified using NEGATIVE numbers. You should not append E or W after the number. **EXAMPLE** LONGITUDE=2.5 -- An imprecise eastern longitude LONGITUDE=-5.205 -- A more precise western longitude **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#IDTEXT| IDTEXT(1) -- Display / Set ID beacon text]] \\ [[packet:xrouter:docs:MAN7#LATITUDE| LATITUDE(7) -- Geographic latitude]] \\ [[packet:xrouter:docs:MAN7#LOCATOR| LOCATOR(7) -- Maidenhead QTH locator]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAPCOMMENT ===== MAPCOMMENT(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** MAPCOMMENT -- Short text to display on map. **SYNOPSIS** MAPCOMMENT= **DESCRIPTION** MAPCOMMENT is an optional directive, used in XROUTER.CFG. If present, it specifies a short single line of text which pops up when someone clicks on the node on the network map. The text should be descriptive, but not too long. The maximum length accepted by XRouter is around 244 characters, but it cannot be guaranteed that the mapping server will display a test of that length. MAPCOMMENT can be used, once only, anywhere in the "global" section of XROUTER.CFG. **EXAMPLES** MAPCOMMENT=XRLin (XRouter for x86 Linux) alpha test node MAPCOMMENT=Beacon Hill, Trunking Only **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#CONTACT| CONTACT(7) -- Sysop's contact details.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAPSERVADDR ===== MAPSERVADDR(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** MAPSERVADDR -- Hostname / IP address of mapping server. **SYNOPSIS** MAPSERVADDR= **DESCRIPTION** MAPSERVADDR is an optional directive used in XROUTER.CFG. If present, it specifies an alternative address for the mapping server, overriding the inbuilt one. It is provided only in case the server address changes in future. Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's association between callsigns and IP addresses. The mapping server displays nodes and links on a MAP. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MAPCOMMENT| MAPCOMMENT(7) -- Short text to display on map.]] \\ [[packet:xrouter:docs:MAN7#MAPSERVPORT| MAPSERVPORT(7) -- TCP port of mapping server]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAPSERVPORT ===== MAPSERVPORT(7) XROUTER REFERENCE MANUAL 6/9/2023 **NAME** MAPSERVPORT -- TCP port of mapping server. **SYNOPSIS** MAPSERVPORT=n (where n is between 0 and 65535) **DESCRIPTION** MAPSERVPORT is an optional directive, used in XROUTER.CFG. If present, it specifies an alternative TCP port for the mapping server, overriding the inbuilt value. Note that "mapping" refers to CARTOGRAPHY, *not* to BPQ's association between callsigns and IP addresses. The mapping server displays nodes and links on a MAP. This directive is provided only in case the server details change in future. Setting it to 0 disables map reporting, but we really hope you won't do this - if you are concerned about privacy, please consider using a false location, as close to your real locations as you feel comfortable with. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MAPSERVADDR| MAPSERVADDR(7) -- Address of mapping server]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAXFRAME ===== MAXFRAME(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** MAXFRAME -- Maximum Unacked AX25 Frames. **SYNOPSIS** MAXFRAME=n (where n is in the range 1 to 63) **DESCRIPTION** MAXFRAME is an optional PORT configuration directive used in XROUTER.CFG. It specifies the AX25 "window", i.e. the maximum number of unacknowledged frames allowed before the link must stop and wait for an ack. The normal range is between 1 and 7, although maxframes of up to 63 are allowed on modulo-128 (EAX25) links. The default value of MAXFRAME is 3. The value can be changed during run-time using the MAXFRAME command. **OPTIONS** If you set a value between 8 and 63, XRouter will attempt to use Modulo-128 (Extended AX25) on outgoing links. If the link partner is not capable of Modulo-128, the link will fall-back to normal AX25. If the port PACLEN is set to 0, XRouter dynamically adapts MAXFRAME (and PACLEN) to the link conditions, to maximise throughput. **EXAMPLE** MAXFRAME=4 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#MAXFRAME| MAXFRAME(1) -- Display / Set port MAXFRAME value.]] \\ [[packet:xrouter:docs:MAN7#PACLEN| PACLEN(7) -- Maximum AX25 Packet Length.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAXHOPS ===== MAXHOPS(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** MAXHOPS -- Set Hopcount Horizon. **SYNOPSIS** MAXHOPS=n (n = 0-30) **AVAILABILITY** Used only in XROUTER.CFG. **DESCRIPTION** MAXHOPS is a global and PORT configuration keyword used in XROUTER.CFG, and a parameter which can be used in a ROUTE ADD command. It specifies the maximum accepted hop count for new nodes table entries received via INP3 unicasts from neighbours. Node information with hop counts that exceed this figure are not accepted into the nodes table. This parameter has no effect on data received via conventional NetRom broadcasts. MAXHOPS would typically be used to limit the "hop horizon" to a smaller value than the default horizon, which is 30. Like MAXTT, it can be used to limit the number of node entries that are accepted via a particular port or neighbour. For example, the RF purists don't like Internet-routed nodes cluttering up their tables, nor do they want traffic to "short-circuit" the RF links via tortuous multi-hop Internet routes. In this case, a low MAXHOPS might be used at the interface between the RF-based network segment and the Internet-based segment, to (a) control the number of Internet nodes appearing in the nodes tables of the RF routers, and (b) limit the run-length of Internet routes. MAXHOPS can be used in 3 places: If used in the "global" section of XROUTER.CFG, it specifies a default value for all ports, overriding the default of 30. If used in a PORT configuration block, it overrides the global default. All new routes inherit this value. Finally the PORT value can be overridden for individual routes using by "locking-in" the route at the end of XROUTER.CFG, or by a ROUTE ADD command in the XRNODES file or at the command prompt. For example: route add g8pzt 5 100 ! 0 0 0 2000 5 This adds a locked in route to neighbour "g8pzt" on port 5, quality 100, with default maxframe, paclen and frack, MAXTT of 2000 and MAXHOPS of 5. Setting MAXHOPS to 0 will block all received INP3 data. **CAVEATS** Using MAXHOPS to limit the no. of nodes learned via a neighbour may fail if the neighbour duplicates the INP3 data in NetRom nodes broadcasts. This may enter nodes which are beyond your chosen hop limit into the nodes table and keep them refreshed. The only defence is to ignore data from NetRom broadcasts by setting the port QUALITY below MINQUAL, or to set the MINQUAL high. Both actions may cause the loss of some NetRom-only nodes from the table. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#INP3| INP3(9) -- InterNode Protocol ]] \\ [[packet:xrouter:docs:MAN7#MAXTT| MAXTT(7) -- Maximum Trip Time. ]] \\ [[packet:xrouter:docs:MAN1#MINQUAL| MINQUAL(1) -- Display / Set port Minimum Quality ]] \\ [[packet:xrouter:docs:MAN1#QUALITY| QUALITY(1) -- Display / Modify NetRom Quality. ]] \\ [[packet:xrouter:docs:MAN1#ROUTES| ROUTES(1) -- Display / Modify NetRom Neighbour Routes. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAXLINKS ===== MAXLINKS(7) XROUTER REFERENCE MANUAL 24/10/2023 **NAME** MAXLINKS -- Maximum Simultaneous AX25 L2 links. **SYNOPSIS** MAXLINKS=n (n=0-65535) **DESCRIPTION** MAXLINKS is an optional directive used in the "global" section of XROUTER.CFG. It specifies the maximum number simultaneous AX25 L2 links that XRouter can accommodate. (default=30) You should set this large enough to accommodate the total number of AX25 L2 users and internode links that you expect, but not too large because it reserves a block of memory for each link. **EXAMPLE** MAXLINKS=50 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#SESSLIMIT| SESSLIMIT(7) -- Maximum Simultaneous Connections on Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MAXTT ===== MAXTT(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** MAXTT -- Maximum Trip Time. **SYNOPSIS** MAXTT=n (n = 0-60000) **AVAILABILITY** Used only in XROUTER.CFG. **DESCRIPTION** MAXTT is a global and PORT configuration keyword used in XROUTER.CFG, and a parameter which can be used in a ROUTE ADD command. It defines the maximum accepted "trip time" (transit time) for new nodes table entries received via INP3 unicasts from neighbours. Node information with trip times that exceed this figure are not accepted into the nodes table. This parameter has no effect on data received via conventional NetRom nodes broadcasts. MAXTT would typically be used to limit the "trip time horizon" to a smaller value than the default horizon, which is 60000 (600 seconds). Like MAXHOPS, it can be used to limit the number of node entries that are accepted via a particular port or neighbour. For example, if an RF user lists a moderately sized nodes table via an average 1200 baud RF link, it could take several minutes to download the data. It becomes impractical to use the "N" commands in that situation. Experience has shown that a nodes table with more than 150 entries is impractical for RF users. Since Internet-based routers have low trip times to everywhere, they tend to have very large nodes tables. Thus routers on the Internet<>RF interface, and their RF neighbours, would also have over-sized tables, comprised mainly of Internet-routed nodes. Many of these nodes are in foreign-language countries of no interest to the RF user. The sysop may choose to limit the horizon to reduce the number of Internet nodes in the table. Alternatively (and more likely since there are so few RF nodes nowadays), a sysop may decide that nodes with trip times of more than 10 seconds are too slow, and not worth having in the table, and would therefore set a MAXTT of 1000. MAXTT can be used in 3 places: If used in the "global" section of XROUTER.CFG, it specifies a default value for all ports, overriding the default of 60000. If used in a PORT configuration block, it overrides the global default. All new routes inherit this value. Finally the port default can be overridden for individual routes using by "locking-in" the route at the end of XROUTER.CFG, or by a ROUTE ADD command in the XRNODES file or at the command prompt. For example: ROUTE ADD g8pzt 5 100 ! 0 0 0 2000 5 This adds a locked in route to neighbour "g8pzt" on port 5, quality 100, with default maxframe, paclen and frack, MAXTT of 2000 and MAXHOPS of 5. Setting a route's MAXTT to 0 effectively blocks all INP3 activity. It disables INP3 unicasts, and ignores received INP3. This is not recommended, but NetRom purists may wish to do it anyway. **CAVEATS** Using MAXTT to limit the no. of nodes learned via a neighbour may fail if the neighbour duplicates the INP3 data in conventional NetRom nodes broadcasts. This may enter nodes which are beyond your chosen trip time horizon into the nodes table and keep them refreshed. The only defence is to ignore data from NetRom broadcasts by setting the port QUALITY below MINQUAL, or to set the MINQUAL high. Both actions may cause the loss of some NetRom-only nodes from the table. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#INP3| INP3(9) -- InterNode Protocol ]] \\ [[packet:xrouter:docs:MAN7#MAXHOPS| MAXHOPS(7) -- Maximum Hop Count. ]] \\ [[packet:xrouter:docs:MAN1#MINQUAL| MINQUAL(1) -- Display / Set port Minimum Quality ]] \\ [[packet:xrouter:docs:MAN1#QUALITY| QUALITY(1) -- Display / Modify NetRom Quality. ]] \\ [[packet:xrouter:docs:MAN1#ROUTES| ROUTES(1) -- Display / Modify NetRom Neighbour Routes. ]] \\ [[packet:xrouter:docs:MAN8#XRNODES| XRNODES(8) -- Nodes / Routes Recovery File. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MHEARD ===== MHEARD(7) XROUTER REFERENCE MANUAL 21/9/2023 **NAME** MHEARD -- Enable MHeard & set size. **SYNOPSIS** MHEARD= (where is a number between 0 and 50) **DESCRIPTION** MHEARD is an optional directive which may be used in PORT defininition blocks in XROUTER.CFG. If present, it specifies the MHEARD size for that port. Specifying a of zero, or omitting the directive, disables MHEARD on that port. The maximum size is currently 50 slots, to discourage the sending of ridiculously long MHeard lists on congested RF channels. If you have a requirement for more, please say so. The size of the MHeard list may be changed during run-time using the MHSIZE command. **EXAMPLES** MHEARD=10 ; Enable MHeard, 10 callsigns max MHEARD=0 ; Disable MHeard **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#MHCLEAR| MHCLEAR(1) -- Clear MHeard list. ]] \\ [[packet:xrouter:docs:MAN1#MHEARD| MHEARD(1) -- List recently heard stations. ]] \\ [[packet:xrouter:docs:MAN1#MHFLAGS| MHFLAGS(1) -- Display / Set MHeard options. ]] \\ [[packet:xrouter:docs:MAN1#MHSIZE| MHSIZE(1) -- Adjust size of MHeard list. ]] \\ [[packet:xrouter:docs:MAN7#MHFLAGS| MHFLAGS(7) -- MHeard option flags directive. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:MAN9#MHEARD| MHEARD(9) -- About "Monitor Heard". ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MHFLAGS ===== MHFLAGS(7) XROUTER REFERENCE MANUAL 18/10/2023 **NAME** MHFLAGS -- MHeard option flags. **SYNOPSIS** MHFLAGS=n (where n is a number between 0 and 255) **DESCRIPTION** MHFLAGS is an optional directive which may be used in PORT defininition blocks in XROUTER.CFG. If present, it specifies the MHEARD options for that port. These flags control which callsigns are recorded in the MHeard list. The settings may be changed suring run-time using the MHF[lags] command. **OPTIONS** The argument to MHFLAGS is the sum of the required options from this list: 1 Record directly heard stations 2 Record directly heard digipeaters 4 Record digipeated stations 8 Record direct/digipeated separately for each station 16 Preserve MHeard list across reboots. The default is 255 (record everything). **EXAMPLES** MHFLAGS=3 ; Directly heard stations & digipeaters only MHFLAGS=4 ; Digipeated stations only **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#MHCLEAR| MHCLEAR(1) -- Clear MHeard list. ]] \\ [[packet:xrouter:docs:MAN1#MHEARD| MHEARD(1) -- List recently heard stations. ]] \\ [[packet:xrouter:docs:MAN1#MHFLAGS| MHFLAGS(1) -- Display / Set MHeard options. ]] \\ [[packet:xrouter:docs:MAN1#MHSIZE| MHSIZE(1) -- Adjust size of MHeard list. ]] \\ [[packet:xrouter:docs:MAN7#MHEARD| MHEARD(7) -- MHeard size/enable directive ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:MAN9#MHEARD| MHEARD(9) -- About "Monitor Heard". ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MINQUAL ===== MINQUAL(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** MINQUAL -- Minimum Quality to Add to Nodes Table. **SYNOPSIS** MINQUAL=n (where n is in the range 0 to 255) **DESCRIPTION** MINQUAL is an optional global and PORT directive used in XROUTER.CFG. It specifies the minimum Net/rom "quality" a node must have, in order to be accepted into the nodes table. The "global" MINQUAL is inherited by all PORTs subsequently defined, unless explicitly overridden by a port MINQUAL. When "nodes" broadcasts are received on a port, the "quality" of each node thus learned is "de-rated" by an amount dependent on the port's QUALITY figure. If the de-rated quality is less than the port MINQUAL, the node is not accepted into the table. This can be used to exclude unreachable and marginal nodes, but must be used with care. **EXAMPLE** MINQUAL=100 ; No nodes less than quality 100 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#MINQUAL| MINQUAL(1) -- Display / Set port minimum quality]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#QUALITY| QUALITY(7) -- NetRom Quality]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MINTXQUAL ===== MINTXQUAL(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** MINTXQUAL -- Minimum Quality to Broadcast. **SYNOPSIS** MINTXQUAL=n (where n is in the range 0 to 255) **DESCRIPTION** MINTXQUAL is a PORT directive used in XROUTER.CFG. It specifies the minimum NetRom node "quality" to include in nodes broadcasts on this port. The acceptable range is 0 to 255, and the default is 0. This is used to limit the size of nodes broadcasts on ports which are low bandwidth, low quality, or where the neighbours have limited nodes table capacity. The value of MINTXQUAL can be changed during run-time using the MINTXQUAL command. **EXAMPLE** MINTXQUAL=100 ; Don't broadcast nodes with quality <100 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MINQUAL| MINQUAL(7) -- Minimum Quality.]] \\ [[packet:xrouter:docs:MAN1#MINTXQUAL| MINTXQUAL(1) -- Display / Set minimum quality to transmit]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#QUALITY| QUALITY(7) -- NetRom Quality]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MQTTPORT ===== MQTTPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** MQTTPORT -- TCP Port for MQTT Server/Broker. **SYNPOSIS** MQTTPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** MQTTPORT is an optional GLOBAL configuration directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number for XRouter's internal MQTT server/broker. If not present, the default is 1883. The MQTT server (previously known as a "broker") allows MQTT clients to exchange information with XRouter, with each other, and with an external broker. Although primarily intended for use via the LAN, the broker is also available via NetRomX service 1883 for anyone who wants to experiment with MQTT over radio. **OPTIONS** If a single argument is supplied, e.g. "MQTTPORT=99", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "MQTTPORT=99 9999", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting MQTTPORT to zero on a stack prevents TCP connections to the broker via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags.]] \\ [[packet:xrouter:docs:MAN9#MQTT-SRV| MQTT-SRV(9) -- MQTT Server/Broker.]] \\ [[packet:xrouter:docs:MAN9#MQTT-SVC| MQTT-SVC(9) -- NetRomX MQTT Service.]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MQTTSERVADDR ===== MQTTSERVADDR(7) XROUTER REFERENCE MANUAL 23/9/2023 **NAME** MQTTSERVADDR -- Hostname / IP address of external MQTT Broker. **SYNOPSIS** MQTTSERVADDR= **DESCRIPTION** MQTTSERVADDR is an optional directive used in XROUTER.CFG. If present, it specifies the IP address or hostname of an external MQTT broker, to which XRouter's MQTT "publisher" can connect and publish data. If MQTTSERVADDR is not specified, which is the default condition, the publisher is disabled. **EXAMPLES** MQTTSERVADDR=192.168.1.20 MQTTSERVADDR=test.mosquitto.org **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#MQTT-PUB| MQTT-PUB(9) -- MQTT Publisher.]] \\ [[packet:xrouter:docs:MAN7#MQTTSERVPORT| MQTTSERVPORT(7) -- TCP Port of external MQTT Broker]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== MQTTSERVPORT ===== MQTTSERVPORT(7) XROUTER REFERENCE MANUAL 23/9/2023 **NAME** MQTTSERVPORT -- TCP Port of External MQTT Broker. **SYNOPSIS** MQTTSERVPORT=n (where n is between 0 and 65535) **DESCRIPTION** MQTTSERVPORT is an optional directive, used in XROUTER.CFG. If present, it specifies the TCP port of an external MQTT broker, to which XRouter's MQTT "publisher" can connect and publish data. MQTTSERVPORT defaults to 1883. Setting it 0 disables the MQTT publisher. **EXAMPLE** MQTTSERVADDR=2884 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#MQTT-PUB| MQTT-PUB(9) -- MQTT Publisher.]] \\ [[packet:xrouter:docs:MAN7#MQTTSERVADDR| MQTTSERVADDR(7) -- Hostname / IP of External MQTT Broker.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== NETMASK ===== NETMASK(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** NETMASK -- Subnet Mask. **SYNOPSIS** NETMASK= **DESCRIPTION** NETMASK is an optional PORT directive used in XROUTER.CFG. It specifies a "subnet mask", which together with the port IPADDRESS defines the range of IP addresses that are on the same physical network segment as XRouter, and thus can be reached directly. If XRouter sees any IP datagrams with destination addresses in that range, that are NOT addressed to itself, it will not attempt to route them. The value set by this directive at boot-time can be changed during run-time. For more information see the NETMASK command page. **EXAMPLE** NETMASK=255.255.255.0 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#IPADDRESS| IPADDRESS(7) -- Main or Port IP Address.]] \\ [[packet:xrouter:docs:MAN1#NETMASK| NETMASK(1) -- Display / Set Port NETMASK.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== NODEALIAS ===== NODEALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** NODEALIAS -- Primary AX25 / NetRom Alias. **SYNOPSIS** NODEALIAS= **DESCRIPTION** NODEALIAS is a MANDATORY directive used in the "global" section of XROUTER.CFG, It specifies an "alias", i.e. a memorable or meaningful alternative to the NODECALL, which can be used for all AX25 and NetRom operations. The is a string of up to 6 uppercase ASCII characters and numbers of your choice. It does not have a SSID. Aliases beginning with "#" are not displayed in node lists, and are used for "linking only" nodes with no user access. It is suggested that the alias be geographically relevant beyond your own local area, for example BRSTOL, LEEDS or BRUM, so it can be easily identified. However, some sysops who run multiple node types tend to use "XR..." or "...XR" for their XRouter nodes, e.g. "XRPAG5", "DOTXR", "OMXRP". All AX25 ports respond to AX25 connect requests directed at this alias. They may also have up to 2 additional aliases. **EXAMPLES** NODEALIAS=KIDDER ; Kidderminster NODEALIAS=PZTXRP ; G8PZT's XRPi **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#NODECALL| NODECALL(7) -- Primary AX25 / Netrom Callsign.]] \\ [[packet:xrouter:docs:MAN7#PORTALIAS| PORTALIAS(7) -- Additional Alias for a Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== NODECALL ===== NODECALL(7) XROUTER REFERENCE MANUAL 23/10/2023 **NAME** NODECALL -- Primary AX25 / NetRom Callsign. **SYNOPSIS** NODECALL=[-ssid] **DESCRIPTION** NODECALL is a MANDATORY directive used in the "global" section of XROUTER.CFG, It specifies the callsign used for all AX25 L3/4 operations, and the default for L2 operations on each port. It is the primary station identifier, and is also used in the prompts, ID beacons etc. The argument to NODECALL consists of up to 6 alphanumeric characters plus an optional SSID between 1 and 15. **EXAMPLE** NODECALL=GB7PZT-12 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#NODEALIAS| NODEALIAS(7) -- Primary AX25 / Netrom Alias.]] \\ [[packet:xrouter:docs:MAN7#PORTCALL| PORTCALL(7) -- Port Callsign.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== NODESINT ===== NODESINT(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** NODESINTERVAL -- Nodes Broadcast Interval. **SYNOPSIS** NODESINTERVAL= **DESCRIPTION** NODESINTERVAL is both a global and PORT directive, used in XROUTER.CFG. It specifies the interval, in minutes, between NetRom nodes broadcasts. The default is 60 minutes. If used in the "global" section of XROUTER.CFG, it sets the global NODESINTERVAL, the default for all PORTs. If used in a PORT block, it applies to that port only. Whilst the Netrom network usually works on a 60 minute nodes broadcast cycle, some types of software insist on a much smaller broadcast interval. It is harmful to the established network if sysops try to accommodate these neighbours by setting the global NODESINTERVAL to a smaller value, but using this keyword on a per-port basis you can keep these neighbours happy without disrupting the rest of the Netrom network. **OPTIONS** If you set a NODESINTERVAL=0 on a PORT, XRouter ignores received nodes broadcasts on that port, but will allow L3/L4 activity if QUALITY is non-zero. **EXAMPLE** NODESINTERVAL=10 ; 10 minues between broadcasts **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#NODESINT| NODESINT(1) -- Display / Set NODESINTERVAL.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#QUALITY| QUALITY(7) -- NetRom Quality]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PACLEN ===== PACLEN(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PACLEN -- Maximum Packet Length. **SYNOPSIS** PACLEN=n (where n is in the range 0 to 256) **DESCRIPTION** PACLEN is both a GLOBAL and a PORT configuration directive, used in XROUTER.CFG. It specifies the maximum length of the information-bearing portion of frames transmitted by XRouter. If used in the "global" section of XROUTER.CFG, it sets the default value for NetRom L3 operations. The default is 236, which is the largest NetRom payload that will fit in a full sized AX25 frame. If used in a PORT definition block, PACLEN applies to that port only, and sets the maximum payload size for AX25 frames transmitted on that port. The default in this case is 256. New AX25 connections "inherit" this value, but may adjust it dynamically if allowed to do so. Inter-node links can override this inheritance and use a value specified by a ROUTE command or a suitable entry in XRNODES. **OPTIONS** If the port PACLEN is set to 0, Xrouter dynamically adapts PACLEN (and MAXFRAME) to the link conditions, to maximise throughput. **EXAMPLE** PACLEN=160 ; Allow 160 byte packets **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MAXFRAME| MAXFRAME(7) -- Maximum Unacked AX25 Frames.]] \\ [[packet:xrouter:docs:MAN1#PACLEN| PACLEN(1) -- Display / Set Paclen.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PEER ===== PEER(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** PEER -- Specify AXIP / AXUDP Link Partner. **SYNOPSIS** PEER=[:alias] **DESCRIPTION** PEER is an optional directive that may be used in certain types of PORT block within XROUTER.CFG. It is used to specify the IP addresses and UDP ports for one or more AXUDP / AXIP link partners. PEER is valid only when the PORT is attached to an INTERFACE which has "TYPE=AXUDP" and the PORT's IPLINK is "0.0.0.0". A PORT defined like this can support both AXIP and AXUDP links. Only ONE such port is allowed. This is the "alternative" way of doing AXIP / AXUDP, which is slighly less flexible than the "normal" (one link per port) method. It can be used alongside the "normal" method. The fields of a PEER statement may be separated by one or more spaces or tabs There is no limit to the number of PEER statements that may be used. **OPTIONS** is mandatory. It is not case-dependent. If an SSID is included, only packets addressed that exact destination will be routed. If an SSID is not included, all SSID's of the callsign are routed. To route packet only to G8PZT and none of its SSID's you would use G8PZT-0. [alias] is optional, and case-independent. If present, it allows AX25 Layer 2 connections to the partner's alias. is mandatory. Use an IP address if possible, because it saves having to resolve the hostname. is mandatory, but is specified as 0 for AXIP. **EXAMPLES** # Route all SSID's of G8PZT using AXUDP, to udp port 9393 PEER=G8PZT g8pzt.ath.cx 9393 # As above, but route on either callsign or alias PEER=G8PZT g8pzt.ath.cx 9393 # Route only to exact SSID G8PZT-14 via localhost PEER=G8PZT-14 127.0.0.1 10093 # Route packets using AXIP instead of AXUDP PEER=G8PZT-0:KIDDER g8pzt.ath.cx 0 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AXIP| AXIP(9) -- AX25 over IP]] \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25 over UDP]] \\ [[packet:xrouter:docs:MAN7#LEARN| LEARN(7) -- Learn Unsolicited AX*P Peer Details.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PERSIST ===== PERSIST(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PERSIST -- AX25 Probablity to Transmit. **SYNOPSIS** PERSIST=n (n=0-255) **DESCRIPTION** PERSIST is an optional PORT directive used in XROUTER.CFG. It specifies the AX25 "Probability to transmit" in a given time slot (see SLOTTIME), used as part of the CSMA channel access procedure, to minimise media contention. A low value is used when there are several stations sharing the channel, giving each a fair chance to transmit. A high value can be used when the channel isn't shared. The optimum setting is 255/n where n is the number of stations sharing the channel. The default is 64. **EXAMPLES** PERSIST=25 ; 10% probability / 10 stations PERSIST=128 ; 50% probability / 2 stations **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PERSIST| PERSIST(1) -- Display / Set Port Persist.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#SLOTTIME| SLOTTIME(7) -- CSMA interval timer]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PIPE ===== PIPE(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PIPE -- Frame Pipe. **SYNOPSIS** PIPE= [callsign,callsign...] **DESCRIPTION** PIPE is an optional PORT directive used in XROUTER.CFG. It creates a "frame pipe" to another port. This allows frames received (and optionally sent) on this port to be copied to another port, e.g. to allow a PMS on one port to see the traffic on another port. Unless the "bi-directional" option (see below) is specified, pipes are one way. In order to have two way traffic using a uni-directional pipe, you must set up a reverse pipe on the opposite port. You may pipe several ports to a single destination port, but you can only have one *outgoing* pipe from any port. Pipes are capable of generating an immense amount of traffic, so use them with care - your target port MUST be capable of handling the traffic load. By default, pipes are not selective, i.e. they pass traffic from any source callsign to any destination callsign (with the exception of Budlisted callsigns). On a busy channel, this could result in a lot of unnecessary traffic being piped. Therefore pipes can be made "selective", by adding a comma- delimited callsign list, e.g. "PIPE=4 GB7PZT,KDRBBS". This reduces the loading on the target port, by piping only the frames with the specified calls in the destination field. Pipes can also be made selective in terms of the types of traffic they pipe (AX25, NetRom etc). This is controlled by PIPEFLAG. Pipes can be made "bi-directional" by adding 512 to the PIPEFLAG value (suggested value = 515). If a frame is piped on a bi-directional pipe, the source call is remembered so that responses can be piped back to the sender. Thus a reverse pipe is not needed. Bi-directional pipes are useful where a BBS has a front end router - simply set up bi-directional selective pipes from each user port to the BBS port, and set up the BCAST option so that the UI mail headers are broadcast on each user port. The BBS will then allow direct connect and will respond to resync requests. To disable piping, set PIPE=0 or just omit the directive. Pipes can also be created and reconfigured during run-time, using the PIPE command. **EXAMPLES** PIPE=2 ; Pipe frames from this port to port 2 PIPE=4 GB7PZT,KDRBBS ; Selective pipe to port 4 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PIPE| PIPE(1) -- Display / Set "frame piping".]] \\ [[packet:xrouter:docs:MAN7#PIPEFLAG| PIPEFLAG(7) -- Frame Pipe Options.]] \\ [[packet:xrouter:docs:MAN9#PIPES| PIPES(9) -- About Frame Pipes.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PIPEFLAG ===== PIPEFLAG(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PIPEFLAG -- Frame Pipe Option Flags. **SYNOPSIS** PIPEFLAG=n (where n is in the range 0 to 1023) **DESCRIPTION** PIPEFLAG is an optional PORT directive, used in XROUTER.CFG. It is only used when piping is active, and controls which frames are piped. The default value is 3. **OPTIONS** The argument is the sum of the required options as follows: 1 - UI frames *not* addressed to nodecall/alias. 2 - Non-UI frames *not* addressed to nodecall/alias. 4 - UI frames addressed to nodecall/alias. 8 - Non-UI frames addressed to nodecall/alias. 16 - UI frames transmitted by XRouter. 32 - Non-UI frames transmitted by XRouter. 64 - Allow budlisted users to be piped. 128 - Netrom frames 256 - IP / ARP frames 512 - Bi-directional piping **EXAMPLES** PIPEFLAG=5 ; Pipe received UI frames only PIPEFLAG=517 ; Bi-directional UI pipe **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#PIPE| PIPE(7) -- Frame Pipe Directive.]] \\ [[packet:xrouter:docs:MAN1#PIPEFLAG| PIPEFLAG(1) -- Display / Set Frame Pipe Options.]] \\ [[packet:xrouter:docs:MAN9#PIPES| PIPES(9) -- About Frame Pipes.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PMSALIAS ===== PMSALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PMSALIAS -- Alias for Personal Mail System. **SYNOPSIS** PMSALIAS= **DESCRIPTION** PMSALIAS is a directive that can be used in XROUTER.CFG, both "globally" and within PORT definition blocks. It specifies an "alias", i.e. a sort of memorable alternative "callsign" for the PMS, e.g. "IOWPMS" (Isle of Wight PMS). This can be used interchangeably with the PMSCALL; i.e. the PMS will respond to either. The is a string of up to 6 uppercase ASCII characters and numbers. It is suggested that it should end with "PMS", and begin with the last 3 letters of the sysop's callsign. Alternatively, if the PMS is being used as a public BBS, you could use something geographically relevant, e.g. BHMPMS for Birmingham, KDRPMS for Kidderminster etc., so it can be easily identified in node tables. If used "globally", it specifies the "primary" PMS alias, used for AX25, NetRom and TCP operations. Any PORTs declared further down XROUTER.CFG "inherit" this alias for AX25 Layer 2 PMS operation on that port, UNLESS overridden by the use of PMSALIAS within that PORT's definition block. If PMSALIAS is used within a PORT definition block, it replaces the "global" PMS alias for that port only. **EXAMPLES** PMSALIAS=IOWPMS PMSALIAS=PZTPMS **CAVEATS** Omitting the global PMSALIAS, or setting it IDENTICAL to NODEALIAS disables PMS NetRom connectivity, but the PMS can still be used "standalone" via the PMS command. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PMS| PMS(1) -- Start PMS Session.]] \\ [[packet:xrouter:docs:MAN9#PMS| PMS(9) -- Personal Mail Server.]] \\ [[packet:xrouter:docs:MAN7#PMSCALL| PMSCALL(7) -- PMS Callsign.]] \\ [[packet:xrouter:docs:MAN7#PMSQUAL| PMSQUAL(7) -- NetRom Quality for PMS.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PMSCALL ===== PMSCALL(7) XROUTER REFERENCE MANUAL 24/9/2023 **NAME** PMSCALL -- Callsign for Personal Message System. **SYNOPSIS** PMSCALL= **DESCRIPTION** PMSCALL is a directive that can be used in XROUTER.CFG, both "globally" and within PORT definition blocks. It specifies the AX25/NetRom callsign for the Personal Message / Mailbox System (PMS). This can be used interchangeably with the PMSALIAS; i.e. the PMS will respond to connections directed at either. If used "globally", PMSCALL specifies the "primary" PMS callsign, used for AX25 and NetRom operations. This can be the same as NODECALL, but MUST use a different SSID. A SSID of -2 is the de-facto standard for XRPMS systems. Any PORTs declared further down XROUTER.CFG "inherit" this callsign for AX25 Layer 2 PMS operation on that port, UNLESS overridden by the use of PMSCALL within that PORT's definition block. If PMSCALL is used within a PORT definition block, it replaces the "global" PMS callsign for that port only. **EXAMPLE** PMSCALL=G8PZT-2 **CAVEATS** Omitting the global PMSCALL, or setting it IDENTICAL to NODECALL (including the SSID) disables PMS server connectivity, but the PMS can still be used "standalone" via the PMS command. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PMS| PMS(1) -- Start PMS Session.]] \\ [[packet:xrouter:docs:MAN9#PMS| PMS(9) -- About the Personal Message System.]] \\ [[packet:xrouter:docs:MAN7#PMSALIAS| PMSALIAS(7) -- Personal Message System Alias.]] \\ [[packet:xrouter:docs:MAN7#PMSQUAL| PMSQUAL(7) -- NetRom Quality for PMS.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PMSHADDR ===== PMSHADDR(7) XROUTER REFERENCE MANUAL 29/3/2024 **NAME** PMSHADDR -- Hierarchical Address of PMS. **SYNOPSIS** PMSHADDR= **DESCRIPTION** PMSHADDR is an optional directive, which can be used anywhere within the "global" section of XROUTER.CFG. If present, it specifies the "hierarchical address" of the inbuilt mailbox. This address is used, in combination wih the mailbox callsign, for routing mail. If a typical mailbox address is "GB7PZT.#24.GBR.EU", the ".#24.GBR.EU" is the "hierarchical address" (HA) part. This is usually read from right to left, specifying first the continent (EU), then the country within the continent (GBR), then the region within the country (#24). PMSHADDR is not required for "normal" PMS operation, but is required if you intend to exchange mail with other systems. Note that it MUST begin with a dot. **EXAMPLE** PMSHADDR=.#24.GBR.EU **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PMS| PMS(1) -- Access Personal Message System(s).]] \\ [[packet:xrouter:docs:MAN7#PMSTYPE| PMSTYPE(7) -- Specify PMS / BBS mode.]] \\ [[packet:xrouter:docs:MAN8#PMS.CFG| PMS.CFG(8) -- PMS Configuration File.]] \\ [[packet:xrouter:docs:MAN9#PMS| PMS(9) -- About the PMS.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PMSQUAL ===== PMSQUAL(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** PMSQUAL -- NetRom Quality for Personal Message System. **SYNOPSIS** PMSQUAL=n (n=0-255) **DESCRIPTION** PMSQUAL is an optional directive used in the "global" section of XROUTER.CFG. It specifies the NetRom "quality" associated with the PMSCALL and PMSALIAS in nodes broadcasts from XRouter. The default is 0, which suppresses broadcasting of the PMS callsign and alias. A non-zero value of PMSQUAL has no effect unless both PMSCALL and PMSALIAS are defined. The use of a non-zero value is deprecated unless you are using the PMS as a public maildrop / BBS, because it bloats the nodes tables with PMS's that nobody is likely to use. Even if PMSQUAL is 0, the PMS is always available via the NODECALL, using NetRomX service number 2. **EXAMPLE** PMSQUAL=50 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#PMSALIAS| PMSALIAS(7) -- Alias of Personal Message System.]] \\ [[packet:xrouter:docs:MAN7#PMSCALL| PMSCALL(7) -- Callsign of Personal Message System]] \\ [[packet:xrouter:docs:MAN9#PMS| PMS(9) -- About the Personal Message System]] \\ [[packet:xrouter:docs:MAN9#PMS-SVC| PMS-SVC(9) -- NetRomX PMS Service.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PMSTYPE ===== PMSTYPE(7) XROUTER REFERENCE MANUAL 29/3/2024 **NAME** PMSTYPE -- Set PMS / BBS mode. **SYNOPSIS** PMSTYPE=n (n=0-4) **DESCRIPTION** PMSTYPE is an optional directive, which can be used anywhere within the "global" section of XROUTER.CFG. If present, it specifies the type, or mode, of the inbuilt mailbox. If not present, the mode defaults to 1 (standard PMS). The purpose of this is to allow the sysop to comply with their local licensing regulations and/or to have some control over what their system is doing. **OPTIONS** 0 Reserved for possible "No bulletins" option. 1 Normal PMS, reverse forwarding only (default) 2 PMS with forwarding and reverse forwarding. 3 PMS with forwarding, reverse forwarding & relaying 4 Full BBS The "Standard PMS" option accepts incoming mail (including bulletins) from bulletin boards, and allows outgoing mail to be collected by them. It also allows automatic XRouter to Xrouter private mail forwarding. It does not allow the mailbox to initiate "conventional" forwarding to other systems. Mode 2 allows "conventional" forwarding and reverse forwarding, but does not allow "relaying", i.e. mail received from one BBS cannot be forwarded to another. Mode 3 is a "sleeper" BBS. It looks and acts like a BBS, but pretends to be a PMS. It is still accessed using the PMS command. Mode 4 changes some of the captions, and installs the "BBS" command (in addition to the PMS command). If accessed via the former, both bulletins and personal mail are displayed by default. If accessed via the PMS command, only personal mail is displayed by default. **EXAMPLES** PMSTYPE=1 - Normal PMS PMSTYPE=3 - BBS masqurading as a PMS **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#PMS| PMS(1) -- Access Personal Message System(s).]] \\ [[packet:xrouter:docs:MAN7#PMSHADDR| PMSHADDR(7) -- Hierarchical Address of PMS.]] \\ [[packet:xrouter:docs:MAN8#PMS.CFG| PMS.CFG(8) -- PMS Configuration File.]] \\ [[packet:xrouter:docs:MAN9#PMS| PMS(9) -- About the PMS.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PORTALIAS2 ===== PORTALIAS2(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PORTALIAS2 -- Secondary Alias for a Port. **SYNOPSIS** PORTALIAS2= **DESCRIPTION** PORTALIAS2 is an optional PORT directive used in XROUTER.CFG. It specifies an additional AX25 alias for the port, to be used for DIGIPEATING only. It does not accept connections. The is a string of up to 6 uppercase ASCII characters and numbers. **EXAMPLE** PORTALIAS2=KRDIGI **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#PORTALIAS| PORTALIAS(7) -- Additional Port Alias.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PORTALIAS ===== PORTALIAS(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PORTALIAS -- Additional Alias for a Port. **SYNOPSIS** PORTALIAS= **DESCRIPTION** PORTALIAS is an optional PORT directive used in XROUTER.CFG. It specifies an AX25 alias for the port, to be used in addition to the NODEALIAS. The port will then respond to connect requests directed at either alias. The is a string of up to 6 uppercase ASCII characters and numbers. **EXAMPLE** PORTALIAS=KDRMIN **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#NODEALIAS| NODEALIAS(7) -- Primary Node Alias]] \\ [[packet:xrouter:docs:MAN7#PORTALIAS2| PORTALIAS2(7) -- Secondary Port Alias.]] \\ [[packet:xrouter:docs:MAN7#PORTCALL| PORTCALL(7) -- Port Callsign.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PORTCALL ===== PORTCALL(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** PORTCALL -- Additional Callsign for a Port. **SYNOPSIS** PORTCALL=[-ssid] **DESCRIPTION** PORTCALL is an optional PORT directive used in XROUTER.CFG. It specifies an AX25 callsign for the port, to be used in addition to the NODECALL. The port will then respond to connect requests directed at either callsign. **EXAMPLE** PORTCALL=GB7PZT-1 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#NODECALL| NODECALL(7) -- Node Main Callsign.]] \\ [[packet:xrouter:docs:MAN7#PORTALIAS| PORTALIAS(7) -- Port Alias.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PROMPTCOLOR ===== PROMPTCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023 **NAME** PROMPTCOLOR -- Colour For XRouter Prompts. **SYNOPSIS** PROMPTCOLOR= **DESCRIPTION** PROMPTCOLOR is an optional directive that can be used both in the "global" section of XROUTER.CFG, and within CONSOLE definition blocks. It specifies the colour used by XRouter for prompts such as "VK2DOT-1:DOTXR}", "Type ? for command list", "Callsign:" etc. If used in the "global" section of XROUTER.CFG, the setting is inherited by all CONSOLEs subsequently defined. If used within a CONSOLE definition block, it applies only to that console, overriding any inherited setting. The default PROMPTCOLOR is TURQUOISE. Default colours have been carefully chosen for good visibility against a BLACK background. **OPTIONS** should be one of the 16 colour names described in COLOURS(6), but please note that some colour combinations have very poor visibility. In general, the lighter the background colour, the smaller the choice of foreground colours that will work with it. **EXAMPLE** PROMPTCOLOR=YELLOW **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#ANSI| ANSI(1) -- Enquire/set ANSI colour mode]] \\ [[packet:xrouter:docs:MAN6#COLOURS| COLOURS(6) -- XRouter Display Colours.]] \\ [[packet:xrouter:docs:MAN6#CONSOLES| CONSOLES(6) -- About XRouter Consoles.]] \\ [[packet:xrouter:docs:MAN7#ACTIONCOLOR| ACTIONCOLOR(7) -- Colour For XRouter Actions and Events.]] \\ [[packet:xrouter:docs:MAN7#CAPTIONCOLOR| CAPTIONCOLOR(7) -- Colour For Captions and Headings.]] \\ [[packet:xrouter:docs:MAN7#WARNCOLOR| WARNCOLOR(7) -- Colour For warnings and Errors.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PROTOCOL ===== PROTOCOL(7) XROUTER REFERENCE MANUAL 24/10/2023 **NAME** PROTOCOL -- Protocol Used on INTERFACE. **SYNPOSIS** PROTOCOL= **DESCRIPTION** PROTOCOL is a configuration directive used within INTERFACE definition blocks in XROUTER.CFG, to specify the protocol to use on the interface. It is mandatory in most types of INTERFACE, but not required in other types, e.g. TYPE=AXIP, AXUDP etc. must be one of the options detailed below. **OPTIONS** ASCII - Raw ASCII. This is a plain ASCII *uplink* to XRouter's command interpreter from a real "dumb terminal", or a "terminal emulator" such as Hyperterm, Procomm, PuTTY, Telink etc. via ASYNC interface. May also be used via TCP or UDP interface types. AX25 - Pure AX25, with no CRC or HDLC framing. Used for devices which provide their own CRC and HDLC framing, such as AGW, SCC cards, Baycom & YAM modems. Can also be used via "block mode" interfaces which need no CRC or HDLC framing, such as types LOOPBACK, TCP and UDP. AXIP - AX25 (with CRC) over IP. This is implicit for interface type AXIP, but does not cause an error if specified. Not for use with any other interface type. See AXIP(9) for more information. AXTCP - AX25 (with CRC) over TCP/IP This is implicit for interface type AXTCP, but does not cause an error if specified. Not for use with any other interface type. See AXTCP(9) for more information. AXUDP - AX25 (with CRC) over UDP/IP. This is implicit for interface type AXUDP, but does not cause an error if specified. Not for use with any other interface type. See AXUDP(9) for more information. DEDHOST - WA8DED Host Mode emulation. Used with ASYNC interface to support applications such as F6FBB BBS via real RS232 or pseudo-TTY pairs. See DEDHOST(9) for more information. ETHER - Ethernet protocol. Usually used with interface type EXTERNAL, but may also be used via LOOPBACK, TCP and UDP interfaces. HDLC - High-level Data Link Control protocol. This is not proper HDLC! It is AX25 with CRC, but without the HDLC flags and bit stuffing. For use with TCP, UDP and LOOPBACK interface types. IP - Raw Internet Protocol (IPv4). Used primarily for TUN interfaces, but may also be used on TCP, UDP and LOOPBACK interfaces. KISS - AX25 within KISS framing. Used via ASYNC interfaces for driving KISS TNCs, via TCP interface for soundcard packet drivers such as UZ7HO, Soundmodem, Direwolf etc. . MODEM - Hayes compatible PSTN modem. This is used only on ASYNC interfaces. NETROM - NetRom "backend" serial protocol. This is an "inter-node" protocol originally intended for linking NetRom TNC's (i.e. real TNCs running NET/ROM or TheNet node EPROM's) via their serial ports. Used with ASYNC interface type, but may also be used via LOOPBACK, TCP and UDP interfaces. The latter two NONE - No protocol. This is a dummy protocol for use with LOOPBACK. PPP - Point to Point Protocol. Used to transport IP over serial links such as RS232, dial-up connections etc. Used mainly with ASYNC interfaces, but can also be used on TCP, UDP and LOOPBACK. See PPP(9) for more info. SLIP - Serial Line Internet Protocol. This is IPv4 in a very simple encapsulation, for use on ASYNC interfaces, but can also be used on TCP, UDP and LOOPBACK. See SLIP(9) for more. TNC - TNC command line protocol. This is a plain ASCII *downlink* from XRouter to the command interpreter of a real TNC, or that of an application which accepts TNC-style commands, such as VARA. Used with ASYNC, TCP or UDP interfaces. TNC2 - TNC2 emulator. This is an 8-bit ASCII *uplink* from an external device or program to XRouter's TNC2 emulator, where XRouter looks like a "real" multi-port TNC as far as the external device is concerned. Usually used with ASYNC interface, but may also be used with interface types TCP and UDP. See TNC2(9) for more information. **NOTE** The LOOPBACK interface is completely internal to XRouter, and is intended only for test purposes. The use of any of the above protocols via LOOPBACK is completely pointless! **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#IFACES| IFACES(6) -- Interfaces in XRouter.]] \\ [[packet:xrouter:docs:MAN9#AXIP| AXIP(9) -- AX25 over IP Tunneling Protocol.]] \\ [[packet:xrouter:docs:MAN9#AXTCP| AXTCP(9) -- AX25 over TCPP Tunneling Protocol.]] \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25 over UDP Tunneling Protocol.]] \\ [[packet:xrouter:docs:MAN9#DEDHOST| DEDHOST(9) -- WA8DED Hostmode Emulation.]] \\ [[packet:xrouter:docs:MAN9#PPP| PPP(9) -- Point to Point Protocol.]] \\ [[packet:xrouter:docs:MAN9#PSTN| PSTN(9) -- PSTN Modem Support.]] \\ [[packet:xrouter:docs:MAN9#SLIP| SLIP(9) -- Serial Line Internet Protocol.]] \\ [[packet:xrouter:docs:MAN9#TNC2| TNC2(9) -- TNC2 Emulator.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== PROXY ===== PROXY(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** PROXY -- Proxy Connectivity. **SYNOPSIS** PROXY=[,call2,...] PROXY= PROXY= [passwrd] **DESCRIPTION** PROXY is an optional XROUTER.CFG directive that can be used both "globally" and within PORT definition blocks. It is used to define "proxies", which are AX25 or NetRom addresses which provide connectivity for otherwise unreachable targets. For example, providing an AX25 callsign for a TCP-based BBS. (See PROXIES page for full explanation). **OPTIONS** If used within a PORT definition block, PROXY defines an "AX25-to-NetRom" proxy, giving a NetRom target system a direct AX25 presence on the port. The format is: PROXY=[,netrom2,...] and are the NetRom callsigns of the proxied systems. Example: PROXY=GB7PZT,GB7BBS If used within the "global" section of XROUTER.CFG, there are TWO possible forms of the PROXY, as follows: The first of these is the "NetRom-to-AX25" proxy, the opposite of the above, whereby an AX25-only target is given a NetRom and AX25 presence, as if it was a real NetRom node. I.e. it appears in XRouter's nodes table and is broadcast to its neighbours. PROXY= is the NetRom and AX25 callsign is the NetRom and AX25 "alias" is the NetRom "quality" of the node in our table is the AX25 callsign of the proxied system is the PORT where the proxied system resides Example: PROXY=MB7UYL UYLBBS 150 G6KDR-3 7 The second "global" form is the "AX25/NetRom-to-TCP" proxy, which gives a TCP-only system both an AX25 and a NetRom presence on all ports. It is specified like this: PROXY= [passwrd] is the NetRom and AX25 callsign is the NetRom and AX25 "alias" is the NetRom "quality" of the node in our table is the proxied system's IP address. is the TCP port number of the proxied system. is an optional password sent to the proxied system upon connection. The proxied system uses this to verify that the TCP connection originates from an approved proxy. Example: PROXY=GB7PZT KDRBBS 150 192.168.0.4 8888 bloggs **WARNING** Proxies are very useful, but very dangerous if you aren't sure what you are doing! Proxy-created "forever loops" can kill XRouter, or cause interference to other systems. Don't use them if you don't need to, and please read the warnings in the PROXIES page. If your XRouter crashes, and you have proxies, then its a sure sign that you have configured them wrongly! **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#PROXIES| PROXIES(9) -- About Proxy Connections.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== QUALADJ ===== QUALADJ(7) XROUTER REFERENCE MANUAL 18/10/2023 **NAME** QUALADJUST -- NetRom Quality Manipulation. **SYNOPSIS** This file describes a feature which allows you to reduce the NetRom quality of "foreign" nodes on your system, or to exclude certain nodes or groups of nodes altogether. **DESCRIPTION** With ever-increasing connectivity via the Internet, the NetRom network is bypassing national and geographical boundaries, and this is causing problems. Because Internet qualities are much higher than radio qualities, there are far more nodes in the tables. In some cases there may be a limit to the size of tables, and more importantly there is a limit to the number of nodes that can be broadcast on a low bandwidth RF channel. In addition, with too many nodes in the table the "N" commands become useless because the response becomes too large for the user to download on a limited bandwidth channel. Even if there is sufficient bandwidth, the response may occupy several pages and the user may not be able to review anything which has scrolled off the screen. Experience has shown that 150 nodes is roughly the maximum comfortable table size. But how do you decide *which* 150 nodes to include? How do you achieve the balance between slow, unreliable, radio-routed nodes and fast, reliable, Internet-routed ones? Some people advocate setting low route qualities for the Internet links, but unless everyone agrees on those qualities, this can lead to traffic being routed via slow, unreliable links when faster and more direct routes exist! And do you want your table full of high quality internet-routed foreign nodes, to the exclusion of your local RF nodes? Can your users find the nodes they want, amidst the clutter? Quality de-rating by callsign can help with this management issue. It allows you to de-rate the NetRom quality of a node or group of nodes based on the NetRom callsign, instead of the route on which they were received. Thus, no matter what relative route qualities you use, you can change the relative qualities to favour your local nodes, or (more likely) those which share your language. **OPTIONS** This feature uses the global QUALADJUST directive in XROUTER.CFG as follows: QUALADJUST <0-255> e.g. QUALADJUST DEFAULT 120 QUALADJUST G* 255 QUALADJUST ZL* 200 The "default" argument sets the default value which is used to de-rate all nodes not matched by any other QUALADJUST statement. The normal NetRom de-rate algorithm is used, so 255 gives no de-rate and 0 gives full de-rate (i.e. to block a callsign or group of callsigns). If there are no QUALADJUST statements the default is 255. **LIMITATIONS** QUALADJUST is applied to neighbour nodes and all nodes learned from NetRom broadcasts. It is NOT applied to nodes learned via INP3 because they have no quality to de-rate, and is not applied to nodes entered by a NODE ADD command or an entry in the XRNODES file. **CAVEATS** This is an experimental feature. Please use it with caution. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AUTOQUAL| AUTOQUAL(9) -- Automatic Route Quality. ]] \\ [[packet:xrouter:docs:MAN1#NODES| NODES(1) -- Display / Modify the Nodes table. ]] \\ [[packet:xrouter:docs:MAN1#QUALITY| QUALITY(1) -- Display / Set default quality for a port. ]] \\ [[packet:xrouter:docs:MAN8#XRNODES| XRNODES(8) -- Routes / Nodes Recovery File. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== QUALITY ===== QUALITY(7) XROUTER REFERENCE MANUAL 25/9/2023 **NAME** QUALITY -- Default NetRom Quality. **SYNOPSIS** QUALITY=n (where n is 0 to 255) **DESCRIPTION** QUALITY is an optional PORT directive used in XROUTER.CFG. It specifies the default quality for nodes whose broadcasts are received on the port (default=10). The value can be changed during run-time using the command of the same name. Setting QUALITY to 0 disables all NetRom L3/4 activity on the port, e.g. on user access frequencies. **EXAMPLE** QUALITY=30 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#QUALITY| QUALITY(1) -- Display / Set default Quality.]] \\ [[packet:xrouter:docs:MAN7#QUALADJ| QUALADJ(7) -- NetRom Quality Manipulation.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RADIO ===== RADIO(7) XROUTER REFERENCE MANUAL 21/9/2023 **NAME** RADIO -- Radio control definition block. **SYNOPSIS** RADIO=n (where n is a number between 1 and 5) **DESCRIPTION** RADIO is an optional directive used in XROUTER.CFG. If present in the "global" section, it begins a "radio control" block, which is used, along with the RADIO command, to control an attached radio. If present within an INTERFACE definition block, RADIO specifies which previously defined radio block is associated with the interface. RADIO definition blocks start with RADIO=n, contain a number of other directives, and end with ENDRADIO. They *must* be defined BEFORE any INTERFACEs that refer to them. **OPTIONS** The following directives are accepted within a RADIO block: NAME Specifies a name for this radio, e.g. "HF Rig". Maximum 63 characters, spaces allowed. TYPE Radio type: 1=Custom, 2=Icom ICR7000, 3=Icom PCR1000, 4=Yaesu Ft100, 5=Flex, 6=Hamlib. ICR7000 is a receiver which uses Icom CI-V interface. PCR1000 is a receiver which uses serial TTY control FT100 is a transceiver using Yaesu CAT interface FLEX is for Flexradio HAMLIB lets XR talk to Hamlib which controls the rig. Additional radio types can be added upon request. COM Specifies how XRouter communicates with the rig. For most types this is via a TTY, for example "COM=/dev/ttyUSB0". But for Hamlib it should specify the IP address and port used by Hamlib, for example "COM=127.0.0.1:3900". BAUDS Baud rate for the TTY (not needed for Hamlib). Defaults to 9600 (1200 for ICR7000). STOPBITS Number of "stop" bits on the serial data (default=2) (Not required for Hamlib) FREQUENCY Initial receive frequency in Hz, e.g. "144925000" OFFSET "Tuning Offset" in PPM between requested frequency and actual frequency, in case the rig's reference crytal has drifted. MODE Initial modulation mode: (Not all radios support all types) "USB", "LSB", "SSB", "DSB" "CW", "CWR", "RTTY", "RTTYR", "AM", "FM", "NFM", "WFM", "AMS", "PKTLSB", "PKTUSB", "PKTFM", "ECSSUSB", "ECSSLSB", "FAX", "SAM", "SAL", "SAH", "DATA, "DIG" SQUELCH Initial Squelch level (0-255) 0=fully open, 255=fully closed VOLUME Initial Audio volume (0-255) 0=min, 255=max TXFREQ Initial Transmission frequency in Hz (if different to receive) PTTMETHOD How the PTT is controlled: 0 Undefined 1 Serial RTS 2 Serial DTR 3 CM108 HID 4 CAT, CI5, FLEX etc 5 GPIO pin (Pi only) RXAUDIODEV Device for inputting audio from radio to node, for example: "RXAUDIODEV=/dev/dsp2" Some of the values are "initial" values, that can be changed by the RADIO command during run-time, for example FREQUENCY, VOLUME, MODE etc. **EXAMPLE** Example for PCR1000 receiver controlled via /dev/ttyUSB0, defaulting to 9600,8,n.2 with VOIP audio input via /dev/dsp2 RADIO=1 NAME=PCR-1000 TYPE=3 COM=/dev/ttyUSB0 FREQUENCY=145.625 MODE=FMn VOLUME=80 SQUELCH=75 RXAUDIODEV=/dev/dsp2 ENDRADIO **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#RADIO| RADIO(1) -- Rig control commands]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main configuration file]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RESPTIME ===== RESPTIME(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** RESPTIME -- AX25 Delayed Ack Time. **SYNOPSIS** RESPTIME= **DESCRIPTION** RESPTIME is an optional PORT drectuive, used in XROUTER.CFG. It specifies the AX25 "T2" (delayed ack) time, i.e. the time to wait after receiving a frame before sending an ack, which allows multi-frame transmissions to be acknowledged with a single ack, increasing link efficiency. The value is in milliseconds, and the default is 1500. Resptime should be long enough for a link partner to transmit a full-sized information frame, i.e. approximately ((their_paclen * 10000) / RFbaudRate) millisecs, otherwise XRouter will send unnecessary ack frames. Too high a value will cause the link to be too "relaxed", whereas too low a value will cause too many acks. Both extremes reduce the link efficiency. The default RESPTIME of 1500 milliseconds is OK for 1200 baud with paclen=120, but 2200 would be more appropriate if their paclen was 256. At 9600 baud, or on AXUDP links, 200 ms is probably adequate. The value can be changed "on the fly" using the command of the same name. **EXAMPLE:** RESPTIME=2000 ; 2 seconds **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#FRACK| FRACK(7) -- Frame Acknowledgement Time.]] \\ [[packet:xrouter:docs:MAN1#RESPTIME| RESPTIME(1) -- Display / Set AX25 Delayed Ack Time.]] \\ [[packet:xrouter:docs:MAN7#PACLEN| PACLEN(7) -- Maximum Packet Length.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RETRIES ===== RETRIES(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** RETRIES -- AX25 Maximum Retry Count. **SYNOPSIS** RETRIES=n (where n is 0 to 100) **DESCRIPTION** RETRIES is a PORT directive used in XROUTER.CFG. It specifies the AX25 maximum consecutive connect / disconnect / resend attempts (default = 10). There is little point in setting retries more than 10, other than for test purposes. If you need so many retries, it's a useless link and you're just wasting everyone else's airtime. The higher you set this value, the longer users will have to wait to get a "failure with" for an unconnectable destination. RETRIES=0 means "try forever", and should be avoided except for testing. The value can be changed during run-time using the command of the same name. **EXAMPLE** RETRIES=5 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#RETRIES| RETRIES(1) -- Display / Set Maximum Retries]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RFBAUDS ===== RFBAUDS(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** RFBAUDS -- Radio Channel Baud Rate. **SYNOPSIS** RFBAUDS= **DESCRIPTION** RFBAUDS is an optional PORT directive used in XROUTER.CFG. It specifies the over-the-air baud rate (default = 1200). This parameter is used with "real" tnc's and YAM modems attached via RS232, because the RF baud rate is usually different to the RS232 baud rate. It helps XRouter make timing decisions (such as nodes broadcast inter-packet timing) and to report certain stats correctly. It is also reported to the node mapping server. **EXAMPLE** RFBAUDS=2400 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:MAN9#YAM| YAM(9) -- YAM ("Yet Another Modem") HDLC Modem.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RHPPORT ===== RHPPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** RHPPORT -- TCP Port for RHP Server. **SYNOPSIS** RHPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** RHPPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the RHP (Remote Host Protocol) server. If not present, the default is 9000. The RHP server provides a socket-like application interface to various layers within XRouter. **OPTIONS** If a single argument is supplied, e.g. "RHPPORT=80", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "RHPPORT=80 8080", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting RHPPORT to zero on a stack prevents TCP connections to the RHP server via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#RHP-SRV| RHP-SRV(9) -- Remote Host Protocol server. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== RLOGINPORT ===== RLOGINPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** RLOGINPORT -- TCP Port for Remote Login Service. **SYNOPSIS** RLOGINPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** RLOGINPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the RLOGIN (Rmote Login) service. If not present, the default is 513. RLOGIN is a "remote login" facility for full sysop access via secure links. **OPTIONS** If a single argument is supplied, e.g. "RLOGINPORT=513", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "RLOGINPORT=513 514", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting RLOGINPORT to zero on a stack prevents TCP connections to the RLOGIN service via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#RLOGIN| RLOGIN(9) -- Remote Login Service. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== ROWS ===== ROWS(7) XROUTER REFERENCE MANUAL 19/10/2023 **NAME** ROWS -- Set Display Height. **SYNOPSIS** ROWS=n (n = 25-60) **DESCRIPTION** ROWS is an optional configuration directive, used only in the "global" section of XROUTER.CFG. It sets the display height in rows or lines of text. The default display height for XRouter is 25 rows, which is a legacy from the 80x25 DOS days. With XR32 running in a Windows "command" window, this setting allows the use of retro "full screen" mode, using the ALT-RETURN key combination. However, you may find that with just 25 lines, the status windows are too cramped, and console pages are too short for comfort, in which case you may expand the display by using the ROWS directive at the start of XROUTER.CFG, before any CONSOLE definitions. For instance, for a 50-row display use ROWS=50. Depending on your screen resolution and "Command window" (or Linux "terminal") settings you may be able to use 60 or more rows, however some display adaptors won't allow you to go much beyond 40 rows. It is better to start with a low figure and increase it 10 at a time until you find the limit for your adaptor. Beyond the limit, the display will either break up or behave oddly. **CAVEATS** If you set ROWS more than 25, you cannot use "full screen" mode on Windows. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#COLS| COLS(7) -- Set Display Width. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== SESSLIMIT ===== SESSLIMIT(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** SESSLIMIT -- Maximum Simultaneous Connections on Port. **SYNOPSIS** SESSLIMIT=n (where n is 0 to 255) **DESCRIPTION** SESSLIMIT is an optional PORT directive used in XROUTER.CFG. It specifies the maximum simultaneous connections each user is allowed on the port. The default is 255, i.e. unlimited. This would typically be used to "choke" users who hog all the bandwidth on a port with too many connections. There is a global limit on the number of AX25 links, namely MAXLINKS (default=30), so on a multi-port node it is worth setting SESSLIMIT substantially lower than MAXLINKS. The user must however use a different SSID for each connection on any given PORT, which limits his maximum number of connections to 16. **EXAMPLE** SESSLIMIT=5 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#MAXLINKS| MAXLINKS(7) -- Global Maximum AX25 Connections.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#USERS| USERS(7) -- Maximum Users on Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== SLOTTIME ===== SLOTTIME(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** SLOTTIME -- CSMA Interval Time. **SYNOPSIS** SLOTTIME= **DESCRIPTION** SLOTTIME is an optional PORT directive used in XROUTER.CFG. It specifies the CSMA (Carrier Sense Multiple Access) interval time, used with PERSIST to make channel access decisions. The value is in milliseconds (default=100). If the channel is clear, the TNC (or SCC/YAM card) generates a random number which is then compared with PERSIST. If the random number is less than PERSIST, the TNC will wait for the SLOTTIME interval, then repeat the action, otherwise it will transmit immediately. This improves throughput by ensuring that everyone doesn't transmit as soon as the channel is clear, which would cause collisions and retries. The value can be changed "on the fly" using the SLOTTIME command. **EXAMPLE** SLOTTIME=100 ; 100 millisecs per slot **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#SLOTTIME| SLOTTIME(1) -- Display / Set CSMA Interval.]] \\ [[packet:xrouter:docs:MAN7#PERSIST| PERSIST(7) -- AX25 Probablity to Transmit.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== SOCKSPORT ===== SOCKSPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** SOCKSPORT -- TCP Port for SOCKS Proxy. **SYNOPSIS** SOCKSPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** SOCKSPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used by the SOCKS Proxy. If not present, the default is 1080. SOCKS is a circuit level proxy for applications, as an alternative to Network Address Transslation (NAT). **OPTIONS** If a single argument is supplied, e.g. "SOCKSPORT=1080", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "SOCKSPORT=1080 1090", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting SOCKSPORT to zero on a stack prevents TCP connections to the SOCKS proxy via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#SOCKS| SOCKS(9) -- About the SOCKS Proxy. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== SOFTDCD ===== SOFTDCD(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** SOFTDCD -- Software Data Carrier Detect. **SYNOPSIS** SOFTDCD=<0|1> **DESCRIPTION** SOFTDCD is an optional PORT directive used in XROUTER.CFG. It specifies whether or not software-derived DCD (Data Carrier Detect) is used insteaed of hardware DCD. It is used only by SCC cards, and defaults to 0 (off). **OPTIONS** If SOFTDCD=0 the "real" DCD generated by SCC card is used. If SOFTDCD=1 the real dcd is ignored, and the SCC driver uses the presence of HDLC data as a DCD indication. **CAVEATS** Using SOFTDCD=1 with an open squelch generates a *huge* interrupt loading, which may cause degradation of performance, depending on the PC type, so it is not recommended. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== SYSOP ===== SYSOP(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** SYSOP -- Description.. **SYNOPSIS** SYSOP=<0|1> **DESCRIPTION** SYSOP is an optional PORT directive, used in XROUTER.CFG. If you set SYSOP=1 on a PORT, anyone who connects on that port gets full sysop status without needing to answer a password challenge. This is intended ONLY FOR USE ON SECURE LINKS, such as RS232 or Ethernet, and the default is zero. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TELNETPORT ===== TELNETPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** TELNETPORT -- TCP Port for TELNET Access. **SYNOPSIS** TELNETPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** TELNETPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used for TELNET access to XRouter. If not present, the default is 23. **OPTIONS** If a single argument is supplied, e.g. "TELNETPORT=23", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "TELNETPORT=23 8023", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting TELNETPORT to zero on a stack prevents TELNET access via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#TELNET| TELNET(9) -- About TELNET Access. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TELPROXYPORT ===== TELPROXYPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** TELPROXYPORT -- TCP Port for Telnet Proxy. **SYNOPSIS** TELPROXYPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** TELPROXYPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used for Telnet proxy access to XRouter. If not present, the default is 2323. The Telnet proxy allows 100% binary connections not only to TCP/IP targets, but also to Netrom and AX25 targets. This would typically be used by a TCP/IP-only BBS to perform FBB compressed forwarding with netrom and ax25 targets. **OPTIONS** If a single argument is supplied, e.g. "TELPROXYPORT=2323", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "TELPROXYPORT=236 2323", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting TELPROXYPORT to zero on a stack prevents Telnet proxy access via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#TELPROXY| TELPROXY(9) -- About the Telnet Proxy. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TTYLINKPORT ===== TTYLINKPORT(7) XROUTER REFERENCE MANUAL 27/9/2023 **NAME** TTYLINKPORT -- TCP Port for TTYLINK Access. **SYNOPSIS** TTYLINKPORT=n1 [n2] (where n1 and n2 are 0 to 65535) **DESCRIPTION** TTYLINKPORT is an optional "global" directive used in XROUTER.CFG. If present, it specifies the TCP "service port" number used for TTYLINK (keyboard to keyboard chat) access to XRouter. If not present, the default is 87. TTYLINK is also available as NetRomX service 87. **OPTIONS** If a single argument is supplied, e.g. "TTYLINKPORT=23", it applies to whichever TCP/IP stack(s) XRouter is using. If TWO arguments are supplied, e.g. "TTYLINKPORT=87 8087", the first argument applies to the XRouter stack and the second to the host system's stack. The numbers must be separated by whitespace Setting TTYLINKPORT to zero on a stack prevents TTYLINK access via that stack. See TCP-PORTS(6) for more information on this and the caveat below. **CAVEATS** In order to use port numbers below 1024 on the Linux stack, XRouter must be run from a root account, or given the CAP_NET_BIND_SERVICE capability. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags. ]] \\ [[packet:xrouter:docs:MAN9#TTYLINK| TTYLINK(9) -- About TTYLINK. ]] \\ [[packet:xrouter:docs:MAN6#TCP-PORTS| TCP-PORTS(6) -- TCP Service Ports. ]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File. ]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TXDELAY ===== TXDELAY(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** TXDELAY -- Transmit Delay. **SYNOPSIS** TXDELAY= **DESCRIPTION** TXDELAY is an optional PORT directive used in XROUTER.CFG. It specifies the delay between transmitter activation and the start of the frame data in milliseconds (default=300). After turning the transmitter on, the TNC (or SCC / YAM card) waits for this interval before sending HDLC data. This allows the TX to stabilise, and the link partner's squelch to open. The value can be changed on the fly using the TXDELAY command, but please be ware that changes may take up to 5 minutes to take effect on KISS TNC's. **NOTE** Software TNC's such as "Direwolf" might complain that your TXDELAY setting is too long, but they have no knowledge of how long it takes the transmitter frequency to stabiise, nor how long it takes the link partnar's squelch to open, so you should ignore it and trust your own judgement! Start with a long TXDELAY, e.g. 500 millisecs, then gradually reduce it until the partner stops responding. That is the absolute minimum txdelay. Raise TXDELAY until the link becomes reliable again. Stupidly low TXDELAY is a common cause of erratic links! Don't forget that the radios may be inconsistent - they might be slower to respond when cold or hot, or when desensitised by other signals. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#TXDELAY| TXDELAY(1) -- Display / Set TX Delay.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#TXTAIL| TXTAIL(7) -- TX Tail Time]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TXPORT ===== TXPORT(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** TXPORT -- Port to Transmit On. **SYNOPSIS** TXPORT= **DESCRIPTION** TXPORT is an optional PORT directive used in XROUTER.CFG. It specifies the number of the PORT upon which outgoing frames should be transmitted. The default is 0, i.e. TX and RX on the same port. You would typically use this when several ports, with separate receivers, share a single transmitter. This parameter can be changed "on the fly", using the TXPORT command. **EXAMPLE** TXPORT=5 ; Transmit on port 5 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#TXPORT| TXPORT(1) -- Display / Set Port to Transmit On.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== TXTAIL ===== TXTAIL(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** TXTAIL -- Transmitter Turnoff Delay. **SYNOPSIS** TXTAIL= **DESCRIPTION** TXTAIL is an optional PORT directive used in XROUTER.CFG. It specifies the transmiter turnoff delay in milliseconds (default = 100). This is the interval, after sending a frame, for which the transmitter remains activated. It is intended to allow the CRC (Cyclic Redundancy Check) and closing flags to be sent. It has no meaning on non-radio ports. Due to PC timing inaccuracies, you should set this no lower than 100 for SCC cards! The value can be changed on the fly using the TXTAIL command, but changes may take up to 5 minutes to take effect on KISS ports. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#TXTAIL| TXTAIL(1) -- Display / Set TX Tail Time.]] \\ [[packet:xrouter:docs:MAN7#TXDELAY| TXDELAY(7) -- TX Activation Delay]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== UDPLOCAL ===== UDPLOCAL(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** UDPLOCAL -- Local UDP Port for Link. **SYNOPSIS** UDPLOCAL= **DESCRIPTION** UDPLOCAL is a PORT directive used in XROUTER.CFG for AXUDP ports only. It specifies the UDP port number for the local end of an AXUDP link. The default is 93. This number must match the link partner's UDPREMOTE, i.e. the destination service number in the frames from him to you. It is perfectly valid for all your PORTS to use the same UDPLOCAL. This reduces the number of "holes" (port forwards) you need to make in your firewall. The *only* reason ever to have more than one UDPLOCAL is when you have more than one AXUDP node sharing the same public IP address. Your link partners have no right to dictate this value! **EXAMPLE** UDPLOCAL=7388 **CAVEATS** If UDPLOCAL is less than 1024, and XRouter is using the Linux IP stack, XRouter needs to be granted the CAP_NET_BIND_SERVICE capability unless it is run from a root account. See CAPFLAGS for more information. **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25-over-UDP Tunnelling.]] \\ [[packet:xrouter:docs:MAN6#CAPFLAGS| CAPFLAGS(6) -- Capability Flags.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN1#UDPLOCAL| UDPLOCAL(1) -- Display / Set Local UDP Port.]] \\ [[packet:xrouter:docs:MAN7#UDPREMOTE| UDPREMOTE(7) -- Remote UDP Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== UDPREMOTE ===== UDPREMOTE(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** UDPREMOTE -- Remote UDP Port for Link. **SYNOPSIS** UDPREMOTE= **DESCRIPTION** UDPREMOTE is a PORT directive used in XROUTER.CFG for AXUDP ports only. It specifies the UDP port number for the remote end of an AXUDP link, i.e. UDP destination number in the AXUDP frames from you to your link partner. It must match the link partner's UDPLOCAL, otherwise the link will not function. If not specified, UDPREMOTE defaults to 93. You have no right to dictate this value to your link partner. It is THEIR choice only (see UDPLOCAL). **EXAMPLE** UDPREMOTE=10093 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN9#AXUDP| AXUDP(9) -- AX25-over-UDP Tunnelling.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#UDPLOCAL| UDPLOCAL(7) -- Local UDP Port.]] \\ [[packet:xrouter:docs:MAN1#UDPREMOTE| UDPREMOTE(1) -- Display / Set Remote UDP Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== UNPROTO ===== UNPROTO(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** UNPROTO -- Path for Unproto Broadcasts. **SYNOPSIS** UNPROTO [,digicall,digicall,...] **DESCRIPTION** UNPROTO is an optional PORT directive used in XROUTER.CFG. It specifies a destination callsign plus optional digipeater path used for unproto broadcasts from applications onto the port. The callsigns should be separated the with commas. **EXAMPLE** UNPROTO=CQ,G6YAK **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#UNPROTO| UNPROTO(1) -- Display / Set Path for Unproto Broadcasts.]] \\ [[packet:xrouter:docs:MAN7#APRSPATH| APRSPATH(7) -- Default Digipeater Path for APRS.]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== USERS ===== USERS(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** USERS -- Maximum Users on Port. **SYNOPSIS** USERS=<0-255> **DESCRIPTION** USERS is an optional PORT directive used in XROUTER.CFG. It specifies the maximum no. of simultaneous AX25 L2 connections allowed on the port. The default is 255 which means "no limit". **EXAMPLE** USERS=9 **SEE ALSO:** \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN7#SESSLIMIT| SESSLIMIT(7) -- Maximum Simultaneous Connections on Port.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== VALIDCALLS ===== VALIDCALLS(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** VALIDCALLS -- AX25 Whitelist. **SYNOPSIS** VALIDCALLS=[,calsign,callsign...] **DESCRIPTION** VALIDCALLS is an optional PORT directive used in XROUTER.CFG. It specifies a list of callsigns who are allowed to make AX25 connections to the port, all other callsigns being excluded. It is therefore the opposite of EXCLUDE, and is typically used to prevent users or unwanted nodes from connecting to link-only ports. Callsigns must be separated by commas, with no spaces. **EXAMPLE** VALIDCALLS=G6YAK,G6AMU ; Accept *only* these callsigns **SEE ALSO:** \\ [[packet:xrouter:docs:MAN7#EXCLUDE| EXCLUDE(7) -- AX25 L2 Exclusions (Budlist).]] \\ [[packet:xrouter:docs:MAN6#PORTS| PORTS(6) -- Ports in XRouter.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== WALLFLAGS ===== WALLFLAGS(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** WALLFLAGS -- Options for Message Wall / Guestbook. **SYNOPSIS** WALLFLAGS=n (where 0 <= n <= 15) **DESCRIPTION** WALLFLAGS is an optional directive used only in XROUTER.CFG. It controls whether or not the message "wall" is enabled, whether or not the sysop is notified of new "likes" and replies, and whether or not the activity is published via the MQTT broker. If WALLFLAGS is omitted, the wall is disabled. **OPTIONS** The argument to WALLFLAGS is a decimal number, which is the sum of the desired options from the following list: 1 - Enable wall 2 - Notify sysop (via PMS) of new posts / replies 4 - Publish new posts / replies via MQTT **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#WALL| WALL(1) -- Access Message Wall / Guestbook.]] \\ [[packet:xrouter:docs:MAN9#MQTT-SRV| MQTT-SRV(9) -- MQTT Server / Broker]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== WARNCOLOR ===== WARNCOLOR(7) XROUTER REFERENCE MANUAL 26/10/2023 **NAME** WARNCOLOR -- Colour For Warnings and Errors. **SYNOPSIS** WARNCOLOR= **DESCRIPTION** WARNCOLOR is an optional directive that can be used both in the "global" section of XROUTER.CFG, and within CONSOLE definition blocks. It specifies the colour used by XRouter for warning and error messages, such as "Invalid port", "Syntax error", "System busy", and so on. If used in the "global" section of XROUTER.CFG, the setting is inherited by all CONSOLEs subsequently defined. If used within a CONSOLE definition block, it applies only to that console, overriding any inherited setting. The default WARNCOLOR is CERISE. Default colours have been carefully chosen for good visibility against a BLACK background. **OPTIONS** should be one of the 16 colour names described in COLOURS(6), but please note that some colour combinations have very poor visibility. In general, the lighter the background colour, the smaller the choice of foreground colours that will work with it. **EXAMPLE** WARNCOLOR=PINK **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#ANSI| ANSI(1) -- Enquire/set ANSI colour mode]] \\ [[packet:xrouter:docs:MAN6#COLOURS| COLOURS(6) -- XRouter Display Colours.]] \\ [[packet:xrouter:docs:MAN6#CONSOLES| CONSOLES(6) -- About XRouter Consoles.]] \\ [[packet:xrouter:docs:MAN7#ACTIONCOLOR| ACTIONCOLOR(7) -- Colour For XRouter Actions and Events.]] \\ [[packet:xrouter:docs:MAN7#CAPTIONCOLOR| CAPTIONCOLOR(7) -- Colour For Captions and Headings.]] \\ [[packet:xrouter:docs:MAN7#PROMPTCOLOR| PROMPTCOLOR(7) -- Colour For XRouter Prompts.]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== WXFILE ===== WXFILE(7) XROUTER REFERENCE MANUAL 26/9/2023 **NAME** WXFILE -- Specify Weather Import File. **SYNOPSIS** WXFILE=[path/] **DESCRIPTION** WXFILE is an optional "global" directive used in XROUTER.XFG. It specifies the filename (and if necessary the path to it), of a file that contains weather data in WXNOW, CUMULUS or ": " format, generated by home weather stations or weather applications. Once per minute, if the specified file exists, XRouter reads its contents into its weather database, making it available to the WX command and the NetRomX Weather service.. **EXAMPLE** WXFILE=/etc/wxnow.txt **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#WX| WX(1) -- Obtain Weather Information.]] \\ [[packet:xrouter:docs:MAN9#WX-SVC| WX-SVC(9) -- NetRomX Weather Service]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== WXMAXAGE ===== WXMAXAGE(7) XROUTER REFERENCE MANUAL 31/10/2024 **NAME** WXMAXAGE -- Specify Maximum Age of a Weather Record. **SYNOPSIS** WXMAXAGE= **DESCRIPTION** WXMAXAGE is an optional "global" directive used in XROUTER.XFG. It specifies the maximum lifetime of a weather record, in seconds since the time of observation. Records older than the maximum lifetime are purged. If not specified, the default lifetime is 21600 seconds, i.e. 6 hours. **EXAMPLE** WXMAXAGE=3600 - Sets max lifetime to 1 hour **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#WX| WX(1) -- Obtain Weather Information.]] \\ [[packet:xrouter:docs:MAN9#WX-SVC| WX-SVC(9) -- NetRomX Weather Service]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ---- ===== WXMAXRECS ===== WXMAXRECS(7) XROUTER REFERENCE MANUAL 31/10/2024 **NAME** WXMAXRECS -- Specify Maximum Number of Weather Records. **SYNOPSIS** WXMAXRECS=<0-255> **DESCRIPTION** WXMAXRECS is an optional "global" directive used in XROUTER.XFG. It specifies the maximum number of weather records to retain, one for each weather "station" (source). Records are stored in order of distance from XRouter, i.e. only the records from the WXMAXRECS closest weather stations are retained. If the list is full, new reports from stations further than the most distant one are ignored. If a new report arrives from a closer station, the most distant one is deleted. If not specified, the default value is 5. **EXAMPLE** WXMAXRECS=25 - Store a maxium of 25 weather records **SEE ALSO:** \\ [[packet:xrouter:docs:MAN1#WX| WX(1) -- Obtain Weather Information.]] \\ [[packet:xrouter:docs:MAN9#WX-SVC| WX-SVC(9) -- NetRomX Weather Service]] \\ [[packet:xrouter:docs:MAN8#XROUTER.CFG| XROUTER.CFG(8) -- Main Configuration File.]] \\ [[packet:xrouter:docs:|< Back to Index]] ----