packet:xrpi:manpages:section7
Differences
This shows you the differences between two versions of the page.
| packet:xrpi:manpages:section7 [2025/04/19 11:53] – created m0mzf | packet:xrpi:manpages:section7 [2025/04/19 18:00] (current) – removed m0mzf | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =======Section 7 - Configuration Directives======= | ||
| - | =====ACTIONCOLOR.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ACTIONCOLOR -- Colour For XRouter Actions and Events. | ||
| - | </ | ||
| - | ACTIONCOLOR=< | ||
| - | |||
| - | </ | ||
| - | ACTIONCOLOR is an optional directive that can be used both | ||
| - | in the " | ||
| - | definition blocks. | ||
| - | |||
| - | It specifies the colour used by XRouter for reporting | ||
| - | " | ||
| - | "G9YAK is yelling" | ||
| - | |||
| - | If used in the " | ||
| - | 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. | ||
| - | been carefully chosen for good visibility against a BLACK | ||
| - | background. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | ACTIONCOLOR=PINK | ||
| - | |||
| - | </ | ||
| - | ANSI(1) | ||
| - | COLOURS(6) | ||
| - | CONSOLES(6) | ||
| - | CAPTIONCOLOR(7) -- Colour For Captions and Headings. | ||
| - | PROMPTCOLOR(7) | ||
| - | WARNCOLOR(7) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====AGWPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | AGWPORT -- TCP Port for AGW Emulator. | ||
| - | |||
| - | </ | ||
| - | AGWPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | AGWPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | AGWHOST(6) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ALTITUDE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | ALTITUDE -- Site altitude above mean sea level. | ||
| - | |||
| - | </ | ||
| - | ALTITUDE=< | ||
| - | |||
| - | </ | ||
| - | ALTITUDE is an optional directive that may be used anywhere | ||
| - | in the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | ALTITUDE=46 | ||
| - | |||
| - | </ | ||
| - | HAAT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====APPLMASK.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | APPLMASK -- Application Connectivity Mask. | ||
| - | |||
| - | </ | ||
| - | 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, " | ||
| - | 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. | ||
| - | 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 " | ||
| - | will only allow direct connections to applications 1 and 4 on | ||
| - | that port, providing those applications have either an | ||
| - | APPLCALL or an APPLALIAS. | ||
| - | |||
| - | </ | ||
| - | APPLMASK(1) | ||
| - | PORTS(6) | ||
| - | APPLS(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | | ||
| - | </ | ||
| - | ---- | ||
| - | =====APRSPATH.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | APRSPATH -- Default Digipeater Path for APRS. | ||
| - | |||
| - | </ | ||
| - | APRSPATH=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | APRSPATH=RELAY, | ||
| - | |||
| - | </ | ||
| - | AMSG(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====APRSPORT.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | APRSPORT -- TCP Port for APRS Server. | ||
| - | |||
| - | </ | ||
| - | APRSPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | APRSPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | APRS-SRV(9) | ||
| - | APRS-SVC(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====AUDIODEVICE.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | AUDIODEVICE -- Specify audio device name. | ||
| - | |||
| - | </ | ||
| - | AUDIODEVICE=< | ||
| - | |||
| - | </ | ||
| - | Used only in XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | installed. The XRouter philosophy is to avoid dependencies | ||
| - | where possible. | ||
| - | |||
| - | Having said that, XRouter can be supplied in " | ||
| - | versions if required. | ||
| - | |||
| - | </ | ||
| - | # Audio device for sound output: | ||
| - | # Default OSS device is /dev/dsp (/dev/audio on Rasp pi) | ||
| - | # | ||
| - | AUDIODEVICE=/ | ||
| - | # | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | follows: | ||
| - | |||
| - | " | ||
| - | |||
| - | </ | ||
| - | AUDIO(9) | ||
| - | BELL(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BCAST.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | BCAST -- Destinations for UI Broadcasting. | ||
| - | |||
| - | </ | ||
| - | BCAST=< | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | 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! | ||
| - | | ||
| - | </ | ||
| - | The destination addresses must be separated by commas and | ||
| - | there must be no spaces in the list. | ||
| - | |||
| - | </ | ||
| - | BCAST=MAIL, | ||
| - | |||
| - | </ | ||
| - | BCAST(1) | ||
| - | BCFROM(7) | ||
| - | BCAST(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BCFROM.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | BCFROM -- Approved UI Broadcasters. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | 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" | ||
| - | |||
| - | 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). | ||
| - | |||
| - | </ | ||
| - | The argument to BCFROM is a single callsign, or a comma | ||
| - | separated list of callsigns. There must be no spaces in the | ||
| - | list. | ||
| - | |||
| - | </ | ||
| - | BCFROM=GB7PZT, | ||
| - | |||
| - | </ | ||
| - | BCAST(7) | ||
| - | BCAST(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BLEVEL.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BLEVEL -- Netrom Budlist de-rate level. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | BLEVEL is an optional global XROUTER.CFG directive. It sets | ||
| - | the L3 " | ||
| - | L3EXCLUDE. The default is 0 (allow no packets). | ||
| - | |||
| - | This allows trafic from " | ||
| - | 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' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | A command of the same name can be used at runtime. | ||
| - | |||
| - | </ | ||
| - | BLEVEL(1) | ||
| - | L3EXCLUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BLOGFLAGS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | BLOGFLAGS -- Options For Sysop' | ||
| - | |||
| - | </ | ||
| - | BLOGFLAGS=n (where 0 <= n <= 15) | ||
| - | |||
| - | </ | ||
| - | BLOGFLAGS is an optional directive used only in XROUTER.CFG. | ||
| - | |||
| - | It controls whether or not the sysop' | ||
| - | whether or not the sysop is notified of new " | ||
| - | replies, and whether or not the activity is published via the | ||
| - | MQTT broker. | ||
| - | |||
| - | If BLOGFLAGS is omitted, the blog is disabled. | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 8 - Publish new posts / replies via MQTT | ||
| - | |||
| - | </ | ||
| - | BLOG(1) | ||
| - | MQTT-SRV(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BOOTWIN.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | BOOTWIN -- Window to display after bootup. | ||
| - | |||
| - | </ | ||
| - | BOOTWIN=n (where n is 1 to 12 inclusive) | ||
| - | |||
| - | </ | ||
| - | BOOTWIN is an optional directive that can be used anywhere in | ||
| - | the " | ||
| - | 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 " | ||
| - | |||
| - | Even if BOOTWIN is specified, if MON ON is used in | ||
| - | BOOTCMDS.SYS, | ||
| - | | ||
| - | The window numbers in v503 are as follows. Note that the | ||
| - | " | ||
| - | is specified at bootup: | ||
| - | |||
| - | 1 Sysop chat | ||
| - | 2 Chat monitor | ||
| - | 3 | ||
| - | 4 Nodes monitor | ||
| - | 5 | ||
| - | 6 | ||
| - | 7 | ||
| - | 8 | ||
| - | 9 | ||
| - | 10 Console 3 (if present) | ||
| - | 11 Console 4 (if present) | ||
| - | 12 Console 5 (if present) | ||
| - | |||
| - | </ | ||
| - | BOOTCMDS.SYS(8) -- Commands executed at boot up | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CAPTIONCOLOR.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CAPTIONCOLOR -- Colour For Captions and Headings. | ||
| - | |||
| - | </ | ||
| - | CAPTIONCOLOR=< | ||
| - | |||
| - | </ | ||
| - | CAPTIONCOLOR is an optional directive that can be used both | ||
| - | in the " | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPTIONCOLOR=CYAN | ||
| - | |||
| - | </ | ||
| - | ANSI(1) | ||
| - | COLOURS(6) | ||
| - | CONSOLES(6) | ||
| - | ACTIONCOLOR(7) | ||
| - | PROMPTCOLOR(7) | ||
| - | WARNCOLOR(7) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CFLAGS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CFLAGS -- Connection Control Flags. | ||
| - | |||
| - | </ | ||
| - | CFLAGS=n (n = 0 - 255) | ||
| - | |||
| - | </ | ||
| - | Used in PORT configuration blocks within XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | Add together the decimal values of the desired options from | ||
| - | this list: | ||
| - | |||
| - | Bit Dec | ||
| - | | ||
| - | 0 | ||
| - | 1 | ||
| - | 2 | ||
| - | 3 | ||
| - | 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, | ||
| - | even if users are prevented from downlinking. | ||
| - | |||
| - | Bit 3 was provided to keep the Luddites happy, but its use is | ||
| - | strongly deprecated. | ||
| - | 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. | ||
| - | L3RTT may also be suppressed if a route' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CFLAGS=2 | ||
| - | CFLAGS=5 | ||
| - | | ||
| - | </ | ||
| - | xrouter.cfg | ||
| - | |||
| - | </ | ||
| - | CFLAGS(1) | ||
| - | L2FRAG(9) | ||
| - | L3RTT(9) | ||
| - | FEC(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHANNEL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CHANNEL -- Channel to Use on Interface. | ||
| - | |||
| - | </ | ||
| - | CHANNEL=< | ||
| - | |||
| - | </ | ||
| - | CHANNEL is an optional PORT configuration directive. | ||
| - | |||
| - | If present, it specifies the " | ||
| - | channel interface. | ||
| - | |||
| - | It is required only on certain types of interface, e.g. | ||
| - | KISS. Not required on AXIP, AXUDP, or AXTCP interfaces. | ||
| - | |||
| - | </ | ||
| - | The argument to CHANNEL is a letter between A and P | ||
| - | | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | IFACES(6) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHATALIAS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CHATALIAS -- Alias for Chat Server. | ||
| - | |||
| - | </ | ||
| - | CHATALIAS=< | ||
| - | |||
| - | </ | ||
| - | CHATALIAS is a directive that can be used in XROUTER.CFG, | ||
| - | both " | ||
| - | |||
| - | It specifies an " | ||
| - | " | ||
| - | Chat). This can be used interchangeably with the CHATCALL; | ||
| - | i.e. the chat server will respond to either. | ||
| - | |||
| - | The < | ||
| - | and numbers. It is suggested that it should end with " | ||
| - | 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 " | ||
| - | used for AX25, NetRom and TCP operations. This is also the | ||
| - | chat server' | ||
| - | |||
| - | Any PORTs declared further down XROUTER.CFG " | ||
| - | 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 " | ||
| - | |||
| - | </ | ||
| - | CHATALIAS=IOWCHT | ||
| - | |||
| - | </ | ||
| - | Omitting the global CHATALIAS, or setting it IDENTICAL to | ||
| - | NODEALIAS disables chat server connectivity, | ||
| - | can still be used " | ||
| - | |||
| - | </ | ||
| - | CHAT(1) | ||
| - | CHAT-SRV(9) | ||
| - | CHATCALL(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHATCALL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CHATCALL -- Callsign for Chat Server. | ||
| - | |||
| - | </ | ||
| - | CHATCALL=< | ||
| - | |||
| - | </ | ||
| - | CHATCALL is a directive that can be used in XROUTER.CFG, | ||
| - | both " | ||
| - | |||
| - | 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 " | ||
| - | 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 " | ||
| - | 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 " | ||
| - | |||
| - | </ | ||
| - | CHATCALL=G8PZT-8 | ||
| - | |||
| - | </ | ||
| - | Omitting the global CHATCALL, or setting it IDENTICAL to | ||
| - | NODECALL (including the SSID) disables chat server | ||
| - | connectivity, | ||
| - | via the CHAT command. | ||
| - | |||
| - | </ | ||
| - | CHAT(1) | ||
| - | CHAT-SRV(9) | ||
| - | CHATALIAS(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHATPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CHATPORT -- TCP Port for CHAT Server. | ||
| - | |||
| - | </ | ||
| - | CHATPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | CHATPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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/ | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | CHAT-SRV(9) | ||
| - | CHAT-SVC(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====COLS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | COLS -- Set Display Width (deprecated). | ||
| - | |||
| - | </ | ||
| - | COLS=n (n = 40-120) | ||
| - | |||
| - | </ | ||
| - | COLS is an optional configuration directive, used only in the | ||
| - | " | ||
| - | 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 " | ||
| - | retro "full screen" | ||
| - | 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, | ||
| - | example, for a 90-column display use COLS=90. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | ROWS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CONSOLELANG.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CONSOLELANG -- Default Language. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | 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 | ||
| - | |||
| - | < | ||
| - | |||
| - | 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.. | ||
| - | |||
| - | </ | ||
| - | CONSOLELANG=2 -- Sets console language to SPANISH | ||
| - | |||
| - | </ | ||
| - | CONSOLES(6) | ||
| - | DEFAULTLANG(7) -- Default language | ||
| - | LANGS.SYS(8) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CONTACT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CONTACT -- Sysop' | ||
| - | |||
| - | </ | ||
| - | CONTACT=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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 " | ||
| - | section of XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | [email protected] | ||
| - | CONTACT=www.wmpkt.org/ | ||
| - | CONTACT=PO Box 43, Dudley,West Midlands | ||
| - | |||
| - | </ | ||
| - | MAPCOMMENT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CTEXT.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CTEXT -- Set " | ||
| - | |||
| - | </ | ||
| - | CTEXT | ||
| - | < | ||
| - | *** | ||
| - | CTEXT=< | ||
| - | |||
| - | </ | ||
| - | The CTEXT directive, used in XROUTER.CFG, | ||
| - | " | ||
| - | can be sent to a caller when they connect to XRouter. | ||
| - | |||
| - | The directive has two possible forms, one for specifying the | ||
| - | " | ||
| - | |||
| - | 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 | ||
| - | " | ||
| - | |||
| - | 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: | ||
| - | |||
| - | | ||
| - | |||
| - | 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 < | ||
| - | contents of that file are read " | ||
| - | 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 " | ||
| - | " | ||
| - | directory. If it is a fully qualified path starting with " | ||
| - | or "/", | ||
| - | so long as XRouter is allowed to access it. For example, | ||
| - | using the CTEXT command: | ||
| - | |||
| - | CTEXT ctext-news.txt | ||
| - | CTEXT / | ||
| - | |||
| - | The CTEXT *command* allows the texts to be changed "on the | ||
| - | fly". | ||
| - | |||
| - | </ | ||
| - | CTEXT(1) | ||
| - | CTFLAGS(1) | ||
| - | CTFLAGS(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CTFLAGS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CTFLAGS -- Connection Text Control Flags. | ||
| - | |||
| - | </ | ||
| - | CTFLAGS=n (where n is 0-15) | ||
| - | |||
| - | </ | ||
| - | The CTFLAGS directive, used in XROUTER.CFG, | ||
| - | callers are sent a " | ||
| - | XRouter. | ||
| - | |||
| - | If CTFLAGS is used in the GLOBAL section of XROUTER.CFG, | ||
| - | value is " | ||
| - | 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). | ||
| - | |||
| - | </ | ||
| - | The CTFLAGS *command* allows the texts to be changed "on the | ||
| - | fly". | ||
| - | |||
| - | </ | ||
| - | CTEXT(1) | ||
| - | CTEXT(7) | ||
| - | CTFLAGS(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CWID.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CWID -- Morse Code Identification. | ||
| - | |||
| - | </ | ||
| - | CWID=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | The < | ||
| - | case alphanumeric characters and forward slash (/) are | ||
| - | acceptable. | ||
| - | |||
| - | </ | ||
| - | CWID=GB7PZT | ||
| - | CWID=G8PZT/ | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DEFAULTLANG.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DEFAULTLANG -- Default Language. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | 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 | ||
| - | |||
| - | < | ||
| - | |||
| - | 0 - English | ||
| - | 1 - French | ||
| - | 2 - Spanish | ||
| - | 3 - German | ||
| - | 4 - Dutch | ||
| - | |||
| - | </ | ||
| - | DEFAULTLANG=1 -- Sets default language to FRENCH | ||
| - | |||
| - | </ | ||
| - | CONSOLELANG(7) -- Console language | ||
| - | LANGS.SYS(8) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DHCP.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | DHCP -- Obtain Port IP Using DHCP. | ||
| - | |||
| - | </ | ||
| - | DHCP=n (where n is 0 or 1) | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | DHCP(1) | ||
| - | DHCP(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DIGIFLAG.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG -- Digipeating Options. | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG=n (where n is a number from 0 to 1023) | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG is an optional PORT configuraton directive which | ||
| - | controls digipeating on that port. (0=none, default=7). | ||
| - | |||
| - | </ | ||
| - | Options are enabled by adding together the following numbers: | ||
| - | |||
| - | Value Option | ||
| - | --------------------------------------------------- | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | 16 | ||
| - | 32 Allow APRS 3rd party digi via L4. | ||
| - | 64 Allow digipeating to Internet (IGate). | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG=5 | ||
| - | |||
| - | </ | ||
| - | UITRACE and UIFLOOD are two special addresses that are | ||
| - | suffixed with pseudo-SSID' | ||
| - | 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 " | ||
| - | UIFLOOD address have their SSIDs decremented, | ||
| - | doesn' | ||
| - | |||
| - | For the sake of consistency with UI-View, UITRACE defaults | ||
| - | to " | ||
| - | defaults to WIDE, giving WIDEn-n digipeating. | ||
| - | |||
| - | However, according to the APRS "New Paradigm", | ||
| - | and WIDE are deprecated, UITRACE should be set to " | ||
| - | and UIFLOOD should be set to a " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG(1) | ||
| - | DIGIPORT(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DIGIPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | DIGIPORT -- Destination Port for Digipeated Frames. | ||
| - | |||
| - | </ | ||
| - | DIGIPORT=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | DIGIPORT=3 | ||
| - | |||
| - | </ | ||
| - | Frames may be digipeated to ONE port only, therefore | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | BCAST(9) | ||
| - | DIGIPORT(1) | ||
| - | DIGIFLAG(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DISCARDPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | DISCARDPORT -- TCP Port for DISCARD Server. | ||
| - | |||
| - | </ | ||
| - | DISCARDPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | DISCARDPORT is an optional GLOBAL configuration directive | ||
| - | used in XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | the DISCARD server. If not present, the default is 9. | ||
| - | |||
| - | The DISCARD server is a " | ||
| - | ignores (discards) everything sent to it. This is a useful | ||
| - | tool for testing connections, | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | DISC-SRV(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DXFLAGS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DXFLAGS -- DX List Control Flags. | ||
| - | |||
| - | </ | ||
| - | DXFLAGS=n (where n is a decimal number) | ||
| - | |||
| - | </ | ||
| - | 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/ | ||
| - | |||
| - | XRouter' | ||
| - | 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/ | ||
| - | *** | ||
| - | |||
| - | </ | ||
| - | If XRouter' | ||
| - | not start. | ||
| - | | ||
| - | </ | ||
| - | DX(1) -- Show Distant Stations | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DYNDNS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | DYNDNS -- Enable / Disable Dynamic DNS Update Client. | ||
| - | |||
| - | </ | ||
| - | DYNDNS=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | This directive most only be used on ONE port. It may crash | ||
| - | XRouter if you try to use it on more than one. | ||
| - | |||
| - | </ | ||
| - | DYNDNS(9) -- Dynamic DNS Update Client | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ECHOPORT.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ECHOPORT -- TCP Port for ECHO Server. | ||
| - | |||
| - | </ | ||
| - | ECHOPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | ECHOPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | by the ECHO server. If not present, the default is 7. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | ECHO(1) | ||
| - | ECHO-SRV(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====EXCLUDE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | EXCLUDE -- AX25 Blacklist. | ||
| - | |||
| - | </ | ||
| - | EXCLUDE=< | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | e.g. for preventing CB nodes from interconnecting with ham | ||
| - | radio nodes and vice versa. | ||
| - | |||
| - | If used within the " | ||
| - | exclusion is " | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | EXCLUDE=NOCALL, | ||
| - | |||
| - | </ | ||
| - | EXCLUDE(1) | ||
| - | L3EXCLUDE(7) | ||
| - | PORTS(6) | ||
| - | VALIDCALLS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FEC.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FEC -- Enable / disable Forward Error Correction. | ||
| - | |||
| - | </ | ||
| - | FEC=< | ||
| - | |||
| - | </ | ||
| - | 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" | ||
| - | in the port CFLAGS, to allow XRouter to fragment large L3 | ||
| - | frames which might otherwise exceed the reduced L2 Paclen. | ||
| - | |||
| - | </ | ||
| - | Frames containing FEC look like garbage to " | ||
| - | 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, | ||
| - | or possibly to corrupt node broadcasts or inaccurate APRS | ||
| - | positioning. Therefore FEC should not be used on a shared | ||
| - | channel. | ||
| - | |||
| - | </ | ||
| - | FEC(1) | ||
| - | CFLAGS(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FINGERPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FINGERPORT -- TCP Port for FINGER Server. | ||
| - | |||
| - | </ | ||
| - | FINGERPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | FINGERPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | port, other people' | ||
| - | connect to your server. This directive is provided ONLY for | ||
| - | controlling availablity on each stack. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | FING-SRV(9) | ||
| - | FING-SVC(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FRACK.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FRACK -- AX25 Frame Acknowledgement Time. | ||
| - | |||
| - | </ | ||
| - | FRACK=< | ||
| - | |||
| - | </ | ||
| - | FRACK is an optional PORT configuration directive, used in | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specified the AX25 " | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | FRACK=7000 ; 7 seconds | ||
| - | |||
| - | </ | ||
| - | FRACK(1) | ||
| - | MAXFRAME(7) | ||
| - | PACLEN(7) | ||
| - | PORTS(6) | ||
| - | RESPTIME(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FREQUENCY.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FREQUENCY -- Radio frequency used by RF port. | ||
| - | |||
| - | </ | ||
| - | FREQUENCY=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | FREQUENCY=144925000 -- 144.925 MHz | ||
| - | |||
| - | </ | ||
| - | RADIO(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FTPPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FTPPORT -- TCP Port for FTP Server. | ||
| - | |||
| - | </ | ||
| - | FTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | FTPPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | by the FTP server. If not present, the default is 21. | ||
| - | |||
| - | The FTP server is mainly intended for use by sysops. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | FTP-SRV(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FULLDUP.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FULLDUP -- Full Duplex. | ||
| - | |||
| - | </ | ||
| - | FULLDUP=< | ||
| - | |||
| - | </ | ||
| - | 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.. | ||
| - | |||
| - | </ | ||
| - | FULLDUP=1 | ||
| - | |||
| - | </ | ||
| - | FULLDUP(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====HAAT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | HAAT -- Antenna Height Above Average Terrain. | ||
| - | |||
| - | </ | ||
| - | HAAT=< | ||
| - | |||
| - | </ | ||
| - | HAAT is an optional directive that may be used anywhere in | ||
| - | the " | ||
| - | specifies the height of the antenna in metres above | ||
| - | " | ||
| - | estimate the radio range. | ||
| - | |||
| - | The value is obtained by calculating the average terrain | ||
| - | heights along a series of typically 10 or 20 " | ||
| - | 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 " | ||
| - | page, but it might eventually be sent to the mapping server. | ||
| - | |||
| - | </ | ||
| - | HAAT=-15 -- Antenna is 15 metres BELOW averaged terrain. | ||
| - | HAAT=12 | ||
| - | </ | ||
| - | Although HAAT is currently a " | ||
| - | acknowledged that some PORTS may have antennas at different | ||
| - | heights. Therefore a per-port override will be added in a | ||
| - | future version. | ||
| - | |||
| - | </ | ||
| - | ALTITUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====HTTPPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | HTTPPORT -- TCP Port for HTTP Server. | ||
| - | |||
| - | </ | ||
| - | HTTPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | HTTPPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | HTTP-SRV(9) | ||
| - | HTTP-SVC(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ID.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | ID -- Text to Identify Port. | ||
| - | |||
| - | </ | ||
| - | ID=< | ||
| - | |||
| - | </ | ||
| - | ID is a *mandatory* PORT directive used in XROUTER.CFG. | ||
| - | |||
| - | It specifies a text to identify the port on the " | ||
| - | display. It may contain spaces. Please make it informative. | ||
| - | |||
| - | </ | ||
| - | ID=144.825 MHz 9k6 TCP/IP users | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDINTERVAL.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IDINTERVAL -- Identification Beacon Interval. | ||
| - | |||
| - | </ | ||
| - | IDINTERVAL=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | IDPATH(7) | ||
| - | IDTEXT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDPATH.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | IDPATH -- Destination and Digipeater Path for ID beacons. | ||
| - | |||
| - | </ | ||
| - | IDPATH=< | ||
| - | |||
| - | </ | ||
| - | IDPATH is an optional PORT configuraton directive, used in | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the AX25 destination and optional | ||
| - | digipeater path for routine " | ||
| - | |||
| - | The default AX25 destination and path is " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | IDPATH=APRS, | ||
| - | |||
| - | </ | ||
| - | IDINTERVAL(7) | ||
| - | IDPATH(1) | ||
| - | IDTEXT(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDTEXT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | IDTEXT -- Identification Text. | ||
| - | |||
| - | </ | ||
| - | IDTEXT | ||
| - | < | ||
| - | *** } | ||
| - | IDTEXT=< | ||
| - | |||
| - | </ | ||
| - | IDTEXT is a configuration directive that can be used both | ||
| - | " | ||
| - | |||
| - | 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 " | ||
| - | is " | ||
| - | there is an IDTEXT in that PORT block. | ||
| - | |||
| - | If used in a PORT block, IDTEXT overrides the " | ||
| - | on that port only. | ||
| - | |||
| - | The < | ||
| - | cases. In the global case, IDTEXT begins a 3 line block, | ||
| - | with < | ||
| - | which is a BPQ legacy. In a PORT block, < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If the global < | ||
| - | 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 " | ||
| - | where dd represents degrees of latitude or longitude and | ||
| - | mm.mm represents minutes to two decimal places. " | ||
| - | may be replaced by " | ||
| - | recommended that you include your position, | ||
| - | |||
| - | </ | ||
| - | IDTEXT=!5224.00N/ | ||
| - | |||
| - | </ | ||
| - | IDINTERVAL(7) | ||
| - | IDPATH(7) | ||
| - | IDTEXT(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====INITSTR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | INITSTR -- Modem Initialisation String. | ||
| - | |||
| - | </ | ||
| - | INITSTR=< | ||
| - | |||
| - | </ | ||
| - | INITSTR is an optional PORT configuration directive used in | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | It specifies a "modem initialisation string", | ||
| - | string of characters sent to the modem when Xrouter is | ||
| - | started | ||
| - | |||
| - | </ | ||
| - | INITSTR=ATM0 | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====INTERFACENUM.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | INTERFACENUM -- Interface Number. | ||
| - | |||
| - | </ | ||
| - | INTERFACENUM=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PORT=7 | ||
| - | INTERFACENUM=5 | ||
| - | MTU=256 | ||
| - | ENDPORT | ||
| - | |||
| - | </ | ||
| - | IFACES(6) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====INTERLOCK.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | INTERLOCK -- Transmitter Interlock. | ||
| - | |||
| - | </ | ||
| - | INTERLOCK=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | INTERLOCK=4 | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IPADDRESS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | IPADDRESS -- Main or Port IP Address. | ||
| - | |||
| - | </ | ||
| - | IPADDRESS=< | ||
| - | |||
| - | </ | ||
| - | IPADDRESS is a directive used in XROUTER.CFG. It can be used | ||
| - | both " | ||
| - | |||
| - | If used in the " | ||
| - | 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 " | ||
| - | 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' | ||
| - | of course - you may wish to establish a private network on | ||
| - | another address range. | ||
| - | |||
| - | </ | ||
| - | IPADDRESS=44.131.91.5 | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | lead to death-loops. | ||
| - | |||
| - | </ | ||
| - | IP-STACKS(6) | ||
| - | IP-PRIMER(9) | ||
| - | NETMASK(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IPLINK.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | IPLINK -- Peer Address of a Link. | ||
| - | |||
| - | </ | ||
| - | IPLINK=< | ||
| - | |||
| - | </ | ||
| - | 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, " | ||
| - | in " | ||
| - | several links. In this mode, formal links are specified using | ||
| - | PEER commands, instead of the usual IPLINK/ | ||
| - | |||
| - | The IPLINK address can be changed during run-time using the | ||
| - | IPLINK *command*, but a run-time change to or from " | ||
| - | is not allowed. | ||
| - | |||
| - | </ | ||
| - | IPLINK=62.51.67.21 | ||
| - | IPLINK=gb7pzt.dyndns.org | ||
| - | |||
| - | </ | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | IPLINK(1) | ||
| - | PEER(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====KEEPALIVE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | KEEPALIVE -- AXUDP / AXIP Keepalive interval. | ||
| - | |||
| - | </ | ||
| - | KEEPALIVE=< | ||
| - | |||
| - | </ | ||
| - | 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" | ||
| - | CGNAT. | ||
| - | |||
| - | If KEEPALIVE is not specified, or is zero, no keep alive | ||
| - | packets are sent. | ||
| - | |||
| - | </ | ||
| - | KEEPALIVE=120 ; 2 minutes between keepalives | ||
| - | | ||
| - | </ | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | KEEPALIVE(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====L3EXCLUDE.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | L3EXCLUDE -- Level 3 Exclusion List. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | " | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | L3EXCLUDE=N3UOO-5, | ||
| - | |||
| - | </ | ||
| - | BLEVEL(1) | ||
| - | EXCLUDE(1) | ||
| - | BLEVEL(7) | ||
| - | EXCLUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====L4T3.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | L4T3 -- NetRom Layer 4 link check interval. | ||
| - | |||
| - | </ | ||
| - | L4T3=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | L4T3=600 -- Set link check interval to 10 minutes | ||
| - | |||
| - | </ | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LATITUDE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | LATITUDE -- Set XRouter' | ||
| - | |||
| - | </ | ||
| - | LATITUDE=n | ||
| - | |||
| - | </ | ||
| - | LATITUDE is an optional directive, used in XROUTER.CFG. If | ||
| - | present, it specifies XRouter' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | LATITUDE=52.4 | ||
| - | LATITUDE=-77.6342 -- A more precise southern latitude | ||
| - | |||
| - | </ | ||
| - | IDTEXT(1) | ||
| - | LOCATOR(7) | ||
| - | LONGITUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LEARN.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | LEARN -- Learn Unsolicited AX*P Peer Details. | ||
| - | |||
| - | </ | ||
| - | LEARN=1 | ||
| - | |||
| - | </ | ||
| - | LEARN is an optional directive that is used only in one type | ||
| - | of PORT block within XROUTER.CFG. | ||
| - | 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 " | ||
| - | attached to an INTERFACE which has " | ||
| - | such PORT can exist, but it can co-exist with " | ||
| - | and AXUDP ports, i.e. those which have IPLINK that is not | ||
| - | " | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | AD-HOC(9) | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | PEER(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LOCATOR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | LOCATOR -- Maidenhead QTH locator | ||
| - | |||
| - | </ | ||
| - | LOCATOR=LLddLL[dd] (where L is a letter and d is a digit) | ||
| - | |||
| - | </ | ||
| - | LOCATOR is an optional directive, used in XROUTER.CFG. If | ||
| - | present, it specifies XRouter' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | The argument to LOCATOR is a 6 or 8 character " | ||
| - | locator, e.g. " | ||
| - | |||
| - | </ | ||
| - | LOCATOR=IO82VJ | ||
| - | |||
| - | </ | ||
| - | IDTEXT(1) | ||
| - | LATITUDE(7) | ||
| - | LONGITUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LOG.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LOG -- Activity logging options | ||
| - | |||
| - | </ | ||
| - | LOG=n (where n is between 0 and 16383) | ||
| - | |||
| - | </ | ||
| - | The optional LOG directive, used in XROUTER.CFG, | ||
| - | the logging of XRouter activity, such as connections, | ||
| - | disconnections, | ||
| - | is omitted, or is set to 0, no logging is done. | ||
| - | |||
| - | </ | ||
| - | 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 | ||
| - | | ||
| - | | ||
| - | | ||
| - | 128 Log ODN activity. | ||
| - | 256 Log IDS activity to IDS log | ||
| - | 512 Generate PCAP file (use with caution) | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | LOG=7 -- Log session activity, using CRLF line endings | ||
| - | LOG=65 -- Log Netrom L3 only, using LF line endings | ||
| - | | ||
| - | </ | ||
| - | LOG(1) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====LONGITUDE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | LONGITUDE -- Set XRouter' | ||
| - | |||
| - | </ | ||
| - | LONGITUDE=n | ||
| - | |||
| - | </ | ||
| - | LONGITUDE is an optional directive, used in XROUTER.CFG. If | ||
| - | present, it specifies XRouter' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | LONGITUDE=2.5 | ||
| - | LONGITUDE=-5.205 -- A more precise western longitude | ||
| - | |||
| - | </ | ||
| - | IDTEXT(1) | ||
| - | LATITUDE(7) | ||
| - | LOCATOR(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAPCOMMENT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MAPCOMMENT -- Short text to display on map. | ||
| - | |||
| - | </ | ||
| - | MAPCOMMENT=< | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | 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 " | ||
| - | section of XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | MAPCOMMENT=XRLin (XRouter for x86 Linux) alpha test node | ||
| - | MAPCOMMENT=Beacon Hill, Trunking Only | ||
| - | |||
| - | </ | ||
| - | CONTACT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====MAPSERVADDR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MAPSERVADDR -- Hostname / IP address of mapping server. | ||
| - | |||
| - | </ | ||
| - | MAPSERVADDR=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | association between callsigns and IP addresses. The mapping | ||
| - | server displays nodes and links on a MAP. | ||
| - | |||
| - | </ | ||
| - | MAPCOMMENT(7) | ||
| - | MAPSERVPORT(7) -- TCP port of mapping server | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAPSERVPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MAPSERVPORT -- TCP port of mapping server. | ||
| - | |||
| - | </ | ||
| - | MAPSERVPORT=n (where n is between 0 and 65535) | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MAPSERVADDR(7) -- Address of mapping server | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAXFRAME.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MAXFRAME -- Maximum Unacked AX25 Frames. | ||
| - | |||
| - | </ | ||
| - | MAXFRAME=n (where n is in the range 1 to 63) | ||
| - | |||
| - | </ | ||
| - | MAXFRAME is an optional PORT configuration directive used in | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | It specifies the AX25 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MAXFRAME=4 | ||
| - | |||
| - | </ | ||
| - | MAXFRAME(1) | ||
| - | PACLEN(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAXHOPS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MAXHOPS -- Set Hopcount Horizon. | ||
| - | |||
| - | </ | ||
| - | MAXHOPS=n (n = 0-30) | ||
| - | |||
| - | </ | ||
| - | Used only in XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | MAXHOPS is a global and PORT configuration keyword used in | ||
| - | XROUTER.CFG, | ||
| - | 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. | ||
| - | effect on data received via conventional NetRom broadcasts. | ||
| - | |||
| - | MAXHOPS would typically be used to limit the "hop horizon" | ||
| - | 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 | ||
| - | " | ||
| - | routes. | ||
| - | 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: | ||
| - | section of XROUTER.CFG, | ||
| - | ports, overriding the default of 30. If used in a PORT | ||
| - | configuration block, it overrides the global default. | ||
| - | new routes inherit this value. | ||
| - | overridden for individual routes using by " | ||
| - | route at the end of XROUTER.CFG, | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | beyond your chosen hop limit into the nodes table and keep | ||
| - | them refreshed. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | INP3(9) | ||
| - | MAXTT(7) | ||
| - | MINQUAL(1) | ||
| - | QUALITY(1) | ||
| - | ROUTES(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAXLINKS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MAXLINKS -- Maximum Simultaneous AX25 L2 links. | ||
| - | |||
| - | </ | ||
| - | MAXLINKS=n (n=0-65535) | ||
| - | |||
| - | </ | ||
| - | MAXLINKS is an optional directive used in the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MAXLINKS=50 | ||
| - | |||
| - | </ | ||
| - | SESSLIMIT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAXTT.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MAXTT -- Maximum Trip Time. | ||
| - | |||
| - | </ | ||
| - | MAXTT=n (n = 0-60000) | ||
| - | |||
| - | </ | ||
| - | Used only in XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | MAXTT is a global and PORT configuration keyword used in | ||
| - | XROUTER.CFG, | ||
| - | command. | ||
| - | |||
| - | It defines the maximum accepted "trip time" (transit time) for | ||
| - | new nodes table entries received via INP3 unicasts from | ||
| - | neighbours. | ||
| - | figure are not accepted into the nodes table. | ||
| - | 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). | ||
| - | 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 " | ||
| - | a nodes table with more than 150 entries is impractical for RF | ||
| - | users. | ||
| - | everywhere, they tend to have very large nodes tables. | ||
| - | routers on the Internet<> | ||
| - | neighbours, would also have over-sized tables, comprised | ||
| - | mainly of Internet-routed nodes. | ||
| - | 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: | ||
| - | section of XROUTER.CFG, | ||
| - | ports, overriding the default of 60000. | ||
| - | configuration block, it overrides the global default. | ||
| - | new routes inherit this value. | ||
| - | be overridden for individual routes using by " | ||
| - | route at the end of XROUTER.CFG, | ||
| - | 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 " | ||
| - | quality 100, with default maxframe, paclen and frack, MAXTT | ||
| - | of 2000 and MAXHOPS of 5. | ||
| - | |||
| - | Setting a route' | ||
| - | activity. | ||
| - | INP3. This is not recommended, | ||
| - | to do it anyway. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | which are beyond your chosen trip time horizon into the nodes | ||
| - | table and keep them refreshed. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | INP3(9) | ||
| - | MAXHOPS(7) | ||
| - | MINQUAL(1) | ||
| - | QUALITY(1) | ||
| - | ROUTES(1) | ||
| - | XRNODES(8) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHEARD.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHEARD -- Enable MHeard & set size. | ||
| - | |||
| - | </ | ||
| - | MHEARD=< | ||
| - | |||
| - | </ | ||
| - | 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 < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MHEARD=10 ; Enable MHeard, 10 callsigns max | ||
| - | MHEARD=0 | ||
| - | |||
| - | </ | ||
| - | MHCLEAR(1) | ||
| - | MHEARD(1) | ||
| - | MHFLAGS(1) | ||
| - | MHSIZE(1) | ||
| - | MHFLAGS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | MHEARD(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHFLAGS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHFLAGS -- MHeard option flags. | ||
| - | |||
| - | </ | ||
| - | MHFLAGS=n (where n is a number between 0 and 255) | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | The argument to MHFLAGS is the sum of the required options | ||
| - | from this list: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | 16 | ||
| - | |||
| - | The default is 255 (record everything). | ||
| - | |||
| - | </ | ||
| - | MHFLAGS=3 ; Directly heard stations & digipeaters only | ||
| - | MHFLAGS=4 ; Digipeated stations only | ||
| - | |||
| - | </ | ||
| - | MHCLEAR(1) | ||
| - | MHEARD(1) | ||
| - | MHFLAGS(1) | ||
| - | MHSIZE(1) | ||
| - | MHEARD(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | MHEARD(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MINQUAL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MINQUAL -- Minimum Quality to Add to Nodes Table. | ||
| - | |||
| - | </ | ||
| - | MINQUAL=n (where n is in the range 0 to 255) | ||
| - | |||
| - | </ | ||
| - | MINQUAL is an optional global and PORT directive used in | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | It specifies the minimum Net/rom " | ||
| - | have, in order to be accepted into the nodes table. | ||
| - | |||
| - | The " | ||
| - | defined, unless explicitly overridden by a port MINQUAL. | ||
| - | |||
| - | When " | ||
| - | of each node thus learned is " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MINQUAL=100 | ||
| - | |||
| - | </ | ||
| - | MINQUAL(1) | ||
| - | PORTS(6) | ||
| - | QUALITY(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MINTXQUAL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MINTXQUAL -- Minimum Quality to Broadcast. | ||
| - | |||
| - | </ | ||
| - | MINTXQUAL=n (where n is in the range 0 to 255) | ||
| - | |||
| - | </ | ||
| - | MINTXQUAL is a PORT directive used in XROUTER.CFG. | ||
| - | |||
| - | It specifies the minimum NetRom node " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | MINTXQUAL=100 ; Don't broadcast nodes with quality < | ||
| - | |||
| - | </ | ||
| - | MINQUAL(7) | ||
| - | MINTXQUAL(1) | ||
| - | PORTS(6) | ||
| - | QUALITY(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MQTTPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MQTTPORT -- TCP Port for MQTT Server/ | ||
| - | |||
| - | </ | ||
| - | MQTTPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | MQTTPORT is an optional GLOBAL configuration directive | ||
| - | used in XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | XRouter' | ||
| - | default is 1883. | ||
| - | |||
| - | The MQTT server (previously known as a " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | MQTT-SRV(9) | ||
| - | MQTT-SVC(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MQTTSERVADDR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MQTTSERVADDR -- Hostname / IP address of external MQTT Broker. | ||
| - | |||
| - | </ | ||
| - | MQTTSERVADDR=< | ||
| - | |||
| - | </ | ||
| - | 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' | ||
| - | can connect and publish data. | ||
| - | |||
| - | If MQTTSERVADDR is not specified, which is the default | ||
| - | condition, the publisher is disabled. | ||
| - | |||
| - | </ | ||
| - | MQTTSERVADDR=192.168.1.20 | ||
| - | MQTTSERVADDR=test.mosquitto.org | ||
| - | |||
| - | </ | ||
| - | MQTT-PUB(9) | ||
| - | MQTTSERVPORT(7) -- TCP Port of external MQTT Broker | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MQTTSERVPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MQTTSERVPORT -- TCP Port of External MQTT Broker. | ||
| - | |||
| - | </ | ||
| - | MQTTSERVPORT=n (where n is between 0 and 65535) | ||
| - | |||
| - | </ | ||
| - | MQTTSERVPORT is an optional directive, used in XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP port of an external MQTT | ||
| - | broker, to which XRouter' | ||
| - | publish data. | ||
| - | |||
| - | MQTTSERVPORT defaults to 1883. Setting it 0 disables the | ||
| - | MQTT publisher. | ||
| - | |||
| - | </ | ||
| - | MQTTSERVADDR=2884 | ||
| - | |||
| - | </ | ||
| - | MQTT-PUB(9) | ||
| - | MQTTSERVADDR(7) -- Hostname / IP of External MQTT Broker. | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NETMASK.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | NETMASK -- Subnet Mask. | ||
| - | |||
| - | </ | ||
| - | NETMASK=< | ||
| - | |||
| - | </ | ||
| - | NETMASK is an optional PORT directive used in XROUTER.CFG. | ||
| - | |||
| - | It specifies a " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | NETMASK=255.255.255.0 | ||
| - | |||
| - | </ | ||
| - | IPADDRESS(7) | ||
| - | NETMASK(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NODEALIAS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NODEALIAS -- Primary AX25 / NetRom Alias. | ||
| - | |||
| - | </ | ||
| - | NODEALIAS=< | ||
| - | |||
| - | </ | ||
| - | NODEALIAS is a MANDATORY directive used in the " | ||
| - | section of XROUTER.CFG, | ||
| - | |||
| - | It specifies an " | ||
| - | alternative to the NODECALL, which can be used for all AX25 | ||
| - | and NetRom operations. | ||
| - | |||
| - | The < | ||
| - | and numbers of your choice. | ||
| - | |||
| - | Aliases beginning with "#" | ||
| - | and are used for " | ||
| - | |||
| - | 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. | ||
| - | who run multiple node types tend to use " | ||
| - | for their XRouter nodes, e.g. " | ||
| - | |||
| - | All AX25 ports respond to AX25 connect requests directed at | ||
| - | this alias. They may also have up to 2 additional aliases. | ||
| - | |||
| - | </ | ||
| - | NODEALIAS=KIDDER | ||
| - | NODEALIAS=PZTXRP | ||
| - | |||
| - | </ | ||
| - | NODECALL(7) | ||
| - | PORTALIAS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NODECALL.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NODECALL -- Primary AX25 / NetRom Callsign. | ||
| - | |||
| - | </ | ||
| - | NODECALL=< | ||
| - | |||
| - | </ | ||
| - | NODECALL is a MANDATORY directive used in the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | NODECALL=GB7PZT-12 | ||
| - | |||
| - | </ | ||
| - | NODEALIAS(7) | ||
| - | PORTCALL(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NODESINT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | NODESINTERVAL -- Nodes Broadcast Interval. | ||
| - | |||
| - | </ | ||
| - | NODESINTERVAL=< | ||
| - | |||
| - | </ | ||
| - | 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 NODESINTERVAL, | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | NODESINTERVAL=10 ; 10 minues between broadcasts | ||
| - | | ||
| - | </ | ||
| - | NODESINT(1) | ||
| - | PORTS(6) | ||
| - | QUALITY(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PACLEN.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PACLEN -- Maximum Packet Length. | ||
| - | |||
| - | </ | ||
| - | PACLEN=n (where n is in the range 0 to 256) | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If the port PACLEN is set to 0, Xrouter dynamically adapts | ||
| - | PACLEN (and MAXFRAME) to the link conditions, to maximise | ||
| - | throughput. | ||
| - | |||
| - | </ | ||
| - | PACLEN=160 | ||
| - | |||
| - | </ | ||
| - | MAXFRAME(7) | ||
| - | PACLEN(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PEER.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PEER -- Specify AXIP / AXUDP Link Partner. | ||
| - | |||
| - | </ | ||
| - | PEER=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | PORT defined like this can support both AXIP and AXUDP links. | ||
| - | Only ONE such port is allowed. | ||
| - | |||
| - | This is the " | ||
| - | slighly less flexible than the " | ||
| - | method. It can be used alongside the " | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | 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' | ||
| - | |||
| - | < | ||
| - | possible, because it saves having to resolve the hostname. | ||
| - | |||
| - | < | ||
| - | |||
| - | </ | ||
| - | # 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: | ||
| - | |||
| - | </ | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | LEARN(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PERSIST.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PERSIST -- AX25 Probablity to Transmit. | ||
| - | |||
| - | </ | ||
| - | PERSIST=n (n=0-255) | ||
| - | |||
| - | </ | ||
| - | PERSIST is an optional PORT directive used in XROUTER.CFG. | ||
| - | |||
| - | It specifies the AX25 " | ||
| - | 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. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PERSIST=25 | ||
| - | PERSIST=128 | ||
| - | | ||
| - | </ | ||
| - | PERSIST(1) | ||
| - | PORTS(6) | ||
| - | SLOTTIME(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PIPE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PIPE -- Frame Pipe. | ||
| - | |||
| - | </ | ||
| - | PIPE=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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 " | ||
| - | delimited callsign list, e.g. " | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PIPE=2 | ||
| - | PIPE=4 GB7PZT, | ||
| - | |||
| - | </ | ||
| - | PIPE(1) | ||
| - | PIPEFLAG(7) | ||
| - | PIPES(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PIPEFLAG.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PIPEFLAG -- Frame Pipe Option Flags. | ||
| - | |||
| - | </ | ||
| - | PIPEFLAG=n (where n is in the range 0 to 1023) | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | The argument is the sum of the required options as follows: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | 16 - UI frames transmitted by XRouter. | ||
| - | 32 - Non-UI frames transmitted by XRouter. | ||
| - | 64 - Allow budlisted users to be piped. | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | PIPEFLAG=5 | ||
| - | PIPEFLAG=517 | ||
| - | |||
| - | </ | ||
| - | PIPE(7) | ||
| - | PIPEFLAG(1) | ||
| - | PIPES(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMSALIAS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PMSALIAS -- Alias for Personal Mail System. | ||
| - | |||
| - | </ | ||
| - | PMSALIAS=< | ||
| - | |||
| - | </ | ||
| - | | ||
| - | both " | ||
| - | |||
| - | It specifies an " | ||
| - | " | ||
| - | PMS). This can be used interchangeably with the PMSCALL; | ||
| - | i.e. the PMS will respond to either. | ||
| - | |||
| - | The < | ||
| - | and numbers. It is suggested that it should end with " | ||
| - | and begin with the last 3 letters of the sysop' | ||
| - | |||
| - | Alternatively, | ||
| - | 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 " | ||
| - | used for AX25, NetRom and TCP operations. | ||
| - | |||
| - | Any PORTs declared further down XROUTER.CFG " | ||
| - | 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 " | ||
| - | |||
| - | </ | ||
| - | PMSALIAS=IOWPMS | ||
| - | PMSALIAS=PZTPMS | ||
| - | |||
| - | </ | ||
| - | Omitting the global PMSALIAS, or setting it IDENTICAL to | ||
| - | NODEALIAS disables PMS NetRom connectivity, | ||
| - | can still be used " | ||
| - | |||
| - | </ | ||
| - | PMS(1) | ||
| - | PMS(9) | ||
| - | PMSCALL(7) | ||
| - | PMSQUAL(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMSCALL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PMSCALL -- Callsign for Personal Message System. | ||
| - | |||
| - | </ | ||
| - | PMSCALL=< | ||
| - | |||
| - | </ | ||
| - | PMSCALL is a directive that can be used in XROUTER.CFG, | ||
| - | both " | ||
| - | |||
| - | 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 " | ||
| - | 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 " | ||
| - | 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 " | ||
| - | |||
| - | </ | ||
| - | PMSCALL=G8PZT-2 | ||
| - | |||
| - | </ | ||
| - | Omitting the global PMSCALL, or setting it IDENTICAL to | ||
| - | NODECALL (including the SSID) disables PMS server | ||
| - | connectivity, | ||
| - | via the PMS command. | ||
| - | |||
| - | </ | ||
| - | PMS(1) | ||
| - | PMS(9) | ||
| - | PMSALIAS(7) | ||
| - | PMSQUAL(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMSHADDR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PMSHADDR -- Hierarchical Address of PMS. | ||
| - | |||
| - | </ | ||
| - | PMSHADDR=< | ||
| - | |||
| - | </ | ||
| - | PMSHADDR is an optional directive, which can be used anywhere | ||
| - | within the " | ||
| - | specifies the " | ||
| - | This address is used, in combination wih the mailbox callsign, | ||
| - | for routing mail. | ||
| - | |||
| - | If a typical mailbox address is " | ||
| - | " | ||
| - | 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 " | ||
| - | required if you intend to exchange mail with other systems. | ||
| - | Note that it MUST begin with a dot. | ||
| - | |||
| - | </ | ||
| - | PMSHADDR=.# | ||
| - | |||
| - | </ | ||
| - | PMS(1) | ||
| - | PMSTYPE(7) | ||
| - | PMS.CFG(8) | ||
| - | PMS(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMSQUAL.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PMSQUAL -- NetRom Quality for Personal Message System. | ||
| - | |||
| - | </ | ||
| - | PMSQUAL=n | ||
| - | |||
| - | </ | ||
| - | PMSQUAL is an optional directive used in the " | ||
| - | section of XROUTER.CFG. | ||
| - | |||
| - | It specifies the NetRom " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PMSQUAL=50 | ||
| - | |||
| - | </ | ||
| - | PMSALIAS(7) | ||
| - | PMSCALL(7) | ||
| - | PMS(9) | ||
| - | PMS-SVC(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMSTYPE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PMSTYPE -- Set PMS / BBS mode. | ||
| - | |||
| - | </ | ||
| - | PMSTYPE=n (n=0-4) | ||
| - | |||
| - | </ | ||
| - | PMSTYPE is an optional directive, which can be used anywhere | ||
| - | within the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 0 Reserved for possible "No bulletins" | ||
| - | 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 " | ||
| - | 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 " | ||
| - | systems. | ||
| - | |||
| - | Mode 2 allows " | ||
| - | forwarding, but does not allow " | ||
| - | received from one BBS cannot be forwarded to another. | ||
| - | |||
| - | Mode 3 is a " | ||
| - | pretends to be a PMS. It is still accessed using the PMS | ||
| - | command. | ||
| - | |||
| - | Mode 4 changes some of the captions, and installs the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PMSTYPE=1 | ||
| - | PMSTYPE=3 | ||
| - | |||
| - | </ | ||
| - | PMS(1) | ||
| - | PMSHADDR(7) | ||
| - | PMS.CFG(8) | ||
| - | PMS(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PORTALIAS2.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PORTALIAS2 -- Secondary Alias for a Port. | ||
| - | |||
| - | </ | ||
| - | PORTALIAS2=< | ||
| - | |||
| - | </ | ||
| - | 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 < | ||
| - | and numbers. | ||
| - | |||
| - | </ | ||
| - | PORTALIAS2=KRDIGI | ||
| - | |||
| - | </ | ||
| - | PORTALIAS(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PORTALIAS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PORTALIAS -- Additional Alias for a Port. | ||
| - | |||
| - | </ | ||
| - | PORTALIAS=< | ||
| - | |||
| - | </ | ||
| - | 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 < | ||
| - | and numbers. | ||
| - | |||
| - | </ | ||
| - | PORTALIAS=KDRMIN | ||
| - | |||
| - | </ | ||
| - | NODEALIAS(7) | ||
| - | PORTALIAS2(7) | ||
| - | PORTCALL(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PORTCALL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PORTCALL -- Additional Callsign for a Port. | ||
| - | |||
| - | </ | ||
| - | PORTCALL=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PORTCALL=GB7PZT-1 | ||
| - | |||
| - | </ | ||
| - | NODECALL(7) | ||
| - | PORTALIAS(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PROMPTCOLOR.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PROMPTCOLOR -- Colour For XRouter Prompts. | ||
| - | |||
| - | </ | ||
| - | PROMPTCOLOR=< | ||
| - | |||
| - | </ | ||
| - | PROMPTCOLOR is an optional directive that can be used both | ||
| - | in the " | ||
| - | definition blocks. | ||
| - | |||
| - | It specifies the colour used by XRouter for prompts such | ||
| - | as " | ||
| - | etc. | ||
| - | |||
| - | If used in the " | ||
| - | 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. | ||
| - | been carefully chosen for good visibility against a BLACK | ||
| - | background. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PROMPTCOLOR=YELLOW | ||
| - | |||
| - | </ | ||
| - | ANSI(1) | ||
| - | COLOURS(6) | ||
| - | CONSOLES(6) | ||
| - | ACTIONCOLOR(7) | ||
| - | CAPTIONCOLOR(7) -- Colour For Captions and Headings. | ||
| - | WARNCOLOR(7) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PROTOCOL.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PROTOCOL -- Protocol Used on INTERFACE. | ||
| - | |||
| - | </ | ||
| - | PROTOCOL=< | ||
| - | |||
| - | </ | ||
| - | PROTOCOL is a configuration directive used within INTERFACE | ||
| - | definition blocks in XROUTER.CFG, | ||
| - | use on the interface. | ||
| - | |||
| - | It is mandatory in most types of INTERFACE, but not required | ||
| - | in other types, e.g. TYPE=AXIP, AXUDP etc. | ||
| - | |||
| - | < | ||
| - | |||
| - | </ | ||
| - | ASCII - Raw ASCII. | ||
| - | This is a plain ASCII *uplink* to XRouter' | ||
| - | command interpreter from a real "dumb terminal", | ||
| - | or a " | ||
| - | 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. | ||
| - | |||
| - | 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 | ||
| - | This is an " | ||
| - | | ||
| - | TNCs running NET/ROM or TheNet node EPROM' | ||
| - | 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 | ||
| - | | ||
| - | 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, | ||
| - | use on ASYNC interfaces, but can also be used on | ||
| - | TCP, UDP and LOOPBACK. | ||
| - | |||
| - | 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 | ||
| - | | ||
| - | |||
| - | TNC2 - TNC2 emulator. | ||
| - | This is an 8-bit ASCII *uplink* from an external | ||
| - | | ||
| - | where XRouter looks like a " | ||
| - | as far as the external device is concerned. | ||
| - | | ||
| - | be used with interface types TCP and UDP. | ||
| - | See TNC2(9) for more information. | ||
| - | |||
| - | </ | ||
| - | 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! | ||
| - | |||
| - | </ | ||
| - | IFACES(6) | ||
| - | AXIP(9) | ||
| - | AXTCP(9) | ||
| - | AXUDP(9) | ||
| - | DEDHOST(9) | ||
| - | PPP(9) | ||
| - | PSTN(9) | ||
| - | SLIP(9) | ||
| - | TNC2(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PROXY.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PROXY -- Proxy Connectivity. | ||
| - | |||
| - | </ | ||
| - | PROXY=< | ||
| - | PROXY=< | ||
| - | PROXY=< | ||
| - | |||
| - | </ | ||
| - | PROXY is an optional XROUTER.CFG directive that can be used | ||
| - | both " | ||
| - | |||
| - | It is used to define " | ||
| - | 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). | ||
| - | |||
| - | </ | ||
| - | If used within a PORT definition block, PROXY defines an | ||
| - | " | ||
| - | AX25 presence on the port. The format is: | ||
| - | |||
| - | PROXY=< | ||
| - | |||
| - | < | ||
| - | proxied systems. | ||
| - | |||
| - | Example: PROXY=GB7PZT, | ||
| - | |||
| - | If used within the " | ||
| - | TWO possible forms of the PROXY, as follows: | ||
| - | |||
| - | The first of these is the " | ||
| - | 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' | ||
| - | neighbours. | ||
| - | |||
| - | PROXY=< | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | |||
| - | Example: PROXY=MB7UYL UYLBBS 150 G6KDR-3 7 | ||
| - | |||
| - | The second " | ||
| - | which gives a TCP-only system both an AX25 and a NetRom | ||
| - | presence on all ports. It is specified like this: | ||
| - | |||
| - | PROXY=< | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | 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 | ||
| - | |||
| - | </ | ||
| - | Proxies are very useful, but very dangerous if you aren't sure | ||
| - | what you are doing! Proxy-created " | ||
| - | 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! | ||
| - | |||
| - | </ | ||
| - | PROXIES(9) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====QUALADJ.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | QUALADJUST -- NetRom Quality Manipulation. | ||
| - | |||
| - | </ | ||
| - | This file describes a feature which allows you to reduce | ||
| - | the NetRom quality of " | ||
| - | exclude certain nodes or groups of nodes altogether. | ||
| - | |||
| - | </ | ||
| - | With ever-increasing connectivity via the Internet, the | ||
| - | NetRom network is bypassing national and geographical | ||
| - | boundaries, and this is causing problems. | ||
| - | 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 " | ||
| - | commands become useless because the response becomes too | ||
| - | large for the user to download on a limited bandwidth | ||
| - | channel. | ||
| - | 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? | ||
| - | 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? | ||
| - | amidst the clutter? | ||
| - | |||
| - | Quality de-rating by callsign can help with this management | ||
| - | issue. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | This feature uses the global QUALADJUST directive in | ||
| - | XROUTER.CFG as follows: | ||
| - | |||
| - | | ||
| - | |||
| - | e.g. QUALADJUST DEFAULT 120 | ||
| - | QUALADJUST G* 255 | ||
| - | QUALADJUST ZL* 200 | ||
| - | |||
| - | The " | ||
| - | to de-rate all nodes not matched by any other QUALADJUST | ||
| - | statement. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | QUALADJUST is applied to neighbour nodes and all nodes | ||
| - | learned from NetRom broadcasts. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | This is an experimental feature. Please use it with caution. | ||
| - | |||
| - | </ | ||
| - | AUTOQUAL(9) | ||
| - | NODES(1) | ||
| - | QUALITY(1) | ||
| - | XRNODES(8) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====QUALITY.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | QUALITY -- Default NetRom Quality. | ||
| - | |||
| - | </ | ||
| - | QUALITY=n (where n is 0 to 255) | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | QUALITY=30 | ||
| - | |||
| - | </ | ||
| - | QUALITY(1) | ||
| - | QUALADJ(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RADIO.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RADIO -- Radio control definition block. | ||
| - | |||
| - | </ | ||
| - | RADIO=n (where n is a number between 1 and 5) | ||
| - | |||
| - | </ | ||
| - | RADIO is an optional directive used in XROUTER.CFG. If | ||
| - | present in the " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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 | ||
| - | For most types this is via a TTY, for example | ||
| - | " | ||
| - | the IP address and port used by Hamlib, | ||
| - | for example " | ||
| - | |||
| - | BAUDS Baud rate for the TTY (not needed for Hamlib). | ||
| - | Defaults to 9600 (1200 for ICR7000). | ||
| - | |||
| - | STOPBITS Number of " | ||
| - | (Not required for Hamlib) | ||
| - | |||
| - | FREQUENCY Initial receive frequency in Hz, e.g. " | ||
| - | |||
| - | OFFSET | ||
| - | and actual frequency, in case the rig's reference | ||
| - | crytal has drifted. | ||
| - | |||
| - | MODE Initial modulation mode: | ||
| - | (Not all radios support all types) | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | " | ||
| - | |||
| - | SQUELCH Initial Squelch level (0-255) | ||
| - | 0=fully open, 255=fully closed | ||
| - | |||
| - | VOLUME | ||
| - | |||
| - | TXFREQ | ||
| - | (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: " | ||
| - | |||
| - | Some of the values are " | ||
| - | by the RADIO command during run-time, for example FREQUENCY, | ||
| - | VOLUME, MODE etc. | ||
| - | |||
| - | </ | ||
| - | Example for PCR1000 receiver controlled via / | ||
| - | defaulting to 9600,8,n.2 with VOIP audio input via /dev/dsp2 | ||
| - | |||
| - | RADIO=1 | ||
| - | NAME=PCR-1000 | ||
| - | TYPE=3 | ||
| - | COM=/ | ||
| - | FREQUENCY=145.625 | ||
| - | MODE=FMn | ||
| - | VOLUME=80 | ||
| - | SQUELCH=75 | ||
| - | RXAUDIODEV=/ | ||
| - | ENDRADIO | ||
| - | |||
| - | </ | ||
| - | RADIO(1) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RESPTIME.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RESPTIME -- AX25 Delayed Ack Time. | ||
| - | |||
| - | </ | ||
| - | RESPTIME=< | ||
| - | |||
| - | </ | ||
| - | RESPTIME is an optional PORT drectuive, used in XROUTER.CFG. | ||
| - | |||
| - | It specifies the AX25 " | ||
| - | 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, | ||
| - | |||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | RESPTIME=2000 | ||
| - | |||
| - | </ | ||
| - | FRACK(7) | ||
| - | RESPTIME(1) | ||
| - | PACLEN(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RETRIES.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RETRIES -- AX25 Maximum Retry Count. | ||
| - | |||
| - | </ | ||
| - | RETRIES=n (where n is 0 to 100) | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | destination. | ||
| - | |||
| - | RETRIES=0 means "try forever", | ||
| - | for testing. | ||
| - | |||
| - | The value can be changed during run-time using the command | ||
| - | of the same name. | ||
| - | |||
| - | </ | ||
| - | RETRIES=5 | ||
| - | |||
| - | </ | ||
| - | RETRIES(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RFBAUDS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RFBAUDS -- Radio Channel Baud Rate. | ||
| - | |||
| - | </ | ||
| - | RFBAUDS=< | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | RFBAUDS=2400 | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | YAM(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RHPPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RHPPORT -- TCP Port for RHP Server. | ||
| - | |||
| - | </ | ||
| - | RHPPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | RHPPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | RHP-SRV(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RLOGINPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RLOGINPORT -- TCP Port for Remote Login Service. | ||
| - | |||
| - | </ | ||
| - | RLOGINPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | RLOGINPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | by the RLOGIN (Rmote Login) service. If not present, the | ||
| - | default is 513. | ||
| - | |||
| - | RLOGIN is a " | ||
| - | secure links. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | first argument applies to the XRouter stack and the second to | ||
| - | the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | RLOGIN(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ROWS.7.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ROWS -- Set Display Height. | ||
| - | |||
| - | </ | ||
| - | ROWS=n (n = 25-60) | ||
| - | |||
| - | </ | ||
| - | ROWS is an optional configuration directive, used only in the | ||
| - | " | ||
| - | 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 " | ||
| - | retro "full screen" | ||
| - | 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, | ||
| - | CONSOLE definitions. | ||
| - | ROWS=50. | ||
| - | |||
| - | Depending on your screen resolution and " | ||
| - | Linux " | ||
| - | 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. | ||
| - | limit, the display will either break up or behave oddly. | ||
| - | |||
| - | </ | ||
| - | If you set ROWS more than 25, you cannot use "full screen" | ||
| - | mode on Windows. | ||
| - | |||
| - | </ | ||
| - | COLS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SESSLIMIT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SESSLIMIT -- Maximum Simultaneous Connections on Port. | ||
| - | |||
| - | </ | ||
| - | SESSLIMIT=n (where n is 0 to 255) | ||
| - | |||
| - | </ | ||
| - | 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 " | ||
| - | the bandwidth on a port with too many connections. | ||
| - | |||
| - | There is a global limit on the number of AX25 links, namely | ||
| - | MAXLINKS (default=30), | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | SESSLIMIT=5 | ||
| - | |||
| - | </ | ||
| - | MAXLINKS(7) | ||
| - | PORTS(6) | ||
| - | USERS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SLOTTIME.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SLOTTIME -- CSMA Interval Time. | ||
| - | |||
| - | </ | ||
| - | SLOTTIME=< | ||
| - | |||
| - | </ | ||
| - | 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' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | SLOTTIME=100 | ||
| - | |||
| - | </ | ||
| - | SLOTTIME(1) | ||
| - | PERSIST(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SOCKSPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SOCKSPORT -- TCP Port for SOCKS Proxy. | ||
| - | |||
| - | </ | ||
| - | SOCKSPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | SOCKSPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | by the SOCKS Proxy. If not present, the default is 1080. | ||
| - | |||
| - | SOCKS is a circuit level proxy for applications, | ||
| - | alternative to Network Address Transslation (NAT). | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | SOCKS(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SOFTDCD.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SOFTDCD -- Software Data Carrier Detect. | ||
| - | |||
| - | </ | ||
| - | SOFTDCD=< | ||
| - | |||
| - | </ | ||
| - | 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). | ||
| - | |||
| - | </ | ||
| - | If SOFTDCD=0 the " | ||
| - | |||
| - | If SOFTDCD=1 the real dcd is ignored, and the SCC driver uses | ||
| - | the presence of HDLC data as a DCD indication. | ||
| - | |||
| - | </ | ||
| - | Using SOFTDCD=1 with an open squelch generates a *huge* | ||
| - | interrupt loading, which may cause degradation of | ||
| - | performance, | ||
| - | recommended. | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SYSOP.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SYSOP -- Description.. | ||
| - | |||
| - | </ | ||
| - | SYSOP=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TELNETPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TELNETPORT -- TCP Port for TELNET Access. | ||
| - | |||
| - | </ | ||
| - | TELNETPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | TELNETPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | for TELNET access to XRouter. If not present, the default is | ||
| - | 23. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | TELNET(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TELPROXYPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TELPROXYPORT -- TCP Port for Telnet Proxy. | ||
| - | |||
| - | </ | ||
| - | TELPROXYPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | TELPROXYPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | it applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | TELPROXY(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TTYLINKPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TTYLINKPORT -- TCP Port for TTYLINK Access. | ||
| - | |||
| - | </ | ||
| - | TTYLINKPORT=n1 [n2] (where n1 and n2 are 0 to 65535) | ||
| - | |||
| - | </ | ||
| - | TTYLINKPORT is an optional " | ||
| - | XROUTER.CFG. | ||
| - | |||
| - | If present, it specifies the TCP " | ||
| - | for TTYLINK (keyboard to keyboard chat) access to XRouter. If | ||
| - | not present, the default is 87. | ||
| - | |||
| - | TTYLINK is also available as NetRomX service 87. | ||
| - | |||
| - | </ | ||
| - | If a single argument is supplied, e.g. " | ||
| - | applies to whichever TCP/IP stack(s) XRouter is using. | ||
| - | |||
| - | If TWO arguments are supplied, e.g. " | ||
| - | the first argument applies to the XRouter stack and the | ||
| - | second to the host system' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | CAPFLAGS(6) | ||
| - | TTYLINK(9) | ||
| - | TCP-PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXDELAY.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXDELAY -- Transmit Delay. | ||
| - | |||
| - | </ | ||
| - | TXDELAY=< | ||
| - | |||
| - | </ | ||
| - | 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' | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | Software TNC's such as " | ||
| - | 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' | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | TXDELAY(1) | ||
| - | PORTS(6) | ||
| - | TXTAIL(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXPORT.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXPORT -- Port to Transmit On. | ||
| - | |||
| - | </ | ||
| - | TXPORT=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | TXPORT=5 | ||
| - | |||
| - | </ | ||
| - | TXPORT(1) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXTAIL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXTAIL -- Transmitter Turnoff Delay. | ||
| - | |||
| - | </ | ||
| - | TXTAIL=< | ||
| - | |||
| - | </ | ||
| - | 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, | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | TXTAIL(1) | ||
| - | TXDELAY(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UDPLOCAL.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | UDPLOCAL -- Local UDP Port for Link. | ||
| - | |||
| - | </ | ||
| - | UDPLOCAL=< | ||
| - | |||
| - | </ | ||
| - | 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' | ||
| - | 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 " | ||
| - | 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! | ||
| - | |||
| - | </ | ||
| - | UDPLOCAL=7388 | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | AXUDP(9) | ||
| - | CAPFLAGS(6) | ||
| - | PORTS(6) | ||
| - | UDPLOCAL(1) | ||
| - | UDPREMOTE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UDPREMOTE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | UDPREMOTE -- Remote UDP Port for Link. | ||
| - | |||
| - | </ | ||
| - | UDPREMOTE=< | ||
| - | |||
| - | </ | ||
| - | 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' | ||
| - | |||
| - | 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). | ||
| - | |||
| - | </ | ||
| - | UDPREMOTE=10093 | ||
| - | |||
| - | </ | ||
| - | AXUDP(9) | ||
| - | PORTS(6) | ||
| - | UDPLOCAL(7) | ||
| - | UDPREMOTE(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UNPROTO.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | UNPROTO -- Path for Unproto Broadcasts. | ||
| - | |||
| - | </ | ||
| - | UNPROTO < | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | UNPROTO=CQ, | ||
| - | |||
| - | </ | ||
| - | UNPROTO(1) | ||
| - | APRSPATH(7) -- Default Digipeater Path for APRS. | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====USERS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | USERS -- Maximum Users on Port. | ||
| - | |||
| - | </ | ||
| - | USERS=< | ||
| - | |||
| - | </ | ||
| - | 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" | ||
| - | |||
| - | </ | ||
| - | USERS=9 | ||
| - | |||
| - | </ | ||
| - | PORTS(6) | ||
| - | SESSLIMIT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====VALIDCALLS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | VALIDCALLS -- AX25 Whitelist. | ||
| - | |||
| - | </ | ||
| - | VALIDCALLS=< | ||
| - | |||
| - | </ | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | VALIDCALLS=G6YAK, | ||
| - | |||
| - | </ | ||
| - | EXCLUDE(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WALLFLAGS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WALLFLAGS -- Options for Message Wall / Guestbook. | ||
| - | |||
| - | </ | ||
| - | WALLFLAGS=n (where 0 <= n <= 15) | ||
| - | |||
| - | </ | ||
| - | WALLFLAGS is an optional directive used only in XROUTER.CFG. | ||
| - | |||
| - | It controls whether or not the message " | ||
| - | whether or not the sysop is notified of new " | ||
| - | replies, and whether or not the activity is published via the | ||
| - | MQTT broker. | ||
| - | |||
| - | If WALLFLAGS is omitted, the wall is disabled. | ||
| - | |||
| - | </ | ||
| - | 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 | ||
| - | |||
| - | </ | ||
| - | WALL(1) | ||
| - | MQTT-SRV(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WARNCOLOR.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WARNCOLOR -- Colour For Warnings and Errors. | ||
| - | |||
| - | </ | ||
| - | WARNCOLOR=< | ||
| - | |||
| - | </ | ||
| - | WARNCOLOR is an optional directive that can be used both | ||
| - | in the " | ||
| - | definition blocks. | ||
| - | |||
| - | It specifies the colour used by XRouter for warning and | ||
| - | error messages, such as " | ||
| - | " | ||
| - | |||
| - | If used in the " | ||
| - | 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. | ||
| - | been carefully chosen for good visibility against a BLACK | ||
| - | background. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | WARNCOLOR=PINK | ||
| - | |||
| - | </ | ||
| - | ANSI(1) | ||
| - | COLOURS(6) | ||
| - | CONSOLES(6) | ||
| - | ACTIONCOLOR(7) | ||
| - | CAPTIONCOLOR(7) -- Colour For Captions and Headings. | ||
| - | PROMPTCOLOR(7) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WXFILE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WXFILE -- Specify Weather Import File. | ||
| - | |||
| - | </ | ||
| - | WXFILE=[path/ | ||
| - | |||
| - | </ | ||
| - | WXFILE is an optional " | ||
| - | |||
| - | It specifies the filename (and if necessary the path to it), | ||
| - | of a file that contains weather data in WXNOW, CUMULUS or | ||
| - | "< | ||
| - | 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.. | ||
| - | |||
| - | </ | ||
| - | WXFILE=/ | ||
| - | |||
| - | </ | ||
| - | WX(1) -- Obtain Weather Information. | ||
| - | WX-SVC(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WXMAXAGE.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WXMAXAGE -- Specify Maximum Age of a Weather Record. | ||
| - | |||
| - | </ | ||
| - | WXMAXAGE=< | ||
| - | |||
| - | </ | ||
| - | WXMAXAGE is an optional " | ||
| - | |||
| - | It specifies the maximum lifetime of a weather record, in | ||
| - | seconds since the time of observation. | ||
| - | maximum lifetime are purged. | ||
| - | |||
| - | If not specified, the default lifetime is 21600 seconds, i.e. | ||
| - | 6 hours. | ||
| - | |||
| - | </ | ||
| - | WXMAXAGE=3600 | ||
| - | |||
| - | </ | ||
| - | WX(1) -- Obtain Weather Information. | ||
| - | WX-SVC(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====WXMAXRECS.7.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WXMAXRECS -- Specify Maximum Number of Weather Records. | ||
| - | |||
| - | </ | ||
| - | WXMAXRECS=< | ||
| - | |||
| - | </ | ||
| - | WXMAXRECS is an optional " | ||
| - | |||
| - | It specifies the maximum number of weather records to retain, | ||
| - | one for each weather " | ||
| - | |||
| - | 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. | ||
| - | closer station, the most distant one is deleted. | ||
| - | | ||
| - | If not specified, the default value is 5. | ||
| - | |||
| - | </ | ||
| - | WXMAXRECS=25 | ||
| - | |||
| - | </ | ||
| - | WX(1) -- Obtain Weather Information. | ||
| - | WX-SVC(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
packet/xrpi/manpages/section7.1745063630.txt.gz · Last modified: 2025/04/19 11:53 by m0mzf