packet:xrpi:manpages:section1
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| packet:xrpi:manpages:section1 [2025/04/19 11:49] – m0mzf | packet:xrpi:manpages:section1 [2025/04/19 17:59] (current) – removed m0mzf | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =======Section 1 - General Commands======= | ||
| - | =====ACL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ACL -- IP Access Control List commands | ||
| - | |||
| - | </ | ||
| - | AC[l] D[eny] < | ||
| - | AC[l] L[og] [0-3] | ||
| - | AC[l] M[ove] <rule number> <U[p] | D[own]> | ||
| - | AC[l] P[ermit] < | ||
| - | AC[l] R[emove] <rule number> | ||
| - | AC[l] V[iew] | ||
| - | | ||
| - | </ | ||
| - | The ACL command allows XRouter' | ||
| - | be viewed and edited on the fly without having to edit and | ||
| - | reload IPROUTE.SYS. | ||
| - | |||
| - | The Access Control List specifies which IP addresses are | ||
| - | allowed to send datagrams to, receive datagrams from, and | ||
| - | route datagrams through XRouter' | ||
| - | " | ||
| - | |||
| - | A DENY rule denies access to a specified destination from a | ||
| - | specified source, whilst a PERMIT rule allows access. Both | ||
| - | types of rule can work on single addresses or whole subnets. | ||
| - | |||
| - | Rules can be added using the ACL commands, either at the | ||
| - | command line or in IPROUTE.SYS. | ||
| - | |||
| - | If the Access Control List contains no rules, the default | ||
| - | action is " | ||
| - | unsatisfatory, | ||
| - | compatability. | ||
| - | |||
| - | If one or more rules are present, the default action is | ||
| - | " | ||
| - | " | ||
| - | |||
| - | Rules are applied in the order in which they appear in the | ||
| - | table. | ||
| - | |||
| - | There is currently no mechanism to save a modified ACL back | ||
| - | to the IPROUTE.SYS file, as the ACL command is intended only | ||
| - | for on-the-fly changes. | ||
| - | |||
| - | The syntax for each sub-command can be revealed by | ||
| - | typing that sub-command without any arguments. | ||
| - | |||
| - | </ | ||
| - | Typing ACL without any arguments reveals the subcommands as | ||
| - | follows: | ||
| - | |||
| - | D[eny] | ||
| - | P[ermit] | ||
| - | M[ove] | ||
| - | R[emove] | ||
| - | V[iew] | ||
| - | L[og] | ||
| - | |||
| - | The PERMIT and DENY sub-commands APPEND filter rules to the | ||
| - | IP Access Control List. The < | ||
| - | arguments each have the form: | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | |||
| - | [mask] | ||
| - | the number of bits (0-32) of the IP address to | ||
| - | match from left to right, OR as a dotted quad. | ||
| - | |||
| - | [port] | ||
| - | this or setting it to 0 implies "any port". | ||
| - | |||
| - | [protocol] | ||
| - | | ||
| - | | ||
| - | TCP is 6 and UDP is 17. Omitting this field, or | ||
| - | | ||
| - | |||
| - | The combination 0.0.0.0/32 is a special case matching any of | ||
| - | XRouter' | ||
| - | |||
| - | The VIEW subcommand displays all the rules. Each rule has a | ||
| - | number, which can be used by the REMOVE subcommand. | ||
| - | |||
| - | The REMOVE subcommand removes a rule. After removal, the | ||
| - | remaining rules are renumbered. | ||
| - | |||
| - | The LOG subcommand displays or sets the ACL logging level. | ||
| - | The only levels so far defined are: | ||
| - | |||
| - | Level | ||
| - | ------------------------------------------- | ||
| - | 0 No ACL logging | ||
| - | 1 Log denial events | ||
| - | 2 | ||
| - | 3 Log and display denial events | ||
| - | |||
| - | Typing ACL LOG without any arguments displays the current log | ||
| - | level. | ||
| - | |||
| - | If ACL logging is enabled, ACL events go into the main daily | ||
| - | log. Be aware that in some cases this might generate a lot of | ||
| - | logging, and in other cases virtually nothing. It depends on | ||
| - | how strict your rules are, what your IP routing table is | ||
| - | like, how open your system is to the outside world, and how | ||
| - | much it is attacked. | ||
| - | |||
| - | Logging defaults off, but the ACL LOG command may be used in | ||
| - | IPROUTE.SYS to set it on at bootup if desired. | ||
| - | |||
| - | </ | ||
| - | Allow LAN sources to access any destination: | ||
| - | |||
| - | acl permit | ||
| - | |||
| - | Allow XRouter to access any destination: | ||
| - | |||
| - | acl permit | ||
| - | |||
| - | Prevent non-LAN sources from accessing our TCP port 513: | ||
| - | |||
| - | acl deny 0.0.0.0/ | ||
| - | |||
| - | </ | ||
| - | The ACL command is only available to sysops. | ||
| - | |||
| - | </ | ||
| - | IPROUTE.SYS(8) -- IP Routing File. | ||
| - | IDS(9) | ||
| - | ACCESS.SYS(8) | ||
| - | AXSCTRL(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====AMSG.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | AMSG -- Enter APRS Messaging mode. | ||
| - | |||
| - | </ | ||
| - | AM[sg] < | ||
| - | |||
| - | </ | ||
| - | The AMSG command switches the user's session into APRS | ||
| - | messaging mode, enabling him to exchange messages and | ||
| - | bulletins with APRS and UI-View users. | ||
| - | |||
| - | The < | ||
| - | traffic will be sent and received. e.g. "AM 13" will use port | ||
| - | 13. | ||
| - | |||
| - | Within messaging mode, all commands begin with a forward | ||
| - | slash (/), and anything else is treated as message text for | ||
| - | transmission. | ||
| - | |||
| - | / | ||
| - | / | ||
| - | /C[ancel] [#] List / cancel unacked message(s) | ||
| - | / | ||
| - | /H[elp] [cmd] | ||
| - | /Monitor [on|off] | ||
| - | / | ||
| - | /T[arget] [call] | ||
| - | /U[iview] [on|off] | ||
| - | /V[ia] [digis] | ||
| - | /X Exit | ||
| - | |||
| - | Only the first letter of each command needs to be supplied. | ||
| - | A few are worthy of further explanation.... | ||
| - | |||
| - | The /D command shows a list of all the stations heard | ||
| - | directly, i.e. not via digipeaters or 3rd party networks. | ||
| - | |||
| - | Before any type of message or query can be sent, the user | ||
| - | must specify a " | ||
| - | messages, the target is a callsign. | ||
| - | should be BLN#*, where "#" | ||
| - | represents the bulletin category of up to 5 characters. | ||
| - | Announcements use the same format as bulletins, except that | ||
| - | "#" | ||
| - | without first defining a target will result in an error | ||
| - | response. | ||
| - | specified. | ||
| - | "/ | ||
| - | "/T .". | ||
| - | |||
| - | Outgoing messages and bulletins are re-transmitted at | ||
| - | intervals until either an acknowledgement is received, or too | ||
| - | many retries have taken place. | ||
| - | every 20 minutes for 4 hours, whilst announcements are re- | ||
| - | transmitted every hour for 4 days. Messages are initially re- | ||
| - | transmitted after 10 seconds, then the interval doubles with | ||
| - | each re-send. | ||
| - | hours, the message is expired and re-transmission ceases. | ||
| - | The " | ||
| - | messages and bulletins to be cancelled at any time before | ||
| - | expiry. | ||
| - | |||
| - | The /M (Monitor) command allows other APRS and UI-View | ||
| - | message traffic on the channel to be watched. | ||
| - | is " | ||
| - | |||
| - | The /U (Ui-View mode) command sets the type of outgoing | ||
| - | message to be used. The default is " | ||
| - | all outgoing messages will be in APRS format. If turned " | ||
| - | outgoing messages will be in " | ||
| - | mode, both types of message can be received. UI-View messages | ||
| - | will display with a tilde (~) between the message and its ID, | ||
| - | whereas APRS-format messages will display with a curly | ||
| - | opening bracket ({) if a message ID was supplied. | ||
| - | mode, " | ||
| - | portion | ||
| - | " | ||
| - | |||
| - | /Q (quit) and /X (exit) are identical in function, exiting | ||
| - | message mode and returning the user to XRouter' | ||
| - | prompt. | ||
| - | |||
| - | The /V (via) command sets the digipeater path for outgoing | ||
| - | messages, or if used by itself displays the currently set | ||
| - | path. The path defaults to the port APRSPATH specified in | ||
| - | XROUTER.CFG. | ||
| - | APZ###, where ### is the 3 digit Xrouter version number, | ||
| - | whereas in UI-View mode the destination call is set by the | ||
| - | /Target command. | ||
| - | |||
| - | The /H (help) command is used to display help for the | ||
| - | messaging commands. | ||
| - | (low bandwidth) command resume is displayed. | ||
| - | files are installed, "/H *" will list the help available, and | ||
| - | "/H < | ||
| - | < | ||
| - | argument is ignored, so "/H V" is equally valid. | ||
| - | |||
| - | </ | ||
| - | If Xrouter receives an APRS message whose target address is a | ||
| - | user currently logged into the APRS messaging shell, the | ||
| - | message is delivered to the user and, if there was a message | ||
| - | ID, an acknowledgement is sent. Each re-send of the message | ||
| - | is acknowledged, | ||
| - | the sender didn't receive the previous ack. | ||
| - | |||
| - | If the same message is received twice within 30 seconds, the | ||
| - | second copy is ignored. | ||
| - | received via different digipeater routes. | ||
| - | |||
| - | Expired messages are retained for 1 day before being deleted. | ||
| - | During this interval they will be reactivated if a "? | ||
| - | query is received from the target station. | ||
| - | bulletins and announcements are not retained after expiry. | ||
| - | Incoming | ||
| - | received, and incoming announcements are retained for 4 days | ||
| - | after last received. | ||
| - | |||
| - | The APRS spec limits the maximum message length to 67 | ||
| - | characters. Because a message ID of up to 6 characters is | ||
| - | appended to the message, XRouter splits messages longer than | ||
| - | 61 characters into separate messages no longer than 61 | ||
| - | characters (excluding ID) each. | ||
| - | |||
| - | All APRS facilities are an ongoing experiment and may be | ||
| - | liable to change as development continues. | ||
| - | "APRS Protocol Reference" | ||
| - | |||
| - | </ | ||
| - | All users, but guests can't send messages. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ANSI.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ANSI -- Enquire/set ANSI colour mode | ||
| - | |||
| - | </ | ||
| - | AN[si] [on | off] | ||
| - | |||
| - | </ | ||
| - | The ANSI command switches ANSI colour mode on/off, and | ||
| - | reports the current mode. | ||
| - | |||
| - | To use ANSI colour, you need an ANSI-capable terminal, such | ||
| - | as XRouter, PuTTY, Windows Telnet or Linux Telnet. | ||
| - | |||
| - | By default, sessions on the XRouter console are in colour, | ||
| - | i.e. ANSI is ON. You can type ANSI OFF to view in glorious | ||
| - | monochrome. | ||
| - | |||
| - | If your session is in colour, and you perform a NetRom | ||
| - | connect to another XRouter (version 502 or later), that | ||
| - | connection will also be in colour. | ||
| - | |||
| - | </ | ||
| - | ANSI | ||
| - | ANSI ON Turn colour on. | ||
| - | |||
| - | </ | ||
| - | The ANSI command is available to all users. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====APPLMASK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | APPLMASK -- Display / Set Application Connectivity Mask. | ||
| - | |||
| - | </ | ||
| - | APP[lmask] < | ||
| - | |||
| - | </ | ||
| - | The APPLMASK command displays and controls which applications | ||
| - | are connectable at AX25 L2 on the specified port. It has a | ||
| - | similar function to the APPLMASK directive, used in | ||
| - | XROUTER.CFG, | ||
| - | |||
| - | In this context, " | ||
| - | XRouter to provide their connectivity with the outside world. | ||
| - | |||
| - | In order to be directly connectable 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 are directly | ||
| - | connectable 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. | ||
| - | |||
| - | </ | ||
| - | The APPLMASK command is only available to sysops. | ||
| - | |||
| - | </ | ||
| - | APPLMASK(7) | ||
| - | APPLS(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | | ||
| - | </ | ||
| - | ---- | ||
| - | =====ARP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ARP -- Display / Edit the ARP table. | ||
| - | |||
| - | </ | ||
| - | ARP A[dd] < | ||
| - | ARP C[md] [0-255] | ||
| - | ARP D[rop] < | ||
| - | ARP F[lush] | ||
| - | ARP L[ist] | ||
| - | ARP M[axq] [0-32767] | ||
| - | ARP LE[arn] <port | default> [ON | OFF] | ||
| - | ARP P[ublish] < | ||
| - | ARP T[imeout] [secs] | ||
| - | ARP W[ait] [secs] | ||
| - | |||
| - | </ | ||
| - | The ARP command is used to display and edit the Address | ||
| - | Resolution Table, which maps IP addresses to hardware ones. | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | |||
| - | ARP by itself, lists the table. | ||
| - | ARP ADD is used to add an entry to the table. | ||
| - | ARP CMD specifies the functionality of the ARP command. | ||
| - | ARP DROP is used to delete an entry from the table. | ||
| - | ARP FLUSH flushes temporary entries from the table. | ||
| - | ARP LEARN controls arp learning. | ||
| - | ARP LIST lists the table. | ||
| - | ARP MAXQ limits no. of datagrams queued pending resolution. | ||
| - | ARP PUBLISH adds an ARP proxy entry for a hidden system. | ||
| - | ARP TIMEOUT specifies max life of a dynamic entry (secs). | ||
| - | ARP WAIT specifies how many secs to wait for an ARP reply. | ||
| - | |||
| - | </ | ||
| - | ARP ADD 44.131.91.2 ax25 gb7pzt-5 | ||
| - | ARP DROP 44.131.91.7 ax25 Delete ax25 entry | ||
| - | ARP PUB 44.131.91.127 ax25 g8pzt | ||
| - | ARP TIMEOUT 30 Set 30 sec lifetime | ||
| - | ARP LEARN 2 ON | ||
| - | ARP LIST List the table | ||
| - | ARP List the table | ||
| - | |||
| - | </ | ||
| - | ARP PUBLISH is used when a host is " | ||
| - | which is only accessible via XRouter, and allows XRouter to | ||
| - | respond to ARP requests for the hidden system, by returning | ||
| - | its own hardware address. | ||
| - | |||
| - | The argument for "ARP CMD" is the sum of the desired options | ||
| - | from the following list:: | ||
| - | |||
| - | 1 = Command is available to secure sysops | ||
| - | 2 = Command is available to non-secure sysops | ||
| - | 4 = Command is available to users | ||
| - | 8 = Private addresses visible to secure sysops | ||
| - | 16 = Private addresses visible to non-secure sysops | ||
| - | 32 = Private addresses visible to all users | ||
| - | |||
| - | The default is 9 (secure sysops only). | ||
| - | A " | ||
| - | A " | ||
| - | |||
| - | ARP LEARN controls whether or not XRouter " | ||
| - | from passing ARP traffic. The default is for learning to be | ||
| - | ON, but it may be enabled/ | ||
| - | ARP LEARN DEFAULT [on | off]. | ||
| - | |||
| - | Regardless of the default setting, learning can be enabled or | ||
| - | disabled for any port, using ARP LEARN < | ||
| - | if not refreshed, learned entries persist for the interval | ||
| - | specified by TIMEOUT, usually 15 minutes. | ||
| - | |||
| - | ARP FLUSH removes temporary entries, i.e. those pending | ||
| - | resolution. The default lifetime for these entries is | ||
| - | specified by ARP WAIT (default 30 secs). | ||
| - | |||
| - | ARP MAXQ [0-32767] is used to limit the nunber of datagrams | ||
| - | which may be queued pending resolution. The default is 100. | ||
| - | If the address fails to resolve, the queued datagrams are | ||
| - | dropped. | ||
| - | | ||
| - | </ | ||
| - | The availability of the command is controlled by "ARP CMD", | ||
| - | which is detailed above. | ||
| - | |||
| - | </ | ||
| - | ARP commands to be executed at boot-up are usually placed in | ||
| - | IPROUTE.SYS, | ||
| - | |||
| - | </ | ||
| - | In order for this command to have any meaning, XRouter must | ||
| - | have an IP address and be connected to an IP-capable network. | ||
| - | |||
| - | You cannot add hardware address types for which there is no | ||
| - | compatible interface, e.g. an attempt to add an Ethernet | ||
| - | address on a system with no Ethernet interfaces will fail. | ||
| - | |||
| - | The defaults are as follows: | ||
| - | TIMEOUT=900 secs. WAIT=30 secs, MAXQ-100, CMD=9 | ||
| - | |||
| - | </ | ||
| - | ARP(9) -- Address Resolution Protocol | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====AXROUTES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | AXROUTES -- Display AX25 level 2 circuits | ||
| - | |||
| - | </ | ||
| - | AX[routes] [ < | ||
| - | |||
| - | </ | ||
| - | The AX[routes] command displays information about current | ||
| - | and recently active ax25 level 2 connections. | ||
| - | |||
| - | It allows the sysop to monitor the performance of the links | ||
| - | between XRouter and its users or peers. | ||
| - | |||
| - | Entries are purged 24 hours after they were last active, | ||
| - | unless they are " | ||
| - | callsign), i.e. in use by level 3. | ||
| - | |||
| - | The display shows the the port number and the remote | ||
| - | callsign, with a chevron ">" | ||
| - | link is currently active. | ||
| - | |||
| - | " | ||
| - | used on that link. They may be the same as the port or | ||
| - | global defaults, or they may have been dynamically modified | ||
| - | by XRouter to suit the link conditions | ||
| - | |||
| - | " | ||
| - | time from sending a packet to receiving an acknowledgement | ||
| - | for that packet. | ||
| - | as the packet size, how good the radio link is, the data | ||
| - | rate, the amount of queued data, the TXdelay and Resptime | ||
| - | intervals at each end etc... | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | | ||
| - | |||
| - | " | ||
| - | from the other end. | ||
| - | |||
| - | " | ||
| - | which would be seen by the other station. | ||
| - | |||
| - | Finally, Date/Time shows when the station was last heard. | ||
| - | |||
| - | </ | ||
| - | AX[routes] by itself | ||
| - | AX[routes] < | ||
| - | AX[routes] < | ||
| - | AX[routes] X shows sent/rcvd bytes and throughput. | ||
| - | |||
| - | </ | ||
| - | Sysop-only | ||
| - | |||
| - | </ | ||
| - | This facility was intended for the author' | ||
| - | It is likely to change or disappear altogether in future | ||
| - | versions. | ||
| - | |||
| - | </ | ||
| - | LINKS(1) | ||
| - | ROUTES(1) -- Display links with adjacent nodes | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BCAST.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BCAST -- Trigger a " | ||
| - | |||
| - | </ | ||
| - | BC[ast] < | ||
| - | |||
| - | </ | ||
| - | The BC[ast] command triggers an immediate NetRom " | ||
| - | broadcast on the specified port, speeding up the process | ||
| - | of neighbour discovery after a system restart. | ||
| - | |||
| - | If a broadcast is triggered with this command, the next | ||
| - | " | ||
| - | another NODESINTERVAL. | ||
| - | |||
| - | Although this command was intended for test purposes only, | ||
| - | it can also be used in CRONTAB.SYS for scheduling nodes | ||
| - | broadcasts at specific times, overriding the automatic | ||
| - | scheduler. This could for example be used to stagger the | ||
| - | broadcasts to reduce loading on a radio PSU for example. | ||
| - | |||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | This COMMAND should not be confused with the DIRECTIVE of | ||
| - | the same name, used in XROUTER.CFG, | ||
| - | purpose altogether. | ||
| - | |||
| - | </ | ||
| - | BCPOLL(1) | ||
| - | BCAST(9) | ||
| - | NODESINT(1) | ||
| - | CRONTAB.SYS(8) -- Events control file | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BCPOLL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BCPOLL -- Request " | ||
| - | |||
| - | </ | ||
| - | BCP[oll] < | ||
| - | |||
| - | </ | ||
| - | The BCP[oll] command requests a NetRom " | ||
| - | all neighbours on the specified port. This can speed up the | ||
| - | process of neighbour discovery after a system restart. | ||
| - | |||
| - | Upon receipt of this command, XRouter sends out a short | ||
| - | packet addressed to " | ||
| - | should recognise this packet, and begin broadcasting their | ||
| - | nodes list. | ||
| - | |||
| - | The responses may not be immediate. Nodes wait a random | ||
| - | interval up to 30 seconds before broadcasting, | ||
| - | collisons. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | BCAST(1) -- Trigger a nodes broadcast. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BELL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BELL -- Display / Set bell times. | ||
| - | |||
| - | </ | ||
| - | BE[ll] [h,h h-h] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The BELL command is used to display and set the hours during | ||
| - | which the console bells will sound. | ||
| - | connection (low-> | ||
| - | the 4 tone (Star Trek doorbell) sysop paging sound, and the | ||
| - | various bells associated with sysop chat. | ||
| - | |||
| - | Console sounds normally use the PC speaker, but Raspberry | ||
| - | Pi's and modern laptops don't have speakers. In such cases, | ||
| - | a sound device can be used instead (see AUDIO(9)). | ||
| - | |||
| - | </ | ||
| - | When used without arguments, the current times are displayed. | ||
| - | |||
| - | To set the bell times, the times may be supplied either as a | ||
| - | series of single hours, or in one or more ranges of times | ||
| - | e.g. " | ||
| - | |||
| - | </ | ||
| - | BELL 12 - Bells only between 12:00 and 12:59 | ||
| - | BELL 0-4, 12-23 - Allow bells between midday and 4am next day. | ||
| - | |||
| - | </ | ||
| - | Whatever the BELL setting, the console may still bleep if the | ||
| - | sysop tries to exceed a line length or delete back beyond | ||
| - | the start of a line. | ||
| - | |||
| - | </ | ||
| - | The default bell times are 08:00 to 22:59 inclusive. The BELL | ||
| - | command may be used in BOOTCMDS.SYS to override this | ||
| - | Alternatively the BELL= directive can be used in XROUTER.CFG, | ||
| - | like so... | ||
| - | |||
| - | # Acceptable bell hours, format n,n,n-n n etc | ||
| - | | ||
| - | |||
| - | </ | ||
| - | AUDIODEVICE(7) -- Specify audio device name | ||
| - | AUDIO(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BLEVEL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BLEVEL -- Netrom Budlist de-rate level. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | The BLEVEL command displays or sets the L3 " | ||
| - | This is the leakage level 0-255 for 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 directive of the same name can be used in XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | BLEVEL(7) | ||
| - | L3EXCLUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BLOG.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | BLOG -- Access Sysop' | ||
| - | |||
| - | </ | ||
| - | BL[og] [nodecall | nodealias] | ||
| - | |||
| - | </ | ||
| - | The BLOG command connects the user either to the sysop' | ||
| - | either at this node, or on another XRouter. | ||
| - | |||
| - | The blog is a text-only, packet radio version of an Internet | ||
| - | "web log". It is a space for sysops to post " | ||
| - | other people can " | ||
| - | |||
| - | Unlike the " | ||
| - | These have no size restrictions, | ||
| - | and markup. Anyone may add comments to an existing article. | ||
| - | Comments are not restricted in size. | ||
| - | |||
| - | Blog articles are not forwarded to other packet systems, but | ||
| - | may optionally be published to an MQTT broker. | ||
| - | |||
| - | The blog may also be operated via the sysop' | ||
| - | via MQTT, and via REST. | ||
| - | |||
| - | The BLOGFLAGS directive enables or disables the blog, and | ||
| - | controls whether the sysop is notified (via the PMS) of new | ||
| - | likes and replies. It also controls whether articles and | ||
| - | replies are published to the MQTT broker. | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied to the BLOG command, the user is | ||
| - | connected to the local blog. | ||
| - | |||
| - | If the argument is the nodecall or alias of another XRouter, | ||
| - | which is in the nodes table, the user is connected to the | ||
| - | blog of that node instead. | ||
| - | |||
| - | After connecting to the blog, the available commands are as | ||
| - | follows: | ||
| - | |||
| - | B[ye] | ||
| - | |||
| - | C[reate] | ||
| - | Text is entered in the same manner as for a PMS, | ||
| - | and is terminated by "/ | ||
| - | |||
| - | D[elete] | ||
| - | |||
| - | H[elp] | ||
| - | |||
| - | LIK[e] [n] (shortcut " | ||
| - | article you've just read, or article number " | ||
| - | |||
| - | L[ist] | ||
| - | up to 5 articles at a time. Headers are displayed | ||
| - | in reverse chronological order, i.e. the most | ||
| - | recent at the top. | ||
| - | |||
| - | N[ewer] | ||
| - | |||
| - | O[lder] | ||
| - | |||
| - | Q[uit] | ||
| - | |||
| - | R[ead] n Reads article number " | ||
| - | and use the number alone. | ||
| - | |||
| - | REP[ly] [n] (shortcut " | ||
| - | you've just read, or to article number " | ||
| - | |||
| - | V[iew] [n] View replies to current article, or article " | ||
| - | |||
| - | </ | ||
| - | BLOG -- Connect to the PMS on this node. | ||
| - | BLOG G8PZT -- Connect to the PMS on G8PZT node. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | A blog on Packet Radio might sound like a crazy idea, but is | ||
| - | it any crazier than a packet bulletin board? Even though there | ||
| - | are many Internet forums, people still run packet bulletin | ||
| - | boards! | ||
| - | |||
| - | There are millions of blogs on the Internet, but can you | ||
| - | remember all the URL's? Will they still be there tomorrow? Are | ||
| - | they riddled with cookies, trojans and clickbait? Are they | ||
| - | easy to use? Shouldn' | ||
| - | |||
| - | In order to survive, Packet Radio needs CONTENT. There' | ||
| - | point having a network if that network has nothing to do. The | ||
| - | purpose of a network is to move DATA. A blog is just another | ||
| - | form of data. It gives people a reason to use the network. | ||
| - | |||
| - | The Sysop' | ||
| - | toolbox. Hopefully some sysops may contribute their thoughts, | ||
| - | and others will find them interesting and thought provoking, | ||
| - | but you don't have to use it. | ||
| - | |||
| - | </ | ||
| - | BLOGFLAGS(7) | ||
| - | MQTT-BLOG(9) | ||
| - | MQTT-SRV(9) | ||
| - | PMS(1) | ||
| - | REST-BLOG(9) | ||
| - | WALL(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====BYE.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | BYE -- Disconnect from the router. | ||
| - | |||
| - | </ | ||
| - | B[ye] | ||
| - | |||
| - | </ | ||
| - | The BYE command causes XRouter to terminate the uplink. | ||
| - | |||
| - | It is particularly useful when a user cannot terminate the | ||
| - | connection locally, e.g. if there' | ||
| - | TNC's " | ||
| - | with the " | ||
| - | |||
| - | The disconnection occurs only after all outstanding data has | ||
| - | been sent to the user. | ||
| - | |||
| - | Disconnectiing the uplink terminates all dependent sessions. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | QUIT(1) -- Disconnect from the router | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CAPTURE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CAPTURE -- Enable / disable tracing to disk file. | ||
| - | |||
| - | </ | ||
| - | CAP[TURE] [on | off] | ||
| - | |||
| - | </ | ||
| - | The CAPTURE command is used to enable or disable the capture | ||
| - | to disk file of incoming and outgoing traffic. | ||
| - | |||
| - | When capture is enabled, anything which is displayed in the | ||
| - | central window of an XRouter console is also written to disk. | ||
| - | This includes session activity and TRACE' | ||
| - | screen display is filtered to prevent it being garbled by | ||
| - | binary data, the capture is pure binary, so it is useful for | ||
| - | diagnostics. | ||
| - | |||
| - | The optional argument may be " | ||
| - | supplied, the current setting is reported. | ||
| - | |||
| - | This command overrides the <F5> (toggle capture) key. | ||
| - | |||
| - | There is a seperate capture file for each XRouter " | ||
| - | named CAPTURnn.TXT where nn represents the console number (01 | ||
| - | to 05). | ||
| - | |||
| - | Capture is fully independent on each console, and consoles may | ||
| - | be captured concurrently. Switching between consoles, or | ||
| - | scrolling consoles back, does not affect the capture. | ||
| - | |||
| - | </ | ||
| - | CAP ON - Enables capture. | ||
| - | |||
| - | </ | ||
| - | Cconsole and remote sysops only. | ||
| - | |||
| - | </ | ||
| - | The CAPTUREnn.TXT files are created in the XRouter working | ||
| - | directory. Although they have the extension " | ||
| - | them to be easily opened with Notepad, they may sometimes | ||
| - | contain characters which Notepad can't display. | ||
| - | |||
| - | </ | ||
| - | MONITOR(1) -- Controls protocol tracing | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CFLAGS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CFLAGS -- Display / Change Connection Control Flags. | ||
| - | |||
| - | </ | ||
| - | CF[lags] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | CFLAGS is a port configuration command, whose primary | ||
| - | function is to control whether or not AX25 level 2 | ||
| - | uplinking and/or downlinking is allowed on the port. | ||
| - | |||
| - | 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. | ||
| - | |||
| - | A directive of the same name can be used in PORT config | ||
| - | blocks within XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | 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 4 - Display current value for port 4 | ||
| - | CF 4 5 - Only sysops and apps can downlink on port 4. | ||
| - | | ||
| - | </ | ||
| - | CFLAGS(7) | ||
| - | L2FRAG(9) | ||
| - | L3RTT(9) | ||
| - | FEC(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHATCMD2.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ========================== | ||
| - | |||
| - | </ | ||
| - | |||
| - | /? / | ||
| - | /EXIT / | ||
| - | / | ||
| - | /QTH /QUIT / | ||
| - | / | ||
| - | |||
| - | |||
| - | </ | ||
| - | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| - | |||
| - | /MSG --- Send a short message to a channel or a single user. | ||
| - | |||
| - | | ||
| - | |||
| - | The /Msg command is used to send a short message (70 chars | ||
| - | max.) to any specified channel or single user. You may for | ||
| - | | ||
| - | are monitoring, but not actually logged to. | ||
| - | |||
| - | If you direct a message to a specific user, he may be on this | ||
| - | or any other chat server. | ||
| - | will be indicated to the recipient by asterisks around the | ||
| - | | ||
| - | | ||
| - | |||
| - | If the target user's server is specified in the command, and | ||
| - | the user isn't currently logged on, the message will be | ||
| - | | ||
| - | shout on 'KD when you read this.." | ||
| - | |||
| - | | ||
| - | /M g6yak Meet me on channel 69 | ||
| - | /M g6yak@kdrcht See u on KD later | ||
| - | |||
| - | The first form sends "Hello People" | ||
| - | | ||
| - | only. Providing G6YAK is logged on to any chat server, the | ||
| - | | ||
| - | to G6YAK on the KDRCHT server. If G6YAK is not currently | ||
| - | | ||
| - | |||
| - | Note: As with all things Packet, the term " | ||
| - | | ||
| - | |||
| - | |||
| - | /NAME -- Set name. | ||
| - | |||
| - | | ||
| - | |||
| - | The /NAME command sets the user's name, which will be | ||
| - | | ||
| - | sends to others. | ||
| - | |||
| - | Users are not allowed to join any channels until they have | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | On the first use of this command, the user may optionally | ||
| - | | ||
| - | |||
| - | | ||
| - | enter their callsign. | ||
| - | |||
| - | | ||
| - | /N Paula 23 Set name and join channel 23 | ||
| - | |||
| - | |||
| - | /NODES - Display RoundTable nodes | ||
| - | |||
| - | | ||
| - | |||
| - | The /NODES command displays a detailed list of the known | ||
| - | | ||
| - | the function of the /K command. | ||
| - | |||
| - | The display includes the node call and alias, plus the | ||
| - | | ||
| - | |||
| - | |||
| - | /PERSONAL - Display / change personal description. | ||
| - | |||
| - | | ||
| - | |||
| - | The /PERSONAL command is used to display or change the user' | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | (i.e. those above channel 255), this information will appear | ||
| - | on the user lists of all other chat servers. | ||
| - | |||
| - | If used without arguments, the /PERSONAL command displays the | ||
| - | | ||
| - | |||
| - | If the argument is " | ||
| - | |||
| - | | ||
| - | /P Kidderminster, | ||
| - | /P @ - Clear previous text. | ||
| - | |||
| - | |||
| - | /QTH --- Display / set QTH. | ||
| - | |||
| - | | ||
| - | |||
| - | The /QTH command is used to set your QTH. QTH is not | ||
| - | | ||
| - | if you log in to room 101 (RoundTable/ | ||
| - | |||
| - | | ||
| - | /Q Weston Super Mare - Sets new QTH. | ||
| - | |||
| - | Note: QTH may include spaces, and can be up to 64 characters. | ||
| - | |||
| - | |||
| - | /QUIT -- Exit the chat server. | ||
| - | |||
| - | | ||
| - | |||
| - | The /QUIT command, which may be shortened to /Q, disconnects | ||
| - | the user from the chat server, and informs everyone that he' | ||
| - | | ||
| - | | ||
| - | |||
| - | If the user accessed the server via the router' | ||
| - | | ||
| - | | ||
| - | |||
| - | The /BYE and /EXIT commands also perform this function. | ||
| - | |||
| - | |||
| - | /RECENT - Display Recent Messages | ||
| - | |||
| - | | ||
| - | |||
| - | The /RECENT command displays the last 10 messages received | ||
| - | in the last 24 hours. | ||
| - | |||
| - | | ||
| - | /RE 1234 - Recent messages from channel 1234 | ||
| - | |||
| - | The purpose of this command is to display messages that you | ||
| - | might have missed while you weren' | ||
| - | to conduct non-real-time conversations. | ||
| - | |||
| - | | ||
| - | |||
| - | |||
| - | /RM ---- ReadMail | ||
| - | |||
| - | | ||
| - | |||
| - | The /RM (ReadMail) command is used to read any personal | ||
| - | | ||
| - | |||
| - | If someone sends a certain type of personal chat message to | ||
| - | a user while he isn't logged in, that message is stored | ||
| - | on the chat server, and he is notified when he next logs | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | |||
| - | /STAMP - Controls timestamping of message texts. | ||
| - | |||
| - | | ||
| - | |||
| - | With stamp ON (default) each mesage is timestamped in the | ||
| - | | ||
| - | by client software: | ||
| - | |||
| - | | ||
| - | |||
| - | The first field is the channel number. | ||
| - | | ||
| - | to more than one channel! | ||
| - | |||
| - | The second field is the chatserver' | ||
| - | local time the message was received at, and redistributed by, | ||
| - | the server. | ||
| - | for a while, or are logging the activity to disk. | ||
| - | |||
| - | The third field is the originating server' | ||
| - | the local time at which the message was entered into the | ||
| - | | ||
| - | two timestamps may differ by up to 12 hours. | ||
| - | find it useful to know what the other user's local time is, | ||
| - | | ||
| - | | ||
| - | |||
| - | The fourth field consists of the sender' | ||
| - | " | ||
| - | log onto more than one server, often at the same time. | ||
| - | |||
| - | The fifth field is the user's name. | ||
| - | |||
| - | Those who are used to chatting on the Ping-Pong system seem | ||
| - | to be unable to cope with anything which is different, so | ||
| - | with STAMP OFF the header information is abbreviated in the | ||
| - | | ||
| - | |||
| - | < | ||
| - | |||
| - | |||
| - | /TOPIC - Display / Change channel topic. | ||
| - | |||
| - | | ||
| - | |||
| - | Every channel has an optional topic, and the /TOPIC command | ||
| - | can be used to display the existing topic or change it. The | ||
| - | topic can be up to 12 characters, and is displayed on the | ||
| - | /Who list. | ||
| - | |||
| - | | ||
| - | /T 32 - Show channel 32 topic | ||
| - | /T 32 TCP/IP discussion | ||
| - | /T @ - Clear topic. | ||
| - | |||
| - | |||
| - | /USER -- TCP/IP logon. | ||
| - | |||
| - | | ||
| - | |||
| - | The /USER command is available only to TCP/IP users. | ||
| - | the user's callsign (and optionally his name), which will be | ||
| - | | ||
| - | sends to others. | ||
| - | |||
| - | The user will not be able to join the conference without | ||
| - | | ||
| - | max), but if the name is omitted from this command he may | ||
| - | enter it in the normal way with the /Name command. | ||
| - | |||
| - | | ||
| - | /U g8pzt Paula - Set callsign and name. | ||
| - | |||
| - | |||
| - | /USERS - Display RoundTable/ | ||
| - | |||
| - | | ||
| - | |||
| - | The /USERS command is available only when logged to the | ||
| - | | ||
| - | users currently logged into the RoundTable/ | ||
| - | |||
| - | For each user, the callsign, name and QTH are displayed, | ||
| - | | ||
| - | in. | ||
| - | |||
| - | |||
| - | /VERBOSE - Enable / disable Verbose alerts | ||
| - | |||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | This is primarily of use to GUI clients, allowing them to | ||
| - | build and maintain their own lists of who's on what channel. | ||
| - | |||
| - | |||
| - | /VERSION - Display chat server version. | ||
| - | |||
| - | | ||
| - | |||
| - | The /VERSION command displays the chat server version, author | ||
| - | and compilation date. Please quote it if reporting bugs. | ||
| - | |||
| - | |||
| - | /WHO --- List channels and users. | ||
| - | |||
| - | | ||
| - | |||
| - | The /WHO command lists who is logged onto the chat server, | ||
| - | and what channels they are on. | ||
| - | |||
| - | If no arguments are supplied, the active channels are listed, | ||
| - | along with the callsigns of their users. | ||
| - | |||
| - | If an asterisk is supplied as the argument, each user is | ||
| - | | ||
| - | the user's callsign, name, personal text and logon date/time. | ||
| - | |||
| - | | ||
| - | /W * Lists users in detail | ||
| - | |||
| - | |||
| - | </ | ||
| - | CHAT(1) | ||
| - | CHATCMDS(1) -- Chat server commands A-M | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHATCMDS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ========================== | ||
| - | |||
| - | </ | ||
| - | |||
| - | /? / | ||
| - | /EXIT / | ||
| - | / | ||
| - | /QTH /QUIT / | ||
| - | / | ||
| - | |||
| - | |||
| - | </ | ||
| - | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| - | |||
| - | /? ----- Display commands / syntax help. | ||
| - | |||
| - | | ||
| - | |||
| - | When used without arguments, the /? command lists the | ||
| - | | ||
| - | | ||
| - | to the /? command. | ||
| - | |||
| - | | ||
| - | /? /who | ||
| - | |||
| - | |||
| - | /ALERT - Enable / Disable channel join/leave alerts | ||
| - | |||
| - | | ||
| - | |||
| - | | ||
| - | / | ||
| - | |||
| - | If ALERT is ON, the server sends you a notification every | ||
| - | time someone joins or leaves the channel (room) you are in. | ||
| - | This is the default setting. | ||
| - | |||
| - | |||
| - | /ANSI -- Enable / Disable ANSI colour | ||
| - | |||
| - | | ||
| - | |||
| - | The /ANSI command is used to enable or disable the use of | ||
| - | ANSI colour. | ||
| - | must be using an ansi-compatible terminal. | ||
| - | each user's messages are shown in a different colour making | ||
| - | it easier to follow threads of conversation. | ||
| - | |||
| - | | ||
| - | |||
| - | |||
| - | /BELL -- Display / Set activity bell | ||
| - | |||
| - | | ||
| - | |||
| - | The /BELL command controls which events are signalled by an | ||
| - | | ||
| - | | ||
| - | your terminal software must respond to bell characters. | ||
| - | |||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | |||
| - | /BYE --- Exit the chat server. | ||
| - | |||
| - | | ||
| - | |||
| - | The /BYE command, which may be shortened to /B, disconnects | ||
| - | the user from the chat server, and informs everyone that he' | ||
| - | | ||
| - | | ||
| - | |||
| - | If the user accessed the server via the router' | ||
| - | | ||
| - | | ||
| - | |||
| - | The /EXIT and /QUIT commands also perform this function. | ||
| - | |||
| - | |||
| - | /CHANNEL - Display / Change logged channel(s). | ||
| - | |||
| - | | ||
| - | |||
| - | The /CHANNEL command displays / changes the channel(s) the | ||
| - | user is logged to. When no argument is supplied, the logged | ||
| - | | ||
| - | is supplied, the user is logged to the specified channel. | ||
| - | |||
| - | | ||
| - | /C 22 Change to channel 22 | ||
| - | /C default 1234 Default to channel 1234. | ||
| - | |||
| - | When a new channel is selected, the user remains logged to | ||
| - | any previous channels, (so he can " | ||
| - | at once) but any subsequent text he sends will go to the new | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | If a connection with the "Tampa Ping-Pong converse" | ||
| - | | ||
| - | | ||
| - | as local channels. | ||
| - | |||
| - | The default channel at log-on is 1000. You may check or | ||
| - | | ||
| - | |||
| - | The /JOIN command has a similar function, and /LEAVE is used | ||
| - | to de-select unwanted channels. | ||
| - | |||
| - | |||
| - | /ECHO -- Control host echo | ||
| - | |||
| - | | ||
| - | |||
| - | The /ECHO command toggles host echo on and off. The default | ||
| - | | ||
| - | sends to the channel. | ||
| - | |||
| - | | ||
| - | helps to put the user's text into temporal context amongst | ||
| - | the other channel texts, especially when there is latency on | ||
| - | the links. | ||
| - | | ||
| - | |||
| - | |||
| - | /EXIT -- Exit the chat server. | ||
| - | |||
| - | | ||
| - | |||
| - | The /EXIT command, which may be shortened to /E, disconnects | ||
| - | the user from the chat server, and informs everyone that he' | ||
| - | | ||
| - | | ||
| - | |||
| - | If the user accessed the server via the router' | ||
| - | | ||
| - | | ||
| - | |||
| - | The /BYE and /QUIT commands also perform this function. | ||
| - | |||
| - | |||
| - | /HEADERLN Controls display format | ||
| - | |||
| - | | ||
| - | |||
| - | The /HEADERLN command controls whether or not the " | ||
| - | and text of messages are displayed on the same line. | ||
| - | |||
| - | If the setting is OFF (default), the header and text are | ||
| - | | ||
| - | | ||
| - | |||
| - | If the setting is ON, headers and text are displayed on | ||
| - | | ||
| - | |||
| - | |||
| - | /HELP -- Obtain help. | ||
| - | |||
| - | | ||
| - | |||
| - | When used without arguments, the /HELP command gives brief | ||
| - | | ||
| - | |||
| - | If a topic is specified, detailed help for that topic (if | ||
| - | | ||
| - | any other chat server related topic. | ||
| - | help topics can be obtained by specifying " | ||
| - | |||
| - | | ||
| - | /H * List available help topics. | ||
| - | /H /who | ||
| - | |||
| - | | ||
| - | | ||
| - | "/ | ||
| - | |||
| - | |||
| - | /JOIN -- Join (log onto) a channel. | ||
| - | |||
| - | | ||
| - | |||
| - | The /JOIN command logs the user to a channel, and performs a | ||
| - | | ||
| - | |||
| - | When a new channel is selected, the user remains logged to | ||
| - | any previous channels, (so he can " | ||
| - | at once) but any subsequent text he sends will go to the new | ||
| - | | ||
| - | be de-selected using the complementary /LEAVE command.) | ||
| - | |||
| - | | ||
| - | |||
| - | See /CHANNELS for a description of the channels. | ||
| - | |||
| - | /KEEPALIVE - Enables / disables link "keep alive" messages. | ||
| - | |||
| - | | ||
| - | |||
| - | | ||
| - | /KE ON Turns keepalives on. | ||
| - | |||
| - | There is no time-out on connections with XRchat, BUT if you | ||
| - | are connected for long periods with no activity, some part | ||
| - | of the link you are using may time out. For example, a NAT | ||
| - | entry may time out, or an inter-node link may disconnect. | ||
| - | Keep alive messages are intended to keep such links open, | ||
| - | by sending a short text every 10 minutes. | ||
| - | |||
| - | If you are monitoring for long periods, the keepalives may | ||
| - | | ||
| - | |||
| - | /KM ---- Kill Mail | ||
| - | |||
| - | | ||
| - | |||
| - | The /KM (KillMail) command is used to delete personal | ||
| - | | ||
| - | |||
| - | If someone sends you a certain type of personal chat message | ||
| - | while you are not logged in, that message is stored at your | ||
| - | | ||
| - | may then use the /RM command to read the messages, and the | ||
| - | /KM command to delete them afterwards. | ||
| - | |||
| - | |||
| - | /KNOWN - Known Nodes | ||
| - | |||
| - | | ||
| - | |||
| - | The /KNOWN command, which may be shortened to /K, is used | ||
| - | to display a detailed list of the known RoundTable nodes. | ||
| - | The display includes the node call and alias, plus the | ||
| - | | ||
| - | |||
| - | |||
| - | /LEAVE - Leave (log off) a channel. | ||
| - | |||
| - | | ||
| - | |||
| - | The /LEAVE command logs the user off the specified channel. | ||
| - | When a user joins a channel, he remains logged to any | ||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | |||
| - | |||
| - | /LINKS - Display / Change peer links | ||
| - | |||
| - | | ||
| - | / | ||
| - | / | ||
| - | / | ||
| - | |||
| - | The /LINKS command shows the status of the links with other | ||
| - | chat servers, and allows sysops to add and drop links without | ||
| - | | ||
| - | |||
| - | "/ | ||
| - | and other severs. The fields are as follows: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | "/ | ||
| - | chat links, whether they are currently connected or not. | ||
| - | |||
| - | "/ | ||
| - | one for NetRom links and one for TCP/IP links. | ||
| - | |||
| - | In the Netrom case, < | ||
| - | | ||
| - | nodes table otherwise the link will not be opened. | ||
| - | have trouble with peers dropping in and out of the nodes | ||
| - | | ||
| - | |||
| - | In order to define a link with a RoundTable/ | ||
| - | the callsign must be prefixed with a ' | ||
| - | The link will not be allowed unless both callsign and alias | ||
| - | are in the nodes table. | ||
| - | |||
| - | In the TCP/IP case, < | ||
| - | | ||
| - | is the TCP port number of the server. | ||
| - | |||
| - | | ||
| - | /LI DROP G8NTU-8 | ||
| - | /LI ADD brmcht 80.195.22.37: | ||
| - | |||
| - | |||
| - | </ | ||
| - | CHAT(1) -- Start a chat session | ||
| - | CHATCMD2(1) -- Chat Commands in detail (M-Z) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CHAT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CHAT -- Connect to Chat Server. | ||
| - | |||
| - | </ | ||
| - | CH[at] [nodecall] | ||
| - | |||
| - | </ | ||
| - | Available to all users except guests. | ||
| - | |||
| - | </ | ||
| - | CHAT used by itself connects you to the integral chat server, | ||
| - | allowing you to conduct conferences with one or more other | ||
| - | users. | ||
| - | |||
| - | The "CHAT nodecall" | ||
| - | to the chat server on another XRouter, providing that | ||
| - | [nodecall] is in our nodes table. | ||
| - | |||
| - | The chat server has its own set of commands, which are | ||
| - | detailed separately in the CHATCMDS manual entry. | ||
| - | |||
| - | There are 65536 separate channels (or " | ||
| - | first 256 (*except room 101) are local to this system, and | ||
| - | the remainder may be linked to other systems, allowing | ||
| - | widely separated users to chat. | ||
| - | |||
| - | (*Room 101 links to RoundTable/ | ||
| - | links have been defined) | ||
| - | |||
| - | In addition to the " | ||
| - | another 32768 channels numbered 0 to -32767. | ||
| - | correspond to channels 0 to 32767 on the "Tampa Ping Pong" | ||
| - | system. | ||
| - | |||
| - | </ | ||
| - | The chat server may also be reached by connecting to its | ||
| - | own callsign, either directly or through the Netrom network, | ||
| - | or by telnetting to TCP port 3600 (or whatever it has been | ||
| - | relocated to), or by connecting to NetRomX service number 2. | ||
| - | |||
| - | Sysops have a " | ||
| - | themselves, and there is a "chat monitor" | ||
| - | an eye on chat activity. | ||
| - | |||
| - | </ | ||
| - | CHATCMDS(1) -- Chat server commands. | ||
| - | CHAT-SRV(9) -- About the chat server. | ||
| - | CHAT-SVC(9) -- NetRomX Chat Service. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CMD.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | COMMAND -- CMD. | ||
| - | |||
| - | </ | ||
| - | CM[d] <ADD | DROP> < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The CMD command is used to add or delete " | ||
| - | i.e. sysop-defined commands that translate to a simple | ||
| - | command sequence. | ||
| - | |||
| - | This would typically be used to add a " | ||
| - | maps to "C 1 VK1BTR-13" | ||
| - | |||
| - | There is no limit to the number of command aliases which may | ||
| - | be defined. | ||
| - | |||
| - | </ | ||
| - | "CMD ADD < | ||
| - | < | ||
| - | |||
| - | "CMD DROP < | ||
| - | |||
| - | </ | ||
| - | cmd add kidder c 1 kdrnod-1 | ||
| - | cmd drop kidder | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CONNECT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CONNECT -- Make an outgoing AX25 connection | ||
| - | |||
| - | </ | ||
| - | C[onnect] [port] < | ||
| - | |||
| - | </ | ||
| - | The CONNECT command, which may be abbreviated to " | ||
| - | instructs XRouter to make an outgoing (downlink) AX25 level | ||
| - | 2 or 4 connection with another system. | ||
| - | |||
| - | If the target is a known node (i.e. one which is in the nodes | ||
| - | table) a port number is not required, and will be ignored if | ||
| - | supplied. | ||
| - | connection with the target, using information from the | ||
| - | routing tables. | ||
| - | |||
| - | To override the above mechanism and " | ||
| - | connection with an immediately adjacent node, either of the | ||
| - | following methods can be used: | ||
| - | | ||
| - | (a) by appending an arbitrary SSID to the target' | ||
| - | specifying a port number if required, e.g. "C 4 MLVN-1" | ||
| - | |||
| - | (b) by prefixing the target call with an exclamation mark, | ||
| - | and specifying a port if required, e.g. "C 4 !G4FPV" | ||
| - | |||
| - | If the target is NOT a known node, XRouter will attempt to | ||
| - | make a level 2 connection. | ||
| - | number must be specified. | ||
| - | |||
| - | The " | ||
| - | specified, e.g.: "C 3 G6YAK V G8NTU G8EPR" | ||
| - | |||
| - | The " | ||
| - | uplink session to stay connected when the downlink session to | ||
| - | the target node is terminated. | ||
| - | |||
| - | The [svcnum] parameter specifies the " | ||
| - | target system. This is only understood by XRouter nodes at | ||
| - | present. It causes a " | ||
| - | connection to one of 65535 possible " | ||
| - | target system. The service numbers are " | ||
| - | "well known" port numbers in TCP and UDP. For example, | ||
| - | service 0 is always the node's command line, service 1 is | ||
| - | always an " | ||
| - | service 8 is always a chat server, and so on. See the | ||
| - | SERVICES manual page for a full list. | ||
| - | |||
| - | </ | ||
| - | C GLOS - Level 4 connect to GLOS:GB7GH node | ||
| - | C 4 MLVN-1 | ||
| - | C 3 G6YAK - Level 2 connect to non-node G6YAK on port 3 | ||
| - | C KIDDER 8 - L4 connect to service 8 (chat) on KIDDER node | ||
| - | C G8PZT 1 S - L4 connect to service 1, then stay connected | ||
| - | |||
| - | </ | ||
| - | If more than 7 digipeaters are specified, only the first 7 | ||
| - | will be used. | ||
| - | |||
| - | </ | ||
| - | This command is available to everyone, with the exception of | ||
| - | " | ||
| - | public internet without supplying a password. | ||
| - | |||
| - | </ | ||
| - | CX(1) -- Connect using Extended Ax25 | ||
| - | SERVICES(9) -- Standard Service Numbers | ||
| - | TELNET(1) | ||
| - | TTYLINK(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CQ.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | CQ -- Send a CQ Message. | ||
| - | |||
| - | </ | ||
| - | CQ [v[ia] digi, | ||
| - | |||
| - | </ | ||
| - | The CQ command can only be used in LISTEN mode. It sends a | ||
| - | " | ||
| - | being LISTENed to. Optional text and digipeater path may be | ||
| - | supplied. | ||
| - | |||
| - | The message is sent only once, but the command may be repated | ||
| - | at suitable intervals. | ||
| - | |||
| - | </ | ||
| - | The digipeater list, if included, must not include spaces, | ||
| - | but there should be space between the V[ia] and the list. | ||
| - | |||
| - | </ | ||
| - | CQ | ||
| - | CQ Parks on the air | ||
| - | CQ v g8pzt,m0wof Gloucester Docks | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | LISTEN - Invoke Listen mode. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CTEXT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CTEXT -- Display or Set Port " | ||
| - | |||
| - | </ | ||
| - | CT[ext] < | ||
| - | |||
| - | </ | ||
| - | CTEXT < | ||
| - | |||
| - | CTEXT < | ||
| - | |||
| - | CTEXT < | ||
| - | |||
| - | CTEXT < | ||
| - | |||
| - | CTEXT < | ||
| - | |||
| - | CTEXT < | ||
| - | |||
| - | </ | ||
| - | The CTEXT command displays or sets the " | ||
| - | the specified PORT. This is a single or multi-line text that | ||
| - | can be sent to a caller when they connect to the port. The | ||
| - | companion command CTFLAGS controls which callers receive the | ||
| - | text. | ||
| - | |||
| - | If a port-specific CTEXT exists, it overrides the global | ||
| - | CTEXT, on that port only. | ||
| - | |||
| - | Connect texts are usually configured using CTEXT directives | ||
| - | in XROUTER.CFG. The CTEXT *command* allows the texts to be | ||
| - | changed "on the fly". | ||
| - | |||
| - | Upon bootup, if a port CTEXT is not specified in XROUTER.CFG, | ||
| - | XRouter looks for the file CTEXTn.SYS, whcre n is the port | ||
| - | number. If the file is found, the contents are loaded. | ||
| - | Otherwise the global ctext (if any) is inherited by the port. | ||
| - | |||
| - | If the contents of CTEXTn.SYS is changed during runtime, | ||
| - | they can be reloaded into memory using the LOAD sub-command. | ||
| - | Or if the text is changed using the CTEXT command, it can be | ||
| - | stored for the future, using the SAVE sub-command. | ||
| - | |||
| - | The CLEAR subcommand erases any text stored in memory. | ||
| - | |||
| - | Single line ctexts can be added with either NEW or ADD. The | ||
| - | former clears any existing text. The latter is OK if there | ||
| - | is no existing text. | ||
| - | |||
| - | If < | ||
| - | are read " | ||
| - | ideal for " | ||
| - | scenarios. That 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 5 new / | ||
| - | |||
| - | CTEXT 6 new ctext-news.txt | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | There is also a DIRECTIVE of the same name, used in | ||
| - | XROUTER.CFG, | ||
| - | |||
| - | </ | ||
| - | CTEXT(7) | ||
| - | CTFLAGS(1) | ||
| - | CTFLAGS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CTFLAGS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CTFLAGS -- Display / Set Connection Text Control Flags. | ||
| - | |||
| - | </ | ||
| - | CTF[lags] < | ||
| - | |||
| - | </ | ||
| - | The CTFLAGS command controls which callers are sent a | ||
| - | " | ||
| - | |||
| - | < | ||
| - | applies. Port 0 displays/ | ||
| - | which is used for all ports without a specific override. | ||
| - | |||
| - | [value] is the sum of the desired options from the following | ||
| - | list (options 4 and 8 apply to global ctflags only): | ||
| - | |||
| - | 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). | ||
| - | |||
| - | Setting a value of 0 disables CTEXT entirely. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | There is a DIRECTIVE of the same name, used in XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | CTEXT(1) | ||
| - | CTEXT(7) | ||
| - | CTFLAGS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CTRL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CTRL -- Read / Write remote hardware control port. | ||
| - | |||
| - | </ | ||
| - | Syntax: CTRL [0-255] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The CTRL command reads from and writes to the CTRL port | ||
| - | defined in the CFG file (e.g. CTRL=0378 to use LPT1). | ||
| - | used for controlling external hardware devices via logic, and | ||
| - | reading status from them, for example transmitter bank | ||
| - | switching or temperature alarm monitoring. | ||
| - | |||
| - | </ | ||
| - | " | ||
| - | |||
| - | The read value is the bitwise OR of last written value and | ||
| - | external levels, so a bit must be written to 0 in order to use | ||
| - | it as an input. | ||
| - | |||
| - | </ | ||
| - | CTRL 127 - Write a 1 to bit 7 of ctrl port. | ||
| - | |||
| - | </ | ||
| - | This page applies only to the DOS version! LPT ports are a | ||
| - | thing of the past, so this will be repurposed to use other | ||
| - | hardware, such as GPIO pins. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====CX.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | CX -- Make Outgoing AX25L2 Connection Using Modulo-128 | ||
| - | |||
| - | </ | ||
| - | CX [port] < | ||
| - | |||
| - | </ | ||
| - | The CX (Connect eXtended) command instructs XRouter to make | ||
| - | an outgoing (downlink) AX25 level 2 connection with another | ||
| - | system. | ||
| - | |||
| - | It is very similar to the normal " | ||
| - | that it ignores NetRom, and attempts layer 2 connections | ||
| - | using " | ||
| - | |||
| - | If the target system is not capable of, or does not wish to | ||
| - | use EAX25, it will answer with <DM> and XRouter will revert | ||
| - | to regular AX25. | ||
| - | |||
| - | </ | ||
| - | On multi-port systems, a port number must be specified | ||
| - | before the target callsign. | ||
| - | |||
| - | The " | ||
| - | specified, e.g.: "C 3 G6YAK V G8NTU G8EPR" | ||
| - | |||
| - | The " | ||
| - | uplink session to stay connected when the downlink session | ||
| - | to the target station is terminated. | ||
| - | |||
| - | </ | ||
| - | CX 4 MLVN-1 | ||
| - | CX 3 G6YAK - Level 2 connect to G6YAK on port 3 | ||
| - | |||
| - | </ | ||
| - | If more than 7 digipeaters are specified, only the first 7 | ||
| - | will be used. | ||
| - | |||
| - | </ | ||
| - | This command is available to everyone, with the exception of | ||
| - | " | ||
| - | public internet without supplying a password. | ||
| - | |||
| - | </ | ||
| - | CONNECT(1) | ||
| - | MOD128(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DATE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DATE -- Enquire / set system date | ||
| - | |||
| - | </ | ||
| - | DATE [dd/ | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied, the existing system date is shown. | ||
| - | |||
| - | If the argument is a valid date of form dd/mm/yy or dd/mm/yyyy | ||
| - | the system date is set to the new value. | ||
| - | |||
| - | </ | ||
| - | DATE 24/2/99 | ||
| - | |||
| - | </ | ||
| - | The DATE command is available only to sysops. | ||
| - | |||
| - | </ | ||
| - | TIME(1) -- Show time at any XRouter / Set time here. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DHCP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DHCP -- Display DHCP-obtained IP configuration parameters. | ||
| - | |||
| - | </ | ||
| - | DHCP < | ||
| - | |||
| - | </ | ||
| - | Sysop-only | ||
| - | |||
| - | </ | ||
| - | For ports on which the DHCP Dynamic Host Configuration | ||
| - | Protocol) client is enabled, the DHCP command displays the | ||
| - | IP configuration parameters which have been obtained via DHCP. | ||
| - | |||
| - | Parameters displayed include: IP address, DHCP server | ||
| - | address, gateway IP address, primary DNS address, lease | ||
| - | expiry time, and DHCP state. | ||
| - | |||
| - | States are as follows: | ||
| - | |||
| - | INIT - Initial state, no IP address yet. | ||
| - | SELECTING | ||
| - | REQUESTING | ||
| - | BOUND - Lease obtained, OK to use. | ||
| - | RENEWING | ||
| - | REBINDING | ||
| - | |||
| - | </ | ||
| - | When the only argument is a port number, the DHCP settings | ||
| - | for that port are displayed. | ||
| - | |||
| - | The BIND option isn't curently implemented, | ||
| - | automatically binds. | ||
| - | |||
| - | The RELEASE option forces the client to release the current | ||
| - | configuration. | ||
| - | |||
| - | The TRACE option displays or sets the DHCP trace flags. Use | ||
| - | a non-zero value to enable tracing, or zero to disable it. | ||
| - | Tracing is enabled by default. | ||
| - | |||
| - | </ | ||
| - | DHCP 3 - Display DHCP settings for port 3 | ||
| - | DHCP 3 RELEASE | ||
| - | DHCP 3 TRACE 0 - Disable DHCP tracing on port 3 | ||
| - | |||
| - | </ | ||
| - | DHCP is enabled by including the " | ||
| - | relevant PORT block within XROUTER.CFG. | ||
| - | |||
| - | </ | ||
| - | The use of dynamic IP addressing for XRouter is strongly | ||
| - | deprecated, as so many of its servers and protocols require | ||
| - | "port forwarding", | ||
| - | keeps changing! | ||
| - | | ||
| - | </ | ||
| - | ---- | ||
| - | =====DIAL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DIAL -- Dial a PSTN connection. | ||
| - | |||
| - | </ | ||
| - | DIA[l] < | ||
| - | |||
| - | </ | ||
| - | The DIAL command invokes the named Dial Up Networking (DUN) | ||
| - | script on the specified port, to establish a land-line | ||
| - | connection with another system. | ||
| - | |||
| - | This command has no effect unless the port is connected to a | ||
| - | PSTN modem, the interface protocol is defined as MODEM, and | ||
| - | the script file exists. | ||
| - | |||
| - | </ | ||
| - | DIAL 1 AOL.SCR | ||
| - | |||
| - | </ | ||
| - | The dialer uses script files which contain commands such as | ||
| - | SEND, WAIT, MODE, SLEEP and CONTROL. The script files must | ||
| - | reside in the same directory as XRouter, and the script name | ||
| - | is limited to 11 chars. | ||
| - | |||
| - | </ | ||
| - | Sysop-only | ||
| - | |||
| - | </ | ||
| - | This command has litle relevance nowadays, as it is doubtful | ||
| - | whether anyone still uses Dial-up networking, and Windows | ||
| - | already has DUN tools. | ||
| - | | ||
| - | </ | ||
| - | DUN(1) -- Dial Up Networking | ||
| - | SCRIPT(9) -- Dialer script commands | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DIGIFLAG.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DIGIFLAG -- Display / Set digipeat options. | ||
| - | |||
| - | </ | ||
| - | DIGIFLAG < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The DIGIFLAG command is used to display and/or set the | ||
| - | digipeat options for a specified port. | ||
| - | |||
| - | New settings override those read from the XROUTER.CFG file, | ||
| - | and remain in force until changed, or the system is restarted. | ||
| - | |||
| - | The minimum abbreviation of this command is DIGIF. | ||
| - | |||
| - | </ | ||
| - | Options are enabled by adding together the following numbers: | ||
| - | |||
| - | Bit Value Option | ||
| - | --------------------------------------------------- | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | DIGIF 3 | ||
| - | DIGIF 3 259 | ||
| - | DIGIF 2 0 | ||
| - | |||
| - | </ | ||
| - | 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 dupe prevention measures. | ||
| - | |||
| - | Not everyone agrees with the "New Paradigm, so the choice of | ||
| - | which features to enable is left you you. | ||
| - | |||
| - | </ | ||
| - | DIGIPORT(1) | ||
| - | DIGIFLAG(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DIGIPORT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DIGIPORT -- Display / Set port to digipeat on. | ||
| - | |||
| - | </ | ||
| - | DIGIPORT < | ||
| - | |||
| - | </ | ||
| - | Sysop only. | ||
| - | |||
| - | </ | ||
| - | Displays or specifies the port upon which digipeated frames | ||
| - | should be transmitted. | ||
| - | |||
| - | If " | ||
| - | displayed. | ||
| - | |||
| - | If " | ||
| - | transmitted on the port upon which they are received, | ||
| - | otherwise they are transmitted on the port specified. | ||
| - | |||
| - | The minimum abbreviation of this command is DIGIP. | ||
| - | |||
| - | </ | ||
| - | DIGIP 3 5 - Digipeat frames received on port 3 to port 5 | ||
| - | |||
| - | </ | ||
| - | Frames may currently be digipeated only to one port, therefore | ||
| - | it is not possible for a BBS on one port to broadcast unproto | ||
| - | headers to several ports at once using DIGIPORT. However, it | ||
| - | is possible using BCAST. | ||
| - | |||
| - | </ | ||
| - | BCAST(9) | ||
| - | DIGIPORT(7) -- Destination Port for Digipeated Frames. | ||
| - | DIGIFLAG(7) -- Control type of frames digipeated | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DISCARD.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DISCARD -- Start a "data sink" session. | ||
| - | |||
| - | </ | ||
| - | Syntax: DIS[card] [nodecall | nodealias] | ||
| - | |||
| - | </ | ||
| - | Sysop-only | ||
| - | |||
| - | </ | ||
| - | The DISCARD command starts a " | ||
| - | router ignores (discards) everything subsequently sent to | ||
| - | it. This is useful for testing TNC's, link throughputs etc. | ||
| - | |||
| - | Entering DISCARD without any arguments starts a sink session | ||
| - | on this XRouter. | ||
| - | |||
| - | If the optional argument is a nodecall or alias, and that | ||
| - | node is in the nodes table, XRouter connects to the discard | ||
| - | service on the specifed node. This only works if the target | ||
| - | node is also an XRouter at present. | ||
| - | |||
| - | A DISCARD session can only be ended by disconnection, | ||
| - | typing "/ | ||
| - | |||
| - | </ | ||
| - | The DISCARD server is also available on NetRomX service 9, | ||
| - | and by telnetting to TCP port 9 (This port may be altered | ||
| - | or disabled using the DISCARDPORT=n directive. | ||
| - | |||
| - | </ | ||
| - | ECHO(1) | ||
| - | DISC-SRV(9) | ||
| - | DISC-SVC(9) | ||
| - | DISCARDPORT(7) -- Specify TCP port for DISCARD server | ||
| - | TCP-PORTS(6) | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====DNS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DNS -- Domain Name Server commands. | ||
| - | |||
| - | </ | ||
| - | DNS {<A[dd] | D[rop]> < | ||
| - | |||
| - | </ | ||
| - | The DNS commands are used to add and delete Domain Name | ||
| - | Servers from the DNS list, and to display the list or cache. | ||
| - | |||
| - | Domain Name Servers are external TCP/IP hosts which are used | ||
| - | to resolve host names, for example " | ||
| - | addresses, when the information is not found locally in | ||
| - | DOMAIN.SYS. | ||
| - | |||
| - | In order for XRouter to use this process, it needs to know | ||
| - | the IP addresses of suitable DNS' | ||
| - | specified in XROUTER.CFG. | ||
| - | |||
| - | If no servers are specified, XRouter will use the domain | ||
| - | resolution services provided by the operating system. | ||
| - | |||
| - | The "Split DNS" system used by XRouter allows private | ||
| - | domains to be resolved using their own servers. | ||
| - | |||
| - | </ | ||
| - | a) "DNS ADD < | ||
| - | | ||
| - | |||
| - | The [domain] argument may be specified with or without a | ||
| - | | ||
| - | |||
| - | If [domain] is specified, the name server will only be | ||
| - | used to resolve hostnames in that domain, and the host | ||
| - | names in that domain will only be resolved using that | ||
| - | | ||
| - | |||
| - | For example: " | ||
| - | to exclusively use the server 44.131.91.245 to resolve all | ||
| - | | ||
| - | | ||
| - | will not be resolved using any other server. | ||
| - | |||
| - | |||
| - | b) "DNS DROP < | ||
| - | < | ||
| - | |||
| - | c) "DNS LIST" displays the list of domain name servers. | ||
| - | |||
| - | d) "DNS CACHE" displays the contents of XRouter' | ||
| - | cache. | ||
| - | |||
| - | </ | ||
| - | DNS ADD 44.131.91.245 .ampr.org. | ||
| - | DNS ADD 62.31.117.22 | ||
| - | DNS DROP 44.131.88.73 | ||
| - | |||
| - | </ | ||
| - | Domain servers are usually specified in XROUTER.CFG using | ||
| - | one or more " | ||
| - | directives to force the use of the operating system' | ||
| - | |||
| - | Alternatively, | ||
| - | BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | This command, and the DNS server / client were necessary in | ||
| - | DOS XRouter, but have less relevance in XRouter because the | ||
| - | Operating System provides Domain Resolution services. | ||
| - | |||
| - | However, the facilities were not deleted when the code was | ||
| - | ported to XRouter, because it is conceivable that (a) someone | ||
| - | might wish to use an external DNS via SLIP or PPP or RF | ||
| - | because the OS has no Internet connection (Imagine a node | ||
| - | on a remote site, with no internet connection), | ||
| - | may wish to act as a DNS for TCP/IP over radio. | ||
| - | |||
| - | </ | ||
| - | If XRouter obtains its IP address via DHCP or PPP, it will | ||
| - | automatically obtain primary and secondary DNS addresses, and | ||
| - | remove them from the list when the lease terminates. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DOS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DOS -- Enter PZTDOS command mode. | ||
| - | |||
| - | </ | ||
| - | DOS | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The DOS command switches the command interpreter into " | ||
| - | mode", allowing local and remote sysops to use familiar DOS | ||
| - | commands to maintain the system without taking it off line. | ||
| - | |||
| - | In this mode, the normal command prompt is replaced by a DOS- | ||
| - | style $P$G prompt showing the current drive and directory, and | ||
| - | only the PZTDOS commands are understood. | ||
| - | |||
| - | The operator must use the EXIT command to return to normal | ||
| - | command mode. | ||
| - | |||
| - | Sessions automatically return to command mode upon | ||
| - | disconnection. | ||
| - | |||
| - | </ | ||
| - | PZTDOS accepts both the MSDOS backslash (\) and the UNIX | ||
| - | forward slash (/) pathname seperator characters, and they may | ||
| - | be freely mixed. | ||
| - | always displays the path using the UNIX convention on Linux | ||
| - | platforms, and the DOS convention on DOS/Windows platforms. | ||
| - | |||
| - | As in MSDOS and UNIX, when specifying pathnames, a single dot | ||
| - | (.) represents the current directory, and a double dot | ||
| - | represents the parent directory. | ||
| - | ../ | ||
| - | the current directory' | ||
| - | |||
| - | Unlike MSDOS, PZTDOS does not maintain a seperate " | ||
| - | directory" | ||
| - | when changing drives. | ||
| - | |||
| - | On DOS/ | ||
| - | change drive, and the CD (change directory) command can also | ||
| - | accept a drive letter. | ||
| - | |||
| - | </ | ||
| - | PZTDOS is fully multitasking, | ||
| - | continues while PZTDOS mode is operating. | ||
| - | |||
| - | PZTDOS commands are detailed in section 3 of the manual. | ||
| - | |||
| - | PZTDOS is a vestige of a bygone age, where the OS would only | ||
| - | support a single foreground application. Without PZTDOS, it | ||
| - | would have been necessary either to "shell to DOS", or to | ||
| - | stop XROUTER altogether, in order to perform file-system | ||
| - | tasks. Nowadays, such tasks are easily performed on a multi- | ||
| - | tasking OS, and PZTDOS has little relevance. It is included | ||
| - | simply because it never got removed when XRouter was | ||
| - | ported to Windows, thence to Linux. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DUN.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DUN -- Dial Up Networking configuration commands. | ||
| - | |||
| - | </ | ||
| - | DUN A[dd] < | ||
| - | DUN D[rop] < | ||
| - | DUN L[ist] | ||
| - | DUN LO[g] [0-255] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | Dial-Up Networking (DUN) is a subsystem which allows Xrouter | ||
| - | to connect to other TCP/IP systems via a dial-up Public | ||
| - | Switched Telephone Network (PSTN) link. The DUN commands | ||
| - | are used to configure this subsystem. | ||
| - | |||
| - | </ | ||
| - | DUN ADD creates an association between a callsign (for KISS | ||
| - | links) or gateway IP address (for PPP or SLIP links) and a DUN | ||
| - | script. | ||
| - | |||
| - | DUN DROP removes a previously created association between a | ||
| - | callsign or gateway IP address and a DUN script. | ||
| - | |||
| - | DUN LIST lists the peers to whom a dial-up connection may be | ||
| - | established, | ||
| - | connections. | ||
| - | |||
| - | DUN LOG sets the level of logging, for diagnostic purposes. | ||
| - | The argument is a flag field, comprising the sum of the | ||
| - | following values: | ||
| - | |||
| - | 1 Log starts, stops and errors. | ||
| - | 2 Log all script lines. | ||
| - | 4 Log responses from modem or host. | ||
| - | |||
| - | A value of 0 disables all logging. | ||
| - | supplied, the current logging level is reported. | ||
| - | |||
| - | </ | ||
| - | DUN ADD gb7tyr | ||
| - | DUN ADD 62.31.176.22 | ||
| - | DUN DROP 62.31.176.22 | ||
| - | DUN LOG 3 | ||
| - | |||
| - | </ | ||
| - | The DUN ADD and DUN LOG commands may also be used in | ||
| - | IPROUTE.SYS and / or BOOTCMDS.SYS to set up the system at boot | ||
| - | time. | ||
| - | |||
| - | </ | ||
| - | DIAL(1) | ||
| - | SCRIPT(9) -- Dialler script commands. | ||
| - | DUN(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====DX.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | DX -- Displays distant APRS stations. | ||
| - | |||
| - | </ | ||
| - | DX [ port | node [port] ] | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The DX command displays a list of the most distant APRS | ||
| - | stations heard by XRouter, along with their positions, | ||
| - | distances and headings. | ||
| - | |||
| - | Providing XRouter' | ||
| - | position reports heard by XRouter will be recorded in the | ||
| - | DX list, in order of distance. | ||
| - | |||
| - | The sysop may set this up (using the DXFLAGS keyword in | ||
| - | XROUTER.CFG) to show only the directly heard stations, or | ||
| - | may choose to include those heard via digipeaters. He may | ||
| - | also specify a minimum distance for table inclusion. | ||
| - | |||
| - | If included, digipeated stations are clearly identifiable | ||
| - | by an entry in the " | ||
| - | heard stations. | ||
| - | |||
| - | </ | ||
| - | When no argument is used, stations received on all ports are | ||
| - | displayed. | ||
| - | |||
| - | If an optional port number is supplied, only the stations | ||
| - | received on that port will be shown | ||
| - | |||
| - | if the first argument is the callsign or alias of a known | ||
| - | node, the DX list of that node is requested, provided the | ||
| - | target node is XRouter v502s or later. If the second argument | ||
| - | is a port number, only the records for that port on the | ||
| - | target node are requested | ||
| - | |||
| - | </ | ||
| - | DX - Display all DX stations on this node | ||
| - | DX 13 - Display DX from port 13 only. | ||
| - | DX KIDDER | ||
| - | DX KIDDER 16 - Display DX records on KIDDER node's port 16 | ||
| - | |||
| - | G8PZT: | ||
| - | Prt Callsn Dist Dir Date Time Frm Position | ||
| - | 9 | ||
| - | 4 | ||
| - | 1 | ||
| - | (End of list) | ||
| - | |||
| - | Prt - Port number | ||
| - | Dist - Distance in Kilometers | ||
| - | Dir - Heading in degrees | ||
| - | Date - Date & time of last reception | ||
| - | Frm - No. of frames seen | ||
| - | Position - Latitude & longitude of station in APRS format | ||
| - | Via - Digipeater callsign (blank if heard direct) | ||
| - | |||
| - | </ | ||
| - | The DXFLAGS=n 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 by including an | ||
| - | APRS position string in the IDTEXT, for example: | ||
| - | |||
| - | IDTEXT | ||
| - | !5224.00N/ | ||
| - | *** | ||
| - | |||
| - | </ | ||
| - | If XRouter' | ||
| - | will be available | ||
| - | |||
| - | </ | ||
| - | AMSG(1) | ||
| - | DXFLAGS(7) -- DX List Control Flags | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====ECHO.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ECHO -- Start an Echo session. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The ECHO command starts a " | ||
| - | received by XRouter is echoed back to the sender. This is | ||
| - | useful for testing TNC's, link throughputs etc. | ||
| - | |||
| - | Entering ECHO without any arguments starts an echo session | ||
| - | on this XRouter. | ||
| - | |||
| - | If the optional argument is a nodecall or alias, and that | ||
| - | node is in the nodes table, XRouter connects to the echo | ||
| - | service on the specified node. This only works if the target | ||
| - | node is also an XRouter at present. | ||
| - | |||
| - | An ECHO session can only be ended by sending "/ | ||
| - | disconnection. | ||
| - | |||
| - | </ | ||
| - | The ECHO server is also available on NetRomX service 7, and | ||
| - | by telnetting to TCP port 7 (This port may be altered or | ||
| - | disabled using the ECHOPORT directive in XROUTER.CFG). | ||
| - | |||
| - | </ | ||
| - | DISCARD(1) | ||
| - | ECHOPORT(7) -- Specify TCP port for ECHO server | ||
| - | ECHO-SRV(9) -- ECHO Server. | ||
| - | |||
| - | </ | ||
| - | </ | ||
| - | ---- | ||
| - | =====EXCLUDE.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | EXCLUDE -- Prevent connections from a callsign. | ||
| - | |||
| - | </ | ||
| - | EXC[lude] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The EXCLUDE command is used to manage AX25 level 2 | ||
| - | exclusions, i.e. callsigns that are blocked from connecting | ||
| - | to the node using AX25. | ||
| - | |||
| - | Exclusions can apply on a port-by-port basis, or globally. | ||
| - | |||
| - | They can be added at boot-time using the EXCLUDE directive | ||
| - | in XROUTER.CFG, | ||
| - | |||
| - | The command can be used multiple times, to add one or more | ||
| - | callsigns at a time. Callsigns are appended to the list, if | ||
| - | they are not already in the list. | ||
| - | |||
| - | |||
| - | </ | ||
| - | " | ||
| - | |||
| - | If < | ||
| - | ports. To avoid confusion, global exclusions are not shown | ||
| - | in port exclusion lists. | ||
| - | |||
| - | " | ||
| - | stations prevented from connecting on < | ||
| - | |||
| - | Multiple callsigns may be added in this way, by adding them | ||
| - | as a comma separated list, like so: | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | used interchangeably, | ||
| - | |||
| - | |||
| - | |||
| - | There is as yet no way to remove a single callsign, other | ||
| - | than remove them all and reinstate the wanted ones. If anyone | ||
| - | needs this, please request it. | ||
| - | |||
| - | </ | ||
| - | exclude 0 g9mtt | ||
| - | |||
| - | exclude 4 | ||
| - | |||
| - | exclude 4 gd7dr Add GD7DR | ||
| - | |||
| - | exclude 5 g8pzt, | ||
| - | |||
| - | exclude 5 none Delete all calls | ||
| - | |||
| - | exclude 4 clear | ||
| - | |||
| - | | ||
| - | </ | ||
| - | EXCLUDE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====EXIT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | EXIT -- Exit XRouter (terminate the program) | ||
| - | |||
| - | </ | ||
| - | EXIT < | ||
| - | |||
| - | </ | ||
| - | The EXIT command is available only to sysops. | ||
| - | |||
| - | </ | ||
| - | The EXIT command terminates XRouter. The numeric argument is | ||
| - | returned to the calling program, allowing different actions | ||
| - | to be taken depending on the value. | ||
| - | |||
| - | </ | ||
| - | EXIT(3) -- Leave PZTDOS mode. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FEC.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FEC -- Control Forward Error Correction. | ||
| - | |||
| - | </ | ||
| - | FEC < | ||
| - | |||
| - | </ | ||
| - | The FEC command allows you to display and set the Reed | ||
| - | Solomon Forward Error Correction properties for a port. | ||
| - | At present, the only property which can be controlled is | ||
| - | FEC on/off. | ||
| - | |||
| - | 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. | ||
| - | |||
| - | In order to make use of FEC, the port needs to be using a | ||
| - | KISS TNC with the CRC check disabled, or an SCC or YAM card. | ||
| - | |||
| - | </ | ||
| - | The first argument is a port number, and is required. If not | ||
| - | supplied, a syntax reminder is displayed. | ||
| - | |||
| - | The second argument is optional. If supplied, the FEC flags | ||
| - | for the specified port are set to the numeric value of the | ||
| - | argument. If not supplied, the current value is reported. | ||
| - | |||
| - | A zero value turns FEC off, and a non-zero value turns it on. | ||
| - | |||
| - | </ | ||
| - | FEC 1 - Display current FEC setting for port 1. | ||
| - | FEC 1 0 - Turn off FEC on port 1 | ||
| - | |||
| - | </ | ||
| - | A suitable KISS ROM image for use with FEC is KISSFEC.BIN, | ||
| - | which should be provided in the XRouter release package. Note | ||
| - | that this ROM is for use only with XRouter, and only for FEC. | ||
| - | |||
| - | The FEC flag may be changed in future to allow it to be | ||
| - | enabled on TX, RX, both or neither. | ||
| - | way FEC, e.g. for use in the case where a link is bad in one | ||
| - | direction but good in another. Other flags may be used to | ||
| - | control parameters such as interleaving. | ||
| - | |||
| - | </ | ||
| - | 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 Netrom | ||
| - | 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. | ||
| - | |||
| - | 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 | ||
| - | |||
| - | </ | ||
| - | Sysops-only. | ||
| - | |||
| - | </ | ||
| - | CFLAGS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FINGER.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | FINGER -- Display information about users. | ||
| - | |||
| - | </ | ||
| - | FINGER <user | user@host | @host> | ||
| - | |||
| - | </ | ||
| - | The command is available to all users. | ||
| - | |||
| - | </ | ||
| - | If the command is of the form " | ||
| - | searches the FINGER subdirectory for a text file which matches | ||
| - | " | ||
| - | file may contain anything you like, and " | ||
| - | callsign, nickname or other form of hostname consisting of up | ||
| - | to 8 legal DOS characters | ||
| - | |||
| - | If the form " | ||
| - | attempt to resolve " | ||
| - | TCP/IP contact with the finger server on that host. | ||
| - | |||
| - | </ | ||
| - | FINGER g8pzt - Info on local user g8pzt | ||
| - | FINGER g8jvm@iptlfd | ||
| - | |||
| - | </ | ||
| - | This feature is very rudimentary at present, requiring the | ||
| - | user account files to be created by the sysop. | ||
| - | |||
| - | </ | ||
| - | FING-SRV(9) | ||
| - | FINGERPORT(7) -- TCP Port for Finger Server. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FRACK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FRACK -- Display / Set FRACK for a port. | ||
| - | |||
| - | </ | ||
| - | FRACK < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | Displays the current FRACK (AX25 level 2 T1 timer) setting for | ||
| - | the specified port, or allows it to be changed. | ||
| - | |||
| - | If the second argument is ommitted, the current value is | ||
| - | displayed, otherwise the value in millseconds is used. | ||
| - | |||
| - | The new setting overrides the value specified in the CFG file, | ||
| - | and remains in force until changed or the next restart. | ||
| - | |||
| - | </ | ||
| - | FRACK 2 - Display port 2 frack setting | ||
| - | FRACK 2 6000 - Set port 2 frack to 6 seconds | ||
| - | |||
| - | </ | ||
| - | A typical FRACK setting for 1200 baud is 7000 (7 secs), and | ||
| - | specifies how long AX25 will wait for a level 2 ack before | ||
| - | requesting confirmation. | ||
| - | antisocial, achieves nothing, and could result in the link | ||
| - | retrying out. | ||
| - | |||
| - | However, on AXUDP links 7 secs is excessive, and a figure | ||
| - | more like 2000 (2 secs) should be used. | ||
| - | |||
| - | FRACK=n may be used within PORT definition blocks in | ||
| - | XROUTER.CFG to specify the default setting for a port. | ||
| - | |||
| - | </ | ||
| - | FRACK(7) -- Frame Acknowledgement Time. | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FTP-CMDS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FTP-CMDS -- FTP Server Commands. | ||
| - | |||
| - | </ | ||
| - | XRouter' | ||
| - | |||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | |||
| - | All commands are case-insensitive, | ||
| - | " | ||
| - | DOS and Windows versions of XRouter, but are case-sensitive | ||
| - | on Linux versions (XRLin / XRPi). | ||
| - | |||
| - | Both UNIX style (e.g. /pub/fred) and DOS style (e.g. | ||
| - | \pub\fred) pathname conventions are accepted. | ||
| - | |||
| - | Disk drive letters (e.g. " | ||
| - | but not to Linux versions. | ||
| - | |||
| - | Unlike DOS, the server does not maintain separate " | ||
| - | directories" | ||
| - | drive letter must start at the root of that drive. | ||
| - | " | ||
| - | |||
| - | The FTP commands are described in detail below: | ||
| - | |||
| - | |||
| - | ABOR -- Abort data connection. | ||
| - | |||
| - | Syntax: ABOR | ||
| - | |||
| - | The ABOR command tells the server to abort any data | ||
| - | transfer currently in progress and close the data | ||
| - | connection. | ||
| - | |||
| - | If the data connection is not open, this command has | ||
| - | no effect. | ||
| - | |||
| - | |||
| - | CDUP -- Change Directory Up By One Level | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The CDUP command changes the current working directory | ||
| - | up one level to the parent directory, i.e. it performs | ||
| - | the function of "CWD .." | ||
| - | |||
| - | This command has no arguments, and if already at the | ||
| - | root it has no effect. | ||
| - | |||
| - | |||
| - | CWD -- Change Working Directory | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The CWD command changes the current working directory | ||
| - | (and drive if necessary) for the FTP session. | ||
| - | |||
| - | Examples: | ||
| - | |||
| - | CWD FRED Change to sub-directory FRED. | ||
| - | CWD .. Change up one level to parent dir. | ||
| - | CWD / | ||
| - | CWD / | ||
| - | |||
| - | |||
| - | DELE -- Delete file(s). | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | Examples: | ||
| - | |||
| - | DELE JIM.TXT | ||
| - | DELE / | ||
| - | DELE *.BAT | ||
| - | |||
| - | Notes: | ||
| - | |||
| - | |||
| - | FEAT -- Feature negotiation mechanism. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The FEAT command requests the server to list all extension | ||
| - | commands, or extended mechanisms, that it supports. | ||
| - | |||
| - | |||
| - | HELP -- Display help for FTP server commands. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | Examples: | ||
| - | HELP CWD Gives help for the CWD command. | ||
| - | |||
| - | Some FTP clients may intercept the HELP command to | ||
| - | give help on client commands. | ||
| - | REMOTEHELP command, if it is implemented should | ||
| - | translate to a server HELP command. If not, the client | ||
| - | may have a command which passes commands " | ||
| - | server. | ||
| - | HELP command will work. | ||
| - | |||
| - | |||
| - | LIST -- lists FTP server directory contents. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The LIST command causes a directory listing to be sent | ||
| - | from the FTP server to the client over the data | ||
| - | connection. | ||
| - | established, | ||
| - | |||
| - | The optional argument consists of a directory path and | ||
| - | filename mask. If no path is specified, the current | ||
| - | directory is assumed. | ||
| - | (all files) is assumed. | ||
| - | accepted. | ||
| - | |||
| - | Examples: | ||
| - | LIST Show all files in current directory | ||
| - | LIST C: | ||
| - | LIST / | ||
| - | |||
| - | See also: NLST -- List names only | ||
| - | |||
| - | |||
| - | MDTM -- Enquire file modification date and time. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The MDTM command is used to obtain the "last modifed" | ||
| - | date and time of the specified file. | ||
| - | |||
| - | Examples: | ||
| - | MDTM C: | ||
| - | |||
| - | |||
| - | MFMT -- Modify the last modification time of a file. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | Example: | ||
| - | (sets file date/time to 17/7/2002 21:07:15) | ||
| - | |||
| - | |||
| - | MKD -- Make new directory. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The MKD command creates a new directory of the | ||
| - | specified name. If pathname is not fully qualified, | ||
| - | the new directory is created within the current | ||
| - | working directory. | ||
| - | |||
| - | Examples: | ||
| - | MKD C:/JIM/BILL | ||
| - | |||
| - | See also: RMD -- Remove directory | ||
| - | |||
| - | |||
| - | MODE -- Specifies the data transfer mode. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | MODE specifies how the data is to be formatted and | ||
| - | transferred via the data connection. | ||
| - | as follows: | ||
| - | |||
| - | B - Block Data is sent in blocks | ||
| - | C - Compressed | ||
| - | S - Stream | ||
| - | |||
| - | The default transfer mode, which is the only one | ||
| - | currently implemented, | ||
| - | included to prevent unnecessary error replies. | ||
| - | |||
| - | Examples: | ||
| - | |||
| - | |||
| - | NLST -- Lists directory contents in short form. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The NLST (Name List) command causes a directory | ||
| - | listing to be sent from the FTP server to the client | ||
| - | over the data connection. | ||
| - | cannot be established, | ||
| - | |||
| - | The optional argument consists of a directory path and | ||
| - | filename mask. If no path is specified, the current | ||
| - | directory is assumed. | ||
| - | (all files) is assumed. | ||
| - | accepted. | ||
| - | |||
| - | The listing consists of filenames only, without size, | ||
| - | date and other supplementary information. | ||
| - | |||
| - | Examples: | ||
| - | NLST K:\PUB | ||
| - | NLST /USR/*.EXE | ||
| - | |||
| - | See also: LIST -- List directory contents | ||
| - | |||
| - | |||
| - | NOOP -- (NO OPeration) does nothing. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The NOOP command does not affect anything, and its | ||
| - | only action is to cause the server to send an " | ||
| - | reply. | ||
| - | control connection is still functioning. | ||
| - | |||
| - | |||
| - | PASS -- Specifies user password at login. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The argument to the PASS command is either a string of | ||
| - | up to 5 characters in response to the secure password | ||
| - | challenge or, for use on secure links only, the | ||
| - | password itself. | ||
| - | |||
| - | The command must be immediately preceded by the USER | ||
| - | command, which causes the system to reply with a | ||
| - | matrix consisting of 5 lines of 5 numbers thus: | ||
| - | |||
| - | 4 1 6 3 7 | ||
| - | 3 5 2 6 3 | ||
| - | 7 1 9 2 4 | ||
| - | 2 7 1 4 6 | ||
| - | 3 5 2 6 1 | ||
| - | |||
| - | The remote sysop must then choose ONE of the lines, | ||
| - | and send the PASS command followed by the 5 characters | ||
| - | from the password string which correspond to the 5 | ||
| - | numbers on the chosen line. There must be a space | ||
| - | after PASS but no spaces between the characters. | ||
| - | |||
| - | Examples: | ||
| - | PASS squirrels | ||
| - | |||
| - | If the sysop has connected on a port which has SYSOP=1 | ||
| - | in the config file (e.g. a secure wire link), the | ||
| - | response to this command is ignored, and the sysop is | ||
| - | granted full access. | ||
| - | |||
| - | See also: USER -- Specify your username. | ||
| - | |||
| - | |||
| - | PASV -- Use " | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | Normal FTP relies on the server being able to initiate | ||
| - | a data connection to TCP port 20 on the client host. | ||
| - | This method may however not work if the client is | ||
| - | located " | ||
| - | |||
| - | Passive mode opens a data connection on the server, | ||
| - | informs the client of the IP address and port number, | ||
| - | and waits for the client to connect to it. It can | ||
| - | therefore work via firewalls. | ||
| - | |||
| - | |||
| - | PORT -- Specifies IP address and port for the data connection. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The PORT command specifies the IP address and TCP port | ||
| - | number to be used by the data connection. | ||
| - | argument is the concatenation of a 32 bit IP address | ||
| - | and a 16 bit TCP port number, split into 8 bit fields, | ||
| - | each field being transmitted as a decimal number. | ||
| - | fields are separated by commas, and the high order | ||
| - | fields are transmitted first. | ||
| - | |||
| - | Example: | ||
| - | Specifies IP address 44.131.91.2 and TCP | ||
| - | port number 0401 (1001 decimal) | ||
| - | |||
| - | Under normal circumstances this command is not needed. | ||
| - | The data connection defaults to TCP port 20 at the | ||
| - | client' | ||
| - | However, it allows data to be sent to a different host | ||
| - | if required. | ||
| - | |||
| - | |||
| - | PWD -- Print Working Directory. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The PWD command causes the full path of the user's | ||
| - | current working directory to be displayed via the | ||
| - | control connection. | ||
| - | |||
| - | See also: CWD -- Change Working Directory | ||
| - | |||
| - | |||
| - | QUIT -- Terminates an FTP session. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | If a file transfer is not in progress, the QUIT | ||
| - | command terminates the FTP session and closes the | ||
| - | control connection. | ||
| - | |||
| - | If file transfer is in progress, the control | ||
| - | connection will remain open until transfer is | ||
| - | complete, allowing the result code to be sent. The | ||
| - | control and data connections will then close. | ||
| - | |||
| - | An unexpected close on the control connection will | ||
| - | abort any data transfer currently in progress. | ||
| - | |||
| - | See also: ABOR -- Abort current command. | ||
| - | |||
| - | |||
| - | REST -- Restart of Interrupted Transfer. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The REST command specifies an offset from which a file | ||
| - | transfer should be resumed. The REST command does not | ||
| - | actually initiate the transfer. After issuing a REST | ||
| - | command, the client must send the appropriate FTP command | ||
| - | to transfer the file. The server resumes file transfer at | ||
| - | the specified offset. | ||
| - | |||
| - | Example: REST 32740 | ||
| - | |||
| - | NOTE: At present this only works for BINARY transfer mode! | ||
| - | |||
| - | |||
| - | RETR -- Retrieve (download) file. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | |||
| - | The RETR command causes the named file to be sent from | ||
| - | the FTP server to the client over the data connection. | ||
| - | If the file can't be found, or access is denied, or | ||
| - | the data connection can't be opened, an appropriate | ||
| - | error message is returned. | ||
| - | |||
| - | Examples: | ||
| - | RETR ../ | ||
| - | RETR C: | ||
| - | |||
| - | Notes: | ||
| - | |||
| - | See also: PORT -- Host/port for data connection. | ||
| - | STOR -- Send a file to the server. | ||
| - | |||
| - | |||
| - | STOR -- Store (upload) file. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The STOR command requests the FTP server to accept | ||
| - | data via the data connection and store it as a file | ||
| - | with the specified name. | ||
| - | |||
| - | If the file specified in the pathname already exists | ||
| - | at the server, it is overwritten by the new data. The | ||
| - | overwrite doesn' | ||
| - | correctly received, which prevents a critical file | ||
| - | being lost if the data connection fails. | ||
| - | |||
| - | Examples: | ||
| - | STOR / | ||
| - | |||
| - | See also: RETR -- Retrieve a file from the server. | ||
| - | |||
| - | |||
| - | RMD -- Remove Directory. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The RMD command deletes the directory specified by | ||
| - | < | ||
| - | owner of that directory and have write access. | ||
| - | |||
| - | Examples: RMD FRED | ||
| - | RMD K:/JIM/BILL | ||
| - | |||
| - | See also: MKD -- Make directory | ||
| - | |||
| - | |||
| - | RNFR -- Rename From | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The RNFR command specifies the old pathname of a file | ||
| - | which is to be renamed, and must be immediately | ||
| - | followed by an RNTO command. | ||
| - | together cause a file to be renamed. | ||
| - | not found the request is refused. | ||
| - | |||
| - | Examples: RNFR ../JIM.TXT | ||
| - | RNFR K:/ | ||
| - | |||
| - | See also: RNTO -- Rename To | ||
| - | |||
| - | |||
| - | RNTO -- Rename To | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The RNTO command specifies the new pathname of a file | ||
| - | which is being renamed, and must immediately follow an | ||
| - | RNFR command. | ||
| - | to be renamed. | ||
| - | |||
| - | If the new pathname isn't valid, the request is refused. | ||
| - | |||
| - | Examples: | ||
| - | RNTO K:/ | ||
| - | |||
| - | See also: RNFR -- Rename From. | ||
| - | |||
| - | |||
| - | SIZE -- Enquire Size of File. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The SIZE command returns the transfer size of the file | ||
| - | whose pathname was supplied, or an error response if the | ||
| - | file does not exist, the size is unavailable, | ||
| - | other error has occurred. | ||
| - | format suitable for use with the RESTART (REST) command | ||
| - | for mode STREAM, provided the transfer mode and type are | ||
| - | not altered. | ||
| - | |||
| - | |||
| - | STRU -- Specify File Structure. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | STRU specifies the internal structure of the files | ||
| - | being transferred, | ||
| - | within them. Structure codes are as follows: | ||
| - | |||
| - | F - File No record structure (contiguous bytes) | ||
| - | R - Record | ||
| - | P - Page File is composed of independent pages | ||
| - | |||
| - | The default structure, which is the only one currently | ||
| - | implemented, | ||
| - | prevent unnecessary error replies. | ||
| - | |||
| - | Example: | ||
| - | |||
| - | |||
| - | SYST -- Operating system enquiry. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The SYST command is used to discover what type of | ||
| - | operating system is being used on the server. | ||
| - | |||
| - | The first word of the reply is one of the agreed | ||
| - | system names, in this case Windows NT. The rest of the | ||
| - | reply gives the server version number and byte size. | ||
| - | |||
| - | |||
| - | TYPE -- Specifies the data representation type. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The argument to the TYPE command specifies how the | ||
| - | data is to be translated between storage and transfer. | ||
| - | Type codes are as follows: | ||
| - | |||
| - | A - ASCII Text. End of line is < | ||
| - | I - Image No translation. | ||
| - | L < | ||
| - | |||
| - | Examples: | ||
| - | TYPE L 8 Local byte size of 8 bits | ||
| - | |||
| - | |||
| - | USER -- Specify user name for login. | ||
| - | |||
| - | Syntax: | ||
| - | |||
| - | The argument to the USER command is a string of up to | ||
| - | 8 characters specifying the user's login name | ||
| - | (usually callsign). | ||
| - | spaces. | ||
| - | |||
| - | Users are not allowed access to the system without | ||
| - | logging in. | ||
| - | |||
| - | If the username (or callsign) exists in the | ||
| - | PASSWORD.SYS file the server sends a grid of 5x5 | ||
| - | numbers (see PASS command) generated from the user's | ||
| - | stored password. | ||
| - | error message is sent instead, and access is denied. | ||
| - | |||
| - | The USER command must be immediately followed by the | ||
| - | PASS command. | ||
| - | |||
| - | Example: | ||
| - | USER G8PZT Use callsign | ||
| - | |||
| - | |||
| - | Note: Because the FTP server allows you to use any | ||
| - | string of characters as a name, you may set up | ||
| - | different passwords for different login names, and | ||
| - | these may be in addition to your callsign, which is | ||
| - | the one used for ax25 sysop access. | ||
| - | |||
| - | See also: PASS -- Specify password. | ||
| - | |||
| - | |||
| - | </ | ||
| - | FTP-SRV(9) -- FTP Server. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FTP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FTP -- Invoke FTP Client. | ||
| - | |||
| - | </ | ||
| - | FT[p] [hostname | ipaddr | nickname] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The FTP command invokes an inbuilt FTP (File Transfer | ||
| - | Protocol) client. This client is part of XRouter, and has | ||
| - | nothing to do with the host operating system. | ||
| - | |||
| - | The client currently has 67 commands, all of which have brief | ||
| - | help and syntax. Commands may be abbreviated. The command | ||
| - | list is as follows: | ||
| - | |||
| - | ? < | ||
| - | ascii | ||
| - | cd cdup close | ||
| - | get | ||
| - | lcd | ||
| - | lmkdir | ||
| - | mdelete | ||
| - | newer | ||
| - | progress | ||
| - | quote | ||
| - | rename | ||
| - | send site size sndport | ||
| - | sunique | ||
| - | verbose | ||
| - | |||
| - | Use "? < | ||
| - | |||
| - | ? ldir | ||
| - | LDIR List files in local directory | ||
| - | Syntax: LDI[r] [local-path] | ||
| - | |||
| - | The Q)uit command returns you to the node. | ||
| - | |||
| - | </ | ||
| - | Typing " | ||
| - | but doesn' | ||
| - | LCD etc can be performed. A connection can be initiated using | ||
| - | the OPEN command. | ||
| - | |||
| - | If the argument to " | ||
| - | address, the client connects to the standard TCP port (21) | ||
| - | on that target. | ||
| - | |||
| - | If the target server isn't on TCP port 21, the port number | ||
| - | can be specified using a second argument, e.g. | ||
| - | |||
| - | FTP 192.168.1.203 31 | ||
| - | |||
| - | Commonly-used targets can be given a " | ||
| - | the connection process. Nicknames are specified in | ||
| - | FTPCLI.SYS, along with connection details allowing automated | ||
| - | login. | ||
| - | |||
| - | </ | ||
| - | FTP -- Start FTP without connect to server | ||
| - | FTP 192.168.1.3 | ||
| - | FTP g8pzt.ath.cx 2521 -- Connect to g8pzt.ath.cx port 2521 | ||
| - | FTP gb7kr -- Automated connect, account " | ||
| - | |||
| - | </ | ||
| - | Some may wonder why XRouter includes an FTP client, when | ||
| - | Linux already has one? | ||
| - | |||
| - | One good reason is that it allows FTP over Amprnet, which is | ||
| - | something that's not easy to set up in Linux itself. | ||
| - | |||
| - | Secondly, I had a need for it. I won't elaborate why, just | ||
| - | to say it has proved very useful to me. It might even prove | ||
| - | useful to you. If not, just ignore it! | ||
| - | |||
| - | </ | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====FULLDUP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | FULLDUP -- Display / Set full duplex mode. | ||
| - | |||
| - | </ | ||
| - | FULLDUP < | ||
| - | |||
| - | </ | ||
| - | SYSOP-only. | ||
| - | |||
| - | </ | ||
| - | Displays the current duplex setting for a port, and allows it | ||
| - | to be changed without restarting the system. | ||
| - | operating in full duplex mode, DCD is ignored and the hardware | ||
| - | will transmit whenever it has anything to send. | ||
| - | |||
| - | If two numeric arguments are supplied, the duplex flag is set | ||
| - | to the second argument, otherwise the current setting for the | ||
| - | specified port is displayed. | ||
| - | full duplex. | ||
| - | |||
| - | Modified settings remain in force until changed or system is | ||
| - | restarted. | ||
| - | |||
| - | </ | ||
| - | FULLDUP 3 - Display current setting for port 3 | ||
| - | FULLDUP 3 1 - Set port 3 into full duplex mode | ||
| - | |||
| - | </ | ||
| - | On KISS ports, allow up to 5 minutes for modified settings to | ||
| - | reach the TNC. | ||
| - | |||
| - | This parameter has meaning only on KISS TNCs, SCC cards, and | ||
| - | YAM modems. | ||
| - | |||
| - | FULLDUP=n may be used within PORT definition blocks in | ||
| - | XROUTER.CFG to specify the default setting for a port. | ||
| - | |||
| - | </ | ||
| - | FULLDUP(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====GNET.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | GNET -- Display / Set GNET parameters. | ||
| - | |||
| - | </ | ||
| - | G[net] A[ddress] [addr] | ||
| - | G[net] R[oute] A[dd] < | ||
| - | G[net] R[oute] D[rop] < | ||
| - | G[net] R[oute] L[ist] | ||
| - | G[net] T[tl] [1-255] | ||
| - | |||
| - | </ | ||
| - | Sysops-only. | ||
| - | |||
| - | </ | ||
| - | The GNET commands allow sysops to display and set the GNET | ||
| - | parameters such as address and routing. | ||
| - | |||
| - | GNET is an experimental global network, which uses ip-like | ||
| - | addressing and routing to tunnel traffic across the NetRom | ||
| - | network, unrestricted by NetRom horizons. | ||
| - | | ||
| - | Not only does GNET offer global routing between all users, | ||
| - | but it also offers up to 65536 possible session types | ||
| - | between those users. | ||
| - | |||
| - | </ | ||
| - | "GNET ADDRESS" | ||
| - | address. See NOTES below for details of address format. | ||
| - | The GNET address defaults to 0.0.0.0 which disables all GNET | ||
| - | activity. | ||
| - | |||
| - | "GNET ROUTE ADD" is used to add a route to the GNET routing | ||
| - | table. The first argument is the address to be routed, with | ||
| - | optional mask. e.g. 131.90.1.2/ | ||
| - | whereas 131.90.1.0/ | ||
| - | bits", and would route all 256 addresses from 131.90.1.0 to | ||
| - | 131.90.1.255. The second argument < | ||
| - | callsign of the GNET gateway to which the addresses should | ||
| - | be routed. | ||
| - | |||
| - | "GNET ROUTE DROP" removes a routing entry from the GNET | ||
| - | routes table. The arguments are the GNET address and mask. | ||
| - | |||
| - | "GNET ROUTE LIST" lists all the GNET routes in the table. | ||
| - | |||
| - | "GNET TTL" sets the "Time To Live", i.e. the maximum number | ||
| - | of hops a packet is allowed to make. A low TTL helps to | ||
| - | suppress bouncing packets in the event of a routing loop. | ||
| - | The default is 25 | ||
| - | |||
| - | </ | ||
| - | GNET ADDR 147.22.14.2 | ||
| - | GNET ROUTE ADD 131.91.2.0/ | ||
| - | GNET ROUTE DROP 131.91.2.0 24 | ||
| - | GNET TTL 15 | ||
| - | |||
| - | </ | ||
| - | There is no provision in XROUTER.CFG for spcifying the GNET | ||
| - | address and routing, but this can be achieved by using the | ||
| - | GNET commands in BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | GNET addressing is based on numeric country and region codes | ||
| - | and the addresses look like IP addresses, although this | ||
| - | protocol does not involve IP at all. | ||
| - | |||
| - | Addresses are of the form < | ||
| - | allowing up to 255 countries, 255 regions per country, 255 | ||
| - | routers per region and 255 users per router. But this is not | ||
| - | rigid; Each country may assign the regions as it sees fit. | ||
| - | |||
| - | Country codes are the same as the ones used for amprnet, | ||
| - | e.g. 131 is the UK, 147 is New Zealand etc. Region codes can | ||
| - | be the same as the amprnet regions. Router codes can be | ||
| - | assigned by local agreement, and user codes are assigned by | ||
| - | the router sysops. | ||
| - | |||
| - | </ | ||
| - | GNET was invented in 2002 by G8PZT, and was implemented in | ||
| - | XRouter. The development name adopted for the system was | ||
| - | " | ||
| - | However, it later transpired that the name was being used | ||
| - | by an ISP, so the shorter name " | ||
| - | was adopted to avoid confusion. | ||
| - | |||
| - | The system showed great promise, but never took off because | ||
| - | there was no sysop documentation, | ||
| - | XRouter was waning as more people wanted to run their | ||
| - | systems on Windows. The author' | ||
| - | urgent matters, and no more development was done. There was | ||
| - | so much more that could have been done. | ||
| - | |||
| - | The GNET protocol and commands were retained when XRouter | ||
| - | was ported from DOS to Windows and thence to Linux. | ||
| - | Development may resume in future. In the meantime, sysops | ||
| - | are encouraged to experiment with this mode. | ||
| - | |||
| - | </ | ||
| - | There is currently no mechanism for resolving user callsigns | ||
| - | to GNET addresses. This is a vital part of the system, which | ||
| - | will be the next component to be added. | ||
| - | | ||
| - | </ | ||
| - | GNET relies on the NetRom network to provide links between | ||
| - | its gateways. In order to route GNET traffic to a gateway, | ||
| - | that gateway must be present in your node table | ||
| - | |||
| - | </ | ||
| - | GPING(1) | ||
| - | IP-CODES(9) -- IP Country Codes | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====GPING.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | GPING -- Send GNET Echo Request. | ||
| - | |||
| - | </ | ||
| - | GP[ing] < | ||
| - | |||
| - | </ | ||
| - | All users, except guests. | ||
| - | |||
| - | </ | ||
| - | Sends GCMP (GlobalNet Control Message Prototcol) echo | ||
| - | request(s) to the specified GNET (GlobalNet) address, for | ||
| - | the purposes of route testing. | ||
| - | |||
| - | An optional data portion may be specified, and the echo | ||
| - | request may optionally be repeated at a specified interval. | ||
| - | |||
| - | If there is a reply it will be displayed. For repeating pings | ||
| - | the system displays the number sent/rcvd, the average round | ||
| - | trip time in milliseconds, | ||
| - | for reply" process may be cancelled at any time by entering | ||
| - | <CR> by itself. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | |||
| - | [len] specifies the number of additional data bytes to send | ||
| - | in the request packet. Default is 0. | ||
| - | |||
| - | [sec] is the interval between requests. If present, this | ||
| - | causes the ping to repeat every [sec] seconds. This | ||
| - | field requires the [len] field to be present. | ||
| - | |||
| - | </ | ||
| - | GPING 131.91.2.1 | ||
| - | GPING 131.91.2.1 50 Single ping with 50 bytes data | ||
| - | GPING 131.91.2.1 512 10 Ping 512 bytes every 10 secs | ||
| - | |||
| - | </ | ||
| - | See the MAN page for GNET(1) for more information about GNET. | ||
| - | |||
| - | </ | ||
| - | In order for this command to work, XRouter' | ||
| - | be defined, and there must be a route to the destination. | ||
| - | |||
| - | If XRouter' | ||
| - | "Error 5 (bad configuration)", | ||
| - | the response is "Error 4 (no route)" | ||
| - | |||
| - | If no response is received, the target doesn' | ||
| - | downstream routing is faulty, or there is no return route | ||
| - | defined. | ||
| - | |||
| - | </ | ||
| - | GNET(1) -- GNET Configuration Commands | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====HELP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | HELP -- Displays help for commands and other topics | ||
| - | |||
| - | </ | ||
| - | HELP [cmd | topic] | ||
| - | |||
| - | </ | ||
| - | The HELP command is available to all users. | ||
| - | |||
| - | </ | ||
| - | If no arguments are given, a short text gives directions on | ||
| - | how to access help. | ||
| - | |||
| - | If the argument is a topic or a command name, the contents of | ||
| - | the appropriate file in the HELP subdirectory are displayed. | ||
| - | |||
| - | The argument " | ||
| - | |||
| - | The minimum abbreviation for this command is " | ||
| - | |||
| - | </ | ||
| - | H * - List available help topics. | ||
| - | H PING - Gives help for PING command. | ||
| - | |||
| - | </ | ||
| - | The command or topic name must at present be given in full, | ||
| - | thus "H NODES" is acceptable, but "H N" is not (unless you | ||
| - | duplicate the NODES.HLP file to N.HLP). | ||
| - | search for the closest match. | ||
| - | |||
| - | Topic names were originally restricted to 8 characters | ||
| - | because in order to be a legal DOS filename. Thus some help | ||
| - | files have names that are shorter than the command name. | ||
| - | |||
| - | </ | ||
| - | The help available using the HELP command is intended to be of | ||
| - | use to both sysops and users alike, and is kept brief in order | ||
| - | to avoid wasting airtime. | ||
| - | information for sysops. | ||
| - | |||
| - | The sysop may customise the help files, or add his/her own | ||
| - | help topics to the HELP directory as required. | ||
| - | directory is located beneath the router' | ||
| - | and the files are simply plain text files with the .HLP | ||
| - | extension. | ||
| - | listed or accessible. | ||
| - | |||
| - | </ | ||
| - | HELP(9) -- Help System. | ||
| - | INFO(1) -- Information System. | ||
| - | MAN(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====HOST.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | HOST -- Display information about a TCP/IP host | ||
| - | |||
| - | </ | ||
| - | HO[st] < | ||
| - | |||
| - | </ | ||
| - | The HOST command displays all known information about the | ||
| - | specified TCP/IP host. | ||
| - | |||
| - | It would typically be used to find the IP address, given the | ||
| - | hostname, or vice versa. | ||
| - | |||
| - | </ | ||
| - | The argument may be either a host name or an IP address. | ||
| - | Hostnames not containing at least one dot (.) are first | ||
| - | expanded by appending the domain suffix, as specified in | ||
| - | XROUTER.CFG (default .ampr.org.) | ||
| - | |||
| - | </ | ||
| - | ho kidder | ||
| - | |||
| - | G8PZT: | ||
| - | Hostname: kidder.ampr.org. | ||
| - | Address: | ||
| - | |||
| - | </ | ||
| - | The HOST command uses information from DOMAIN.SYS. | ||
| - | If domain resolution is to be performed by an external DNS | ||
| - | instead of by Windows/ | ||
| - | the DNS=< | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The returned information is limited in scope at present. It | ||
| - | will be expanded in a future version. | ||
| - | |||
| - | In order to work properly, the HOST command requires either | ||
| - | a populated DOMAIN.SYS, or access to a Domain Name Server, | ||
| - | either directly, or via Windows / Linux. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDPATH.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IDPATH -- Display / Set destination path for ID beacons. | ||
| - | |||
| - | </ | ||
| - | IDP[ath] < | ||
| - | |||
| - | </ | ||
| - | Sysop only. | ||
| - | |||
| - | </ | ||
| - | Displays or modifies the destination callsign, and digipeater | ||
| - | path for the regular AX25 " | ||
| - | is " | ||
| - | for example on APRS ports, to digipeat your beacon. | ||
| - | |||
| - | If " | ||
| - | destination and digipeater callsigns) is displayed. | ||
| - | |||
| - | If " | ||
| - | specified port is changed to the new value. | ||
| - | |||
| - | The " | ||
| - | |||
| - | < | ||
| - | |||
| - | where < | ||
| - | and [digicall] are optional digipeater callsigns. | ||
| - | |||
| - | The minimum abbreviation of this command is IDP. | ||
| - | |||
| - | </ | ||
| - | IDP 3 - Display current IDPATH for port 3 | ||
| - | IDP 3 ID, | ||
| - | |||
| - | </ | ||
| - | IDINTERVAL(7) | ||
| - | IDPATH(7) | ||
| - | IDTEXT(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IDS -- Intrusion Detection System Commands. | ||
| - | |||
| - | </ | ||
| - | IDS L[og] [on | off] | ||
| - | IDS S[tats] | ||
| - | IDS V[erbosity] [0-4] | ||
| - | |||
| - | </ | ||
| - | The IDS commands are used to display the IDS statitics, and | ||
| - | to control IDS logging and verbosity. | ||
| - | |||
| - | The IDS is described in more detail in section 9 of the | ||
| - | manual. | ||
| - | |||
| - | </ | ||
| - | L[og] | ||
| - | Displays or changes IDS logging state. If IDS logging is | ||
| - | enabled, some (but not all) IDS events are logged to the | ||
| - | file LOG/ | ||
| - | year, month and day of the month. | ||
| - | |||
| - | S[tats] | ||
| - | Displays the IDS statistics. These ar more comprehensive | ||
| - | than those displayed in the top pane of the IDS window. | ||
| - | The meaning of each field is explained in IDS(9). | ||
| - | |||
| - | V[erbosity] | ||
| - | Displays / changes IDS verbosity, i.e. the amount of | ||
| - | detail that is displayed and logged. There are 5 | ||
| - | verbosity levels as follows: | ||
| - | |||
| - | 0 - No notifications | ||
| - | 1 - Intrusion / Escalation attempts only. | ||
| - | 2 - As 1, plus recon attempts (port scans etc. | ||
| - | 3 - As 2, plus possible suspicious events. | ||
| - | 4 - As 3, plus " | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | IDS(9) -- Intrusion Detection System. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IDTEXT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IDTEXT -- Display / Set ID Beacon Text. | ||
| - | |||
| - | </ | ||
| - | IDT[ext] <port | 0> [text] | ||
| - | |||
| - | </ | ||
| - | Sysop only. | ||
| - | |||
| - | </ | ||
| - | Displays or modifies the contents of the regular AX25 " | ||
| - | beacons, which are transmitted every IDINTERVAL. | ||
| - | |||
| - | The " | ||
| - | In the latter case the command displays or sets the " | ||
| - | IDTEXT. | ||
| - | |||
| - | If " | ||
| - | specified port is displayed. | ||
| - | |||
| - | If " | ||
| - | port is changed to the new value. | ||
| - | |||
| - | The minimum abbreviation of this command is IDT. | ||
| - | |||
| - | </ | ||
| - | IDT 0 !5220.00N/ | ||
| - | IDT 3 - Display current IDTEXT for port 3 | ||
| - | IDP 3 Test only - Override global IDTEXT on port 3 | ||
| - | |||
| - | </ | ||
| - | The IDTEXT must be a single line only. | ||
| - | |||
| - | Since the command line is limited to 80 characters, the | ||
| - | maximum length of IDTEXT that can be entered using this | ||
| - | command is 74 characters (IDTEXTs that exceed 74 characters | ||
| - | can only be specified in XROUTER.CFG). | ||
| - | |||
| - | </ | ||
| - | IDINTERVAL(7) | ||
| - | IDPATH(1) | ||
| - | IDTEXT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IFACE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IFACE -- Description.. | ||
| - | |||
| - | </ | ||
| - | IF[ace] A[dd] < | ||
| - | IF[ace] D[isplay] < | ||
| - | IF[ace] DR[op] < | ||
| - | IF[ace] L[ist] | ||
| - | IF[ace] STA[rt] < | ||
| - | IF[ace] STO[p] < | ||
| - | IF[ace] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The IFACE command can be used to add, modify, remove, list, | ||
| - | start and stop XRouter' | ||
| - | |||
| - | </ | ||
| - | This is a bit buggy at present. Not all of the commands work | ||
| - | properly for all types of interface. Stopping some types of | ||
| - | interface can cause XRouter to crash!! | ||
| - | |||
| - | </ | ||
| - | The A[dd] sub-command is used to create a new interface: | ||
| - | |||
| - | IF[ace] A[dd] < | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | [id] Optional name for the interface | ||
| - | |||
| - | Interface types (there are others): | ||
| - | |||
| - | AGW AGW Packet Engine | ||
| - | ASYNC Serial (COM) port | ||
| - | AXIP AX25 over IP | ||
| - | AXTCP AX25 over TCP | ||
| - | AXUDP AX25 over UDP | ||
| - | EXTERNAL | ||
| - | LOOPBACK | ||
| - | TCP Anything over TCP | ||
| - | TUN Linux " | ||
| - | UDP Anything over UDP | ||
| - | YAM YAM 1200/ | ||
| - | |||
| - | For example, to create interface 3 (providing iface 3 doesn' | ||
| - | already exist), type AXIP: | ||
| - | |||
| - | iface add 3 axip 256 My new interface | ||
| - | |||
| - | The DR[op] sub-command deletes an interface, for example: | ||
| - | |||
| - | IFACE DROP 3 | ||
| - | |||
| - | The L[ist] sub-command lists the interfaces, showing their | ||
| - | | ||
| - | |||
| - | IFACE LIST | ||
| - | |||
| - | G8PZT: | ||
| - | |||
| - | Num Type | ||
| - | 1 external ether 1064 eth0 | ||
| - | 2 axudp axudp | ||
| - | 3 axtcp axtcp | ||
| - | (End of list) | ||
| - | |||
| - | The D[isplay] sub-command displays the details of a single | ||
| - | interface: | ||
| - | |||
| - | iface d 1 | ||
| - | |||
| - | G8PZT: | ||
| - | Type=external, | ||
| - | Used by port(s): | ||
| - | MAC Address=B8: | ||
| - | |||
| - | If the argumemt is " | ||
| - | the interfaces are listed in detail. | ||
| - | |||
| - | The STA[rt] sub-command is used to bring an interface into | ||
| - | use, e.g.: | ||
| - | |||
| - | IFACE START 2 | ||
| - | |||
| - | The STO[p] sub-command takes an interface out of use, for | ||
| - | example: | ||
| - | |||
| - | IFACE STOP 2 | ||
| - | |||
| - | You cannot stop an interface which has dependent ports until | ||
| - | all those ports have first been stopped. At present, | ||
| - | stopping an Ethernet interface may cause a segfault. | ||
| - | |||
| - | Certain interface parameters can be changed on the fly, | ||
| - | using the general command form: | ||
| - | |||
| - | IF[ace] < | ||
| - | |||
| - | e.g. IFACE 4 ID Paula' | ||
| - | |||
| - | The following parameters are accepted so far, but as this is | ||
| - | a work in progress, they are not all fully functional... | ||
| - | |||
| - | COM CONFIG FLOW ID INTNUM IOADDR KISSOPTIONS MTU | ||
| - | NUMBER PROTOCOL SPEED TYPE | ||
| - | |||
| - | (CONFIG, PROTOCOL and MTU are not yet working) | ||
| - | |||
| - | </ | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====INFO.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | INFO -- Display information | ||
| - | |||
| - | </ | ||
| - | I[nfo] [nodecall | nodealias | topic] | ||
| - | I[nfo] PAGE | ||
| - | I[nfo] MORE | ||
| - | |||
| - | </ | ||
| - | The command is available to all users. | ||
| - | |||
| - | </ | ||
| - | The INFO command displays information about the node, and | ||
| - | other topics chosen by the sysop. It can also be used to | ||
| - | display information from other nodes. | ||
| - | |||
| - | </ | ||
| - | If no arguments are given, the text specified by INFOMSG in | ||
| - | XROUTER.CFG is sent to the user. | ||
| - | |||
| - | If [topic] is specified, the contents of the appropriate .INF | ||
| - | file, if it exists, are sent to the user instead. | ||
| - | |||
| - | If [topic] is " | ||
| - | |||
| - | " | ||
| - | infomation about the system, such as its location, software, | ||
| - | languages, services etc. | ||
| - | |||
| - | "INFO MORE" displays a built-in page showing technical | ||
| - | settings which may be of use when trying to diagnose network | ||
| - | problems. | ||
| - | |||
| - | If the argument is a nodecall or alias, and that node is an | ||
| - | XRouter, and it is in the nodes table, XRouter will obtain | ||
| - | information from the INFO service (NetRomX service 1) on that | ||
| - | node. The information is returned in a form which is readable | ||
| - | by both humans and machines. i.e. of the "< | ||
| - | form, with each piece of information on a separate line. | ||
| - | Every keyword is unique. | ||
| - | |||
| - | </ | ||
| - | I FOURPAK | ||
| - | I KIDDER | ||
| - | |||
| - | </ | ||
| - | Topic file names INFO.INF and MORE.INF are reserved. If you | ||
| - | create those files, they will not be displayed. | ||
| - | |||
| - | Info < | ||
| - | |||
| - | </ | ||
| - | The sysop may create INFO topics as required, and there is no | ||
| - | need to restart XRouter in order to activate them. | ||
| - | |||
| - | Each topic should be created as a plain text file with the | ||
| - | .INF extension and should be placed in the INFO subdirectory | ||
| - | located immediately under the router' | ||
| - | |||
| - | Files without the .INF extension will not be listed or | ||
| - | accessible. | ||
| - | |||
| - | </ | ||
| - | HELP(1) | ||
| - | INFO(9) | ||
| - | INFO-SVC(9) | ||
| - | MAN(1) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IPADDRESS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IPADDRESS -- Display / Set global or port IPADDRESS. | ||
| - | |||
| - | </ | ||
| - | IPA[ddress] <port | 0> [value] | ||
| - | |||
| - | </ | ||
| - | This command is sysop-only. | ||
| - | |||
| - | </ | ||
| - | The IPADDRESS command allows the global and port-specific | ||
| - | IP addresses to be displayed or changed. | ||
| - | |||
| - | The global and port IP addresses are specified in XROUTER.CFG, | ||
| - | but may be changed on the fly using this command. | ||
| - | |||
| - | The global IP address is inherited by all ports, and is | ||
| - | usually an amprnet (44-net) one. The port-specific addresses | ||
| - | are additional to the global one, and are used only on the | ||
| - | port on which they are specified. | ||
| - | |||
| - | The minimum abbreviation for this command is " | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, and it is a valid | ||
| - | port number, the current IPADDRESS for that port number | ||
| - | is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies a | ||
| - | port number and the second specifies a new IPADDRESS for | ||
| - | that port only. | ||
| - | |||
| - | If the first argument is zero, the command displays and sets | ||
| - | the global IPADDRESS. This address is inherited by all | ||
| - | ports, in addition to any port-specific address. | ||
| - | |||
| - | </ | ||
| - | IPA 0 - Display global IPADDRESS | ||
| - | IPA 0 44.131.91.2 | ||
| - | IPA 3 192.168.0.11 | ||
| - | |||
| - | </ | ||
| - | IPADDRESS(7) -- Main or Port IP Address. | ||
| - | IP-STACKS(6) -- IP Stacks in XRouter. | ||
| - | IP-PRIMER(9) -- IP Primer. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IPLINK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IPLINK -- Display / Set Port IPLINK Address. | ||
| - | |||
| - | </ | ||
| - | IPL[ink] < | ||
| - | |||
| - | </ | ||
| - | This command is sysop-only. | ||
| - | |||
| - | </ | ||
| - | The IPLINK command allows the specified port's IPLINK address | ||
| - | to be displayed and changed. | ||
| - | |||
| - | IPLINK is the AXIP or AXUDP link partner' | ||
| - | hostname. | ||
| - | |||
| - | It is usually specified within a PORT configuration block in | ||
| - | the XROUTER.CFG file, but since partner sysops sometimes | ||
| - | change their IP address or hostname, this command allows it | ||
| - | to be changed on the fly, without needing to take XRouter off | ||
| - | line. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, and it is a valid | ||
| - | port number, the current IPLINK value for that port, is | ||
| - | displayed, along with the equivalent IP address. | ||
| - | |||
| - | If two arguments are supplied, the first must specify a valid | ||
| - | port number and the second specifies a new IPLINK address for | ||
| - | that port. | ||
| - | |||
| - | If a hostname is specified, the IP address displayed in | ||
| - | brackets may still show the old value until a frame is sent | ||
| - | to, or received from the peer. | ||
| - | |||
| - | </ | ||
| - | IPLINK 16 - Display current IPLINK for port 16 | ||
| - | IPLINK 16 g8pzt.ath.cx | ||
| - | |||
| - | </ | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | IPLINK(7) | ||
| - | PORTS(6) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IP -- Display / Change IP routing parameters. | ||
| - | |||
| - | </ | ||
| - | IP B[an] A[dd] < | ||
| - | IP B[an] D[rop] < | ||
| - | IP B[an] L[ist] | ||
| - | IP B[an] P[ort] A[dd] < | ||
| - | IP B[an] P[ort] D[rop] < | ||
| - | IP B[an] P[ort] L[ist] | ||
| - | IP B[an] P[ort] S[ave] | ||
| - | IP B[an] S[ave] | ||
| - | IP C[onfig] | ||
| - | IP H[eard] | ||
| - | IP Q[uiet] [level] | ||
| - | IP ROUTES | ||
| - | IP R[oute] A[dd] < | ||
| - | [mode [metric [private]] | ||
| - | IP R[oute] ADDP[rivate] < | ||
| - | IP R[oute] C[md] [0-1] | ||
| - | IP R[oute] D[rop] < | ||
| - | IP R[oute] DE[fault] < | ||
| - | IP R[oute] L[ist] | ||
| - | IP R[oute] LO[ad] | ||
| - | IP R[oute] LOO[kup] < | ||
| - | IP T[tl] [ttl] | ||
| - | IP U[nban] < | ||
| - | |||
| - | </ | ||
| - | The IP ROUTES command is available to all, providing it | ||
| - | hasn't been disabled by sysop. The remaining commands are | ||
| - | sysop-only. | ||
| - | |||
| - | </ | ||
| - | The IP commands are used to display and alter some of the IP | ||
| - | parameters, the contents of the table responsible for | ||
| - | routing of IP datagrams, and the ban lists. | ||
| - | |||
| - | The arguments are as follows: | ||
| - | |||
| - | < | ||
| - | preferred, as it is more efficient. Route default | ||
| - | must always be an IP address. | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | For encapsulated modes (e,i,u), Netrom and reject | ||
| - | modes (r and s) this is ignored and should be 0. | ||
| - | For IPUDP, this can optionally specify the UDP | ||
| - | service number to use (default=94). | ||
| - | |||
| - | < | ||
| - | |||
| - | d = Datagram (direct) | ||
| - | e = Encap (ip-over-ip protocol 4) | ||
| - | i = IPIP (ip-over-ip protocol 94) | ||
| - | k = kernel (via Linux/ | ||
| - | n = Netrom (ip-over-netrom) | ||
| - | r = Reject | ||
| - | s = Silent discard | ||
| - | u = IPUDP (ip-over-UDP) | ||
| - | v = Virtual circuit (ip-over-ax25) | ||
| - | |||
| - | The usual mode is " | ||
| - | than perfect RF links, better performance can be | ||
| - | obtained by using Virtual Circuit mode. Netrom | ||
| - | mode is inefficient, | ||
| - | across non-ip parts of the network. | ||
| - | Encap, IPIP and IPUDP are used for tunneling | ||
| - | amateur IP across the public internet. | ||
| - | Reject and Silent discard are used to suppress | ||
| - | bouncing and looping. | ||
| - | Kernel mode is a dummy mode. It tells XRouter to | ||
| - | use the Windows / Linux IP stack for anything | ||
| - | matching the entry, but see Caveats below. | ||
| - | |||
| - | </ | ||
| - | The QUIET subcommand is used to display or set XRouter' | ||
| - | " | ||
| - | and TCP port probes. If the level is zero, XRouter behaves | ||
| - | normally. If a non-zero argument is supplied, XRouter becomes | ||
| - | stealthy. The stealth level is specified by adding the | ||
| - | following values: | ||
| - | |||
| - | 1 | ||
| - | 2 | ||
| - | 4 | ||
| - | 8 | ||
| - | | ||
| - | ROUTE CMD is used to allow / disallow the IP ROUTES and | ||
| - | IPR[outes] commands from being used by non-sysops. On amateur | ||
| - | networks however, it is considered bad practice to hide IP | ||
| - | routing. | ||
| - | |||
| - | The ROUTE DEFAULT subcommand sets up a default route which is | ||
| - | used when no other route is found. | ||
| - | specified, the target will be assumed to be a direct | ||
| - | neighbour. | ||
| - | |||
| - | The ROUTE ADD subcommand adds an entry to the routing table. | ||
| - | The first argument is the target host IP address, with | ||
| - | optional mask. e.g. 44.131.90.1/ | ||
| - | whereas 44.131.90.0/ | ||
| - | bits", and would route all 256 addresses from 44.131.90.0 to | ||
| - | 44.131.90.255. | ||
| - | The second argument is the " | ||
| - | address | ||
| - | The third argument is the port to route the datagram on, and | ||
| - | the last argument is the mode (see above). | ||
| - | |||
| - | The ROUTE ADDPRIVATE subcommand is the same as ROUTE ADD, | ||
| - | except that it marks the route " | ||
| - | non-sysops. The regular form has the same syntax as ROUTE ADD | ||
| - | and can accept any mode, whereas the shortened form is | ||
| - | provided for backward compatibility with " | ||
| - | only accept mode " | ||
| - | |||
| - | The ROUTE DROP subcommand removes an entry from the table. | ||
| - | Both the target host and the mask must match. | ||
| - | |||
| - | The ROUTE LOAD subcommand clears the existing IP parameters | ||
| - | and tables, and reloads them from IPROUTE.SYS. | ||
| - | |||
| - | The ROUTE LOOKUP subcommand displays the gateway and port | ||
| - | which XRouter will use to reach a given destination. | ||
| - | |||
| - | The CONFIG sub-command displays lots of information about the | ||
| - | IP configuration of the main stack and the various ports. | ||
| - | |||
| - | The HEARD subcommand displays the IP addresses from whom | ||
| - | datagrams have been received, along with the date and time | ||
| - | when they were last heard, the number of packets and number | ||
| - | of bytes received. | ||
| - | |||
| - | The TTL subcommand specifies the default "Time To Live" for | ||
| - | datagrams originating at this host. | ||
| - | |||
| - | Sub-commands "IP BAN ADD" and "IP BAN DROP" allow manual | ||
| - | editing of the " | ||
| - | commands, IP BAN and IP UNBAN, still work.... | ||
| - | |||
| - | The sub-command "IP BAN SAVE" saves the list of banned IP | ||
| - | addresses to the file IPBAN.SYS. The contents of the file | ||
| - | are reloaded at boot-up. The ban list is always saved at | ||
| - | closedown, but this command can be used in CRONTAB.SYS to | ||
| - | additionallly save the ban list from time to time in case of | ||
| - | power cuts. | ||
| - | |||
| - | Sub-commands IP BAN PORT ADD, IP BAN PORT DROP, IP BAN PORT | ||
| - | LIST, and IP BAN PORT SAVE allow management of the " | ||
| - | ports (see below). | ||
| - | |||
| - | </ | ||
| - | IP ROUTE DEFAULT 3 44.131.90.6 v | ||
| - | IP ROUTE ADD 44.131.95.0/ | ||
| - | IP ROUTE DROP 44.131.97.1 32 | ||
| - | IP ROUTE LOOKUP bbc.co.uk | ||
| - | IP BAN PORT ADD tcp 445 | ||
| - | |||
| - | </ | ||
| - | The IP commands may be used in IPROUTE.SYS and BOOTCMDS.SYS | ||
| - | but the only ones that have any meaning in those locations | ||
| - | are IP ROUTE ADD, IP ROUTE DEFAULT, IP TTL and IP QUIET. It | ||
| - | is usual to define IP routing in IPROUTE.SYS. | ||
| - | |||
| - | When XRouter boots, it first reads IPROUTE.SYS, | ||
| - | ENCAP.TXT, then finally BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | Mode " | ||
| - | TCP/IP services to reach this destination", | ||
| - | only for when the XRouter stack can't be used. | ||
| - | |||
| - | For " | ||
| - | to route raw IP traffic through its stack. It actively | ||
| - | blocks IP protocol 4 (IPEncap), and puts severe restrictions | ||
| - | on TCP and UDP traffic. | ||
| - | |||
| - | Windows allows XRouter to originate and terminate TCP, UDP, | ||
| - | IPIP, ICMP and AXIP, but not to *route* those protocols. | ||
| - | Therefore you may Telnet and Ping from XRouter, but you are not | ||
| - | allowed to route 3rd party traffic, e.g. from RF to Internet. | ||
| - | |||
| - | </ | ||
| - | The IP routing table is necessary only for IP, and does not | ||
| - | take any part in normal ax25 and Netrom activities. | ||
| - | full manual for details on how to set up the IP system. | ||
| - | |||
| - | Please do not over-use ADDPRIVATE, as it hinders the | ||
| - | diagnosis of networking problems, and many consider it to | ||
| - | be contrary to the spirit of Ham Radio. | ||
| - | |||
| - | Honeypots | ||
| - | ~~~~~~~~~ | ||
| - | In this context, a honeypot a sticky trap, set up on popular | ||
| - | TCP or UDP ports, for catching internet low-life. | ||
| - | |||
| - | Hackbots generally start their attacks by probing for open | ||
| - | TCP ports, and to save time they often start with the most | ||
| - | popular ones - telnet, SSH, HTTP, VNC and so on. If they find | ||
| - | an open port, they tend to inform each other, then they all | ||
| - | concentrate their attacks on that port. | ||
| - | |||
| - | Unless you have a particular service port open, the chances | ||
| - | are that anyone who tries to connect to it is up to no good. | ||
| - | So the honeypot is a mitigation measure. It LOOKS like an | ||
| - | attractive open port, but it's not! Anyone who connects to it | ||
| - | gets their IP address logged and banned. After that they | ||
| - | can't do any more attacking unless they change their IP | ||
| - | address. | ||
| - | |||
| - | It's not foolproof. Nation states and sophisticated hackers | ||
| - | have access to virtually unlimited IP addresses. But it slows | ||
| - | them down, and the IDS alerts you that there is a problem. | ||
| - | |||
| - | </ | ||
| - | IP-PRIMER(9) -- IP Addressing / Routing Primer. | ||
| - | IPROUTE(1) | ||
| - | IDS(9) | ||
| - | IPBAN.SYS(8) -- Banned IP addresses File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====IPROUTE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | IPROUTE -- Display IP routing table. | ||
| - | |||
| - | </ | ||
| - | IPR[OUTE] | ||
| - | |||
| - | </ | ||
| - | The IPROUTE command, which may be abbreviated to IPR, displays | ||
| - | the contents of the table responsible for routing of IP | ||
| - | datagrams. | ||
| - | |||
| - | For each route it displays the IP address, the subnet mask, | ||
| - | the gateway address, the port and the mode (Datagram, VC or | ||
| - | Netrom). | ||
| - | |||
| - | The command "IP ROUTES" | ||
| - | |||
| - | </ | ||
| - | The IP routing table is initialised from file IPROUTE.SYS when | ||
| - | the router is started, and may contain other entries " | ||
| - | by the system, or entered by the sysop. | ||
| - | any way for normal AX25 and NETROM activities. | ||
| - | |||
| - | </ | ||
| - | The IPROUTE command is available to all users, providing the | ||
| - | sysop hasn't disabled it. However, routes marked as " | ||
| - | are only displayed to sysops. | ||
| - | |||
| - | </ | ||
| - | IP(1) -- Add / Delete / List IP routing entries. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====J.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | J -- Displays recently connected stations. | ||
| - | |||
| - | </ | ||
| - | J | ||
| - | |||
| - | </ | ||
| - | The J (JustHeard) command lists the callsigns of the last 20 | ||
| - | stations who have connected to XRouter since it was booted. | ||
| - | |||
| - | The " | ||
| - | |||
| - | AGWH - AGW Host app APPL - Uplink to app | ||
| - | APRS - APRS Server | ||
| - | CHAT - Chat session | ||
| - | CONS - Console | ||
| - | DEDH - WA8DED Host app DSCD - Discard server | ||
| - | DXSV - DX Server | ||
| - | FING - Finger server | ||
| - | FTPS - FTP Server | ||
| - | HLIB - Hamlib | ||
| - | HTRM - HTTP Terminal | ||
| - | INFO - Info server | ||
| - | MQTT - MQTT Server | ||
| - | NTPX - NetRom/TCP Proxy NTRM - Netrom | ||
| - | PMS - Personal Msg System PRXY - Proxy | ||
| - | PSTN - Dial-in | ||
| - | RHPC - RHP Control Sess RHPP - RHP SeqPacket Socket | ||
| - | RHPS - RHP Stream Socket | ||
| - | RLOG - Remote Login SMS - Short Message | ||
| - | Sock - Socket app SOKH - Uplink to Socket host | ||
| - | SOKS - SOCKS Proxy Teln - Telnet | ||
| - | TPXY - Telnet Proxy TTY - Serial TTY | ||
| - | TTYL - TTYLink | ||
| - | |||
| - | The " | ||
| - | Netrom level 4 connection, the user's node is also shown, in | ||
| - | the form < | ||
| - | |||
| - | The " | ||
| - | logged off. | ||
| - | |||
| - | The " | ||
| - | minutes. | ||
| - | |||
| - | The "Bytes from/ | ||
| - | layer 7) bytes were received from, and sent to the user. | ||
| - | |||
| - | </ | ||
| - | G8PZT: | ||
| - | Type Usercall | ||
| - | CHAT G1WXA-6@GB7BHM | ||
| - | AX25 GB7COV-14 | ||
| - | NTRM GB7PZT@GB7PZT | ||
| - | PMS | ||
| - | (End of list) | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | USERS(1) -- Display current users | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====KEEPALIVE.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | KEEPALIVE -- Display / Change KEEPALIVE time for a port. | ||
| - | |||
| - | </ | ||
| - | KE[eepalive] < | ||
| - | |||
| - | </ | ||
| - | Displays the current AXIP / AXUDP " | ||
| - | specified port, or allows it to be changed. | ||
| - | |||
| - | If the second argument is omitted, the current value is | ||
| - | displayed, otherwise the value in seconds is used. | ||
| - | |||
| - | The new setting overrides the value specified by the | ||
| - | KEEPALIVE directive in the XROUTER.CFG file, and remains in | ||
| - | force until changed, or until the next restart. | ||
| - | |||
| - | Keep-alives are only used on AXIP and AXUDP ports. This | ||
| - | command has no effect on other types of port. | ||
| - | |||
| - | </ | ||
| - | KEEPALIVE 2 - Display port 2 keepalive interval | ||
| - | KE 2 120 - Set port 2 keepalive to 120 seconds | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | AXIP(9) | ||
| - | AXUDP(9) | ||
| - | KEEPALIVE(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====KILL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | KILL -- Terminate any session | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | Immediately terminates the specified session(s), | ||
| - | disconnecting any links. | ||
| - | troublemakers or failed sessions. | ||
| - | |||
| - | To kill multiple sessions, use "KILL ALL", or list the | ||
| - | session numbers with space(s) (not commas) between each one. | ||
| - | |||
| - | Session numbers are shown by the U(sers) command. | ||
| - | |||
| - | </ | ||
| - | K 301 - Terminate session numbered 301 | ||
| - | K 123 456 789 - Terminate sessions 123, 456 and 789 | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | You are not allowed to kill your own session. | ||
| - | |||
| - | </ | ||
| - | USERS(1) -- Display current users | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LANG.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LANG -- Display / Set Session Language | ||
| - | |||
| - | </ | ||
| - | | ||
| - | |||
| - | </ | ||
| - | The LANG command can be used to display the available | ||
| - | languages, report the current language, or change the | ||
| - | language for the session. | ||
| - | |||
| - | As of October 2023 only English (en), French (fr), Spanish | ||
| - | (es) and Dutch (nl) are available. German (de) is still in | ||
| - | progress. More languages can be added if there is any | ||
| - | demand for them. | ||
| - | |||
| - | The default language for XRouter is set by the DEFAULTLANG | ||
| - | directive in XROUTER.CFG. | ||
| - | |||
| - | The initial language for a session is controlled by entries | ||
| - | in LANGS.SYS, if it exists. | ||
| - | |||
| - | </ | ||
| - | If used without arguments, LANG displays the available | ||
| - | language codes, for example: | ||
| - | |||
| - | lang | ||
| - | G8PZT: | ||
| - | |||
| - | If the argument is a known language code, and the | ||
| - | corresponding language file was present in the working | ||
| - | directory when XRouter was started, the language for the | ||
| - | session is changed as follows: | ||
| - | |||
| - | lang es | ||
| - | G8PZT: | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | CONSOLELANG(7) -- Console language | ||
| - | DEFAULTLANG(7) -- Specify default language | ||
| - | LANGS.SYS(8) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LINKED.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LINKED -- Specify Temporary Callsign. | ||
| - | |||
| - | </ | ||
| - | *** LINKED AS < | ||
| - | |||
| - | </ | ||
| - | The "*** LINKED AS" command allows you to change your uplink | ||
| - | callsign for the duration of the current session. This should | ||
| - | be used for test purposes only. | ||
| - | |||
| - | </ | ||
| - | *** LINKED AS G8PZT - Set console callsign to " | ||
| - | |||
| - | </ | ||
| - | Usually Sysop-only, but may additionally be made available to | ||
| - | users and/or applications, | ||
| - | in XROUTER.CFG. | ||
| - | |||
| - | It is recommended that this command is NOT made available to | ||
| - | users. | ||
| - | |||
| - | </ | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LINKS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LINKS -- Displays the currently active level 2 sessions. | ||
| - | |||
| - | </ | ||
| - | L[inks] | ||
| - | |||
| - | </ | ||
| - | The LINKS command lists level 2 user up/ | ||
| - | node links. | ||
| - | callsigns being used at both ends of the link plus some other | ||
| - | data, such as frame counts and retry rates. | ||
| - | |||
| - | The command may be abbreviated to " | ||
| - | |||
| - | </ | ||
| - | G8PZT: | ||
| - | Remote Local Prt Sta Ver Try T3 | ||
| - | G4FPV G8PZT | ||
| - | GB7PZT G8PZT | ||
| - | GB7GH G8PZT | ||
| - | (End of list) | ||
| - | |||
| - | Remote - L2 callsign at far end of link | ||
| - | Local - L2 callsign at our end of the link. | ||
| - | Prt - Port number | ||
| - | Sta - Link state (2 = connecting, 4 = disconnecting, | ||
| - | 5 = connected) | ||
| - | Ver - AX25 version number | ||
| - | Try - Retry count | ||
| - | T3 - Current state of the LAPB T3 countdown in secs | ||
| - | Pac - Paclen | ||
| - | Max - Maxframe | ||
| - | Idle - Secs since there was any activity on the link | ||
| - | Txq - No. of L2 frames queued for transmission | ||
| - | Rxq - No. of L2 frames on receive queue | ||
| - | Asm - No. of frame fragments awaiting reassembly | ||
| - | |||
| - | </ | ||
| - | The LINKS command is available to all users. | ||
| - | |||
| - | </ | ||
| - | AXROUTES(1) -- Display current & recent L2 links | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LISTEN.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | LISTEN -- Listen For Incoming Connections. | ||
| - | |||
| - | </ | ||
| - | LIS[ten] < | ||
| - | |||
| - | </ | ||
| - | The LISTEN command, which can be abbreviated to " | ||
| - | initiates " | ||
| - | |||
| - | In this mode the user is (optionally) able to " | ||
| - | traffic on the chosen port, and the node will accept incoming | ||
| - | connections to the user's callsign. | ||
| - | |||
| - | For scurity reasons, non-sysops may only listen on RADIO | ||
| - | ports. It is not possible to listen on the session' | ||
| - | port. | ||
| - | |||
| - | Traffic monitoring is enabled by default, but may be disabled | ||
| - | by supplying 0 (zero) as an optional additional argument. | ||
| - | |||
| - | All the normal node commands are available in listen mode. | ||
| - | Additionally the CQ command can be used to advertise the | ||
| - | user's presence. | ||
| - | |||
| - | The user's SSID is inverted in the usual Net/Rom way, so if | ||
| - | the uplink is G9XYZ, they will be listening and beaconing as | ||
| - | G9XYZ-15. | ||
| - | |||
| - | Upon incoming connection to a " | ||
| - | is disabled, the user is notified of the incoming connection, | ||
| - | and the connection becomes a normal " | ||
| - | |||
| - | If either party disconencts, | ||
| - | |||
| - | </ | ||
| - | To exit listen mode use " | ||
| - | |||
| - | </ | ||
| - | LISTEN 3 - Listen on port 3 with traffic monitoring. | ||
| - | LISTEN 5 0 - Listen on port 5 without traffic monitoring. | ||
| - | LIS OFF - Exit listen mode. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | CQ(1) -- Send a CQ Message. | ||
| - | WATCH(1) -- Monitor traffic on port(s). | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LOADNODES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LOADNODES -- Load the nodes and routes tables from disk. | ||
| - | |||
| - | </ | ||
| - | LOADNODES [filename] | ||
| - | |||
| - | </ | ||
| - | The LOADNODES command loads the nodes and routes tables from | ||
| - | a " | ||
| - | down, unless the " | ||
| - | start up, unless the " | ||
| - | |||
| - | The recovery file is used to reconstruct the Netrom routing | ||
| - | tables without having to wait for nodes broadcasts to be | ||
| - | received. | ||
| - | tables at any time without taking XRouter off line. | ||
| - | |||
| - | The optional argument specifies the filename to load from, and | ||
| - | if not specified it defaults to XRNODES. | ||
| - | |||
| - | It is recommended that, once in a while, you use the SAVENODES | ||
| - | command to save a " | ||
| - | other than XRNODES. | ||
| - | become depleted, for example due to a radio failure, they can | ||
| - | be reloaded when the problem is fixed, without rebooting. | ||
| - | |||
| - | </ | ||
| - | LOADNODES | ||
| - | LOADNODES nodebak.txt | ||
| - | |||
| - | </ | ||
| - | The XRNODES file is similar in format to the BPQNODES file | ||
| - | used with the DOS version of BPQ node, but is no longer | ||
| - | compatible with it. | ||
| - | |||
| - | XRNODES is a plain text file, which may be viewed with | ||
| - | Notepad by adding the extension .TXT. | ||
| - | |||
| - | </ | ||
| - | The LOADNODES command should be used with caution, because it | ||
| - | can result in obsolete nodes being re-introduced into the node | ||
| - | table. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | SAVENODES(1) -- Save Nodes and Routes to Disk. | ||
| - | XRNODES(8) -- Nodes / Routes Recovery File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====LOG.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | LOG -- Control activity logging. | ||
| - | |||
| - | </ | ||
| - | LOG [ON | OFF] | ||
| - | LOG < | ||
| - | LOG < | ||
| - | |||
| - | </ | ||
| - | Console, BOOTCMDS.SYS, | ||
| - | |||
| - | </ | ||
| - | The LOG command is used to enable or disable the logging | ||
| - | of XRouter activity, such as connections, | ||
| - | errors, user commands etc. It overrides the default setting | ||
| - | that was specified using " | ||
| - | finer control. | ||
| - | |||
| - | </ | ||
| - | If LOG is used without arguments, the current setting of the | ||
| - | "log flags" is shown. These are simple on-off switches for | ||
| - | the various layers / sub-systems. The number returned is the | ||
| - | sum of the active flags in the " | ||
| - | below: | ||
| - | |||
| - | | ||
| - | | ||
| - | 1 Enable/ | ||
| - | 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) | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | If the argument to LOG is a numeric value between 0 and 16383 | ||
| - | the log flags are set to that value. | ||
| - | |||
| - | For example, to log session layer and Netrom L4 activity in | ||
| - | Windows/DOS format, you would use "LOG 23" (1+2+4+16). To log | ||
| - | EVERYTHING, it would be "LOG 16383", | ||
| - | except PCAP (packet capture), LOG would be 15871 (16383-512). | ||
| - | |||
| - | If a "log flag" is " | ||
| - | that subsystem or group of subsystems is set to 6, i.e. | ||
| - | " | ||
| - | level is 0 (no logging). | ||
| - | |||
| - | If the argument to LOG is the mnemonic of a sub-system, the | ||
| - | verbosity " | ||
| - | changed. Sub-system mnemonics currently supported are: | ||
| - | |||
| - | Mnemonic | ||
| - | -------------------------------------------- | ||
| - | AGWC AGW Client | ||
| - | AXTCP AXTCP Interface | ||
| - | CHAT Chat server | ||
| - | CONS Console | ||
| - | FTPC FTP and NFTP clients | ||
| - | FTPS FTP and NFTP servers | ||
| - | HTTP HTTP server | ||
| - | IFTCP TCP interface | ||
| - | INP3 Inp3 network admin | ||
| - | LAPB AX25 connected mode | ||
| - | MAPD Map update daemon | ||
| - | MQTT MQTT client, broker and daemon | ||
| - | NRL3 Netrom layer 3 | ||
| - | NRL4 Netrom layer 4 | ||
| - | ODN | ||
| - | PROC Daemon processes | ||
| - | PMS | ||
| - | PMSD PMS forwarding daemon | ||
| - | SESS Session layer | ||
| - | SMSD Short Message System forwarding daemon | ||
| - | TCPH TCP operations on host (kernal) stack | ||
| - | TELN Telnet | ||
| - | |||
| - | As the conversion of the logging subsystem is only partially | ||
| - | complete, more mnemonics will be added in due course. Use the | ||
| - | LOG command without arguments to list the available mnemonics. | ||
| - | |||
| - | < | ||
| - | LOWER the number, the higher the importance of the | ||
| - | information, | ||
| - | represent errors and events that must not be ignored, whilst | ||
| - | the highest level is for verbose debug information that you | ||
| - | wouldn' | ||
| - | |||
| - | Level Meaning | ||
| - | ------------------------------------------------ | ||
| - | 0 Total system failure | ||
| - | 1 Immediate action required | ||
| - | 2 Critical errors, e.g. hardware problems | ||
| - | 3 Survivable software errors | ||
| - | 4 Warnings | ||
| - | 5 Notifications that may need attention | ||
| - | 6 Normal operational messages | ||
| - | 7 Debugging | ||
| - | |||
| - | Events are only logged if their priority level is equal to | ||
| - | or LOWER than the " | ||
| - | For example, if a subsystem' | ||
| - | operational information, | ||
| - | but debug information isn't. If the verbosity level is 4, | ||
| - | only the warnings and errors are logged. If the verhosity | ||
| - | level is 0, nothing is logged. | ||
| - | |||
| - | In the absence of the " | ||
| - | logging defaults OFF. | ||
| - | |||
| - | </ | ||
| - | LOG 19 -- Log NetRom layer 4 in CRLF format | ||
| - | LOG OFF -- Turn logging off (retains flags) | ||
| - | LOG ON -- Turn logging back on with previous settings | ||
| - | LOG SESS 4 -- Log warnings and errors from session layer | ||
| - | |||
| - | </ | ||
| - | Log files are created in the LOG sub-directory of the XRouter | ||
| - | working directory. One file is created per day, running from | ||
| - | midnight to midnight local time. The files are plain text, | ||
| - | and the file names take the form YYMMDD.LOG. e.g. 130119.LOG. | ||
| - | |||
| - | The format of the entries in the log files is as follows: | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | detailed in the table above. | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | various machine-readable action codes. | ||
| - | |||
| - | Example: | ||
| - | |||
| - | 004101 7 CHAT: Peer G8PZT-8 sess 6 timeout | ||
| - | 004101 6 NRL4: Requesting disconnect from G8PZT-8, | ||
| - | theirCct=2930 ourCct=6 | ||
| - | 004101 6 SESS: 6 G8PZT-8@G8PZT-8 SK R:97 S:33 | ||
| - | 004121 6 NRL3: L3RTT request to G8PZT | ||
| - | 004121 6 NRL3: L3RTT request to G8PZT-14 | ||
| - | 004121 6 NRL3: L3RTT reply from G8PZT, TT=60ms | ||
| - | 004206 7 PROC: PB MAPD | ||
| - | |||
| - | The meaning of the action codes are as follows (incomplete | ||
| - | list): | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | The reason for the cryptic logging is to (a) save space and | ||
| - | (b) allow the logs to be analysed by programs, for example to | ||
| - | generate usage statistics. | ||
| - | |||
| - | </ | ||
| - | Logging is useful if you are trying to rack down a problem, | ||
| - | but it generates large volumes of data. This is unlikely to | ||
| - | be an issue on a modern PC, but may become so if you were | ||
| - | running XRouter on a 256Mb USB memory stick for example. | ||
| - | |||
| - | The effect of logging on the longevity of SD cards is not | ||
| - | known, but the author has had full debug logging enabled for | ||
| - | at least 5 years with no problems. | ||
| - | |||
| - | </ | ||
| - | LOG(7) | ||
| - | BOOTCMDS.SYS(8) -- Commands to run at bootup | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====!.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ! -- Run a command or program in an O/S shell. | ||
| - | |||
| - | </ | ||
| - | ! <cmd> [args...] | ||
| - | |||
| - | </ | ||
| - | Sysops only. | ||
| - | |||
| - | </ | ||
| - | The " | ||
| - | in a temporary operating system shell which terminates upon | ||
| - | completion of the program or command. | ||
| - | |||
| - | It is suitable for simple non-interactive commands such as | ||
| - | " | ||
| - | requiring any further input from the user. | ||
| - | |||
| - | The " | ||
| - | |||
| - | </ | ||
| - | "! ls /dev" | ||
| - | |||
| - | </ | ||
| - | Running interactive commands or programs via this means is | ||
| - | (e.g. piping a directory listing via MORE) not possible. | ||
| - | XRPi is suspended while the external command or program | ||
| - | runs. This will be rectified in future versions. | ||
| - | |||
| - | </ | ||
| - | This might seem pointless on a modern operating system. Why not | ||
| - | just open another terminal, a VNC or SSH session? | ||
| - | |||
| - | But if XRPi is on a remote hilltop and its only connection | ||
| - | with the outside world is via the RF Packet Radio network (not | ||
| - | unusual for a packet node) you can't run VNC or SSH. | ||
| - | |||
| - | This command allows you to do simple Linux administration over | ||
| - | the air with the most basic of equipment. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | [email protected]===== | ||
| - | < | ||
| - | </ | ||
| - | @ -- Request / answer password challenge | ||
| - | |||
| - | </ | ||
| - | @ [string] | ||
| - | |||
| - | </ | ||
| - | In order to gain access to sensitive commands, remote sysops | ||
| - | must first complete a password challenge. | ||
| - | remote sysop enters " | ||
| - | matrix consisting of 5 lines of 5 numbers thus: | ||
| - | |||
| - | 4 1 6 3 7 | ||
| - | 3 5 2 6 3 | ||
| - | 7 1 9 2 4 | ||
| - | 2 7 1 4 6 | ||
| - | 3 5 2 6 1 | ||
| - | |||
| - | The remote sysop must then choose ONE of the lines, and send | ||
| - | the " | ||
| - | password string which correspond to the 5 numbers on the | ||
| - | chosen line. There must be a space after the " | ||
| - | spaces between the characters. | ||
| - | |||
| - | If the uplink is secure, the password may be entered in plain | ||
| - | text, e.g. "@ mypassword", | ||
| - | recommended on RF links! | ||
| - | |||
| - | If the challenge is correctly answered, the system replies | ||
| - | with " | ||
| - | |||
| - | </ | ||
| - | If the user does not have a password registered in | ||
| - | PASSWORD.SYS, | ||
| - | command" | ||
| - | |||
| - | </ | ||
| - | Console sysops already have full access and don't need to use | ||
| - | this command. | ||
| - | |||
| - | </ | ||
| - | PASSWORD.SYS(8) -- Sysop Password File. | ||
| - | USERPASS.SYS(8) -- User Passwords File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAN.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MAN -- Display Sysop' | ||
| - | |||
| - | </ | ||
| - | MAN [section] [topic] | ||
| - | |||
| - | </ | ||
| - | The MAN command is used to access the sysop' | ||
| - | consists of a collection of pages, each covering a different | ||
| - | command or topic. | ||
| - | |||
| - | The MAN pages are designed for sysop use, and usually give | ||
| - | more detail than the corresponding HELP pages. | ||
| - | |||
| - | The manual is divided into several sections as follows: | ||
| - | |||
| - | | ||
| - | | ||
| - | 1 General Commands | ||
| - | 2 Chat Server Commands | ||
| - | 3 PZTDOS commands | ||
| - | 4 Mailbox commands | ||
| - | 6 Installation & Configuration Topics | ||
| - | 7 Configuration Directives | ||
| - | 8 Configuration / System Files. | ||
| - | 9 Miscellaneous Topics | ||
| - | |||
| - | Some manual files are longer than the standard console review | ||
| - | buffer size, and may therefore display only the last 400 or | ||
| - | so lines. However they can be viewed in full via the HTTP | ||
| - | interface, and by using < | ||
| - | console. | ||
| - | |||
| - | </ | ||
| - | Use MAN SECTIONS to list the sections. | ||
| - | |||
| - | Entering MAN alone displays a list of available topics in | ||
| - | section 1. | ||
| - | |||
| - | To read a specific page in section 1, enter MAN followed by | ||
| - | the topic for which you require help. | ||
| - | |||
| - | To list topics in any other section, enter MAN followed by the | ||
| - | section number. | ||
| - | |||
| - | To read a topic in a section other than 1, enter MAN followed | ||
| - | by a space, the section number, a space then the topic. | ||
| - | |||
| - | If a topic name contains wildcards, all matching topic names | ||
| - | in the section are displayed. | ||
| - | |||
| - | </ | ||
| - | MAN ARP Display section 1 page for ARP command. | ||
| - | MAN 7 List the topics in section 7 | ||
| - | MAN 7 MAXTT Display section 7 page for MAXTT directive | ||
| - | MAN 4 I* List section 4 topics begining with ' | ||
| - | |||
| - | </ | ||
| - | The following conventions are used in MAN pages: | ||
| - | |||
| - | < > | ||
| - | enclosed within them represent any piece of text | ||
| - | typed after the command. | ||
| - | of the argument. | ||
| - | |||
| - | [ ] | ||
| - | which is not always present. If used within a | ||
| - | command name (e.g. N[ODES]), this indicates that | ||
| - | the command may be abbreviated to a minimum form | ||
| - | while remaining unique. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | Manual files are normal text files, with the extension | ||
| - | changed to " | ||
| - | simple text editor such as Notepad (windows) or Leafpad, nano | ||
| - | etc (Linux). | ||
| - | |||
| - | All MAN files are located within the MAN directory, which | ||
| - | itself is in the directory containing XRouter. | ||
| - | |||
| - | As MAN files are for use only by the sysop, there is no need | ||
| - | for separate directories for alternate language versions. | ||
| - | Even if the MAN files are translated to a different language, | ||
| - | they must always be situated in the MAN directory, not in a | ||
| - | subdirectory thereof | ||
| - | |||
| - | Filenames, including the extensions, MUST be in UPPER CASE. | ||
| - | Lower case filenames and files without the .MAN extension are | ||
| - | ignored. | ||
| - | |||
| - | Within the .MAN files, lines beginning with a semicolon ';' | ||
| - | are not displayed, so you can use them for comments, such as | ||
| - | file modification details. | ||
| - | |||
| - | Manual files can be viewed from the console using < | ||
| - | followed by <M>. This browser window is only around 76 | ||
| - | characters wide, so try to keep the lines shorter than this, | ||
| - | to preserve formatting. In any case, lines longer than 72 | ||
| - | characters are bad practice, typopgraphically-speaking. | ||
| - | |||
| - | </ | ||
| - | Although most commands may be abbreviated, | ||
| - | possible for the MAN command to correctly identify the | ||
| - | required page from an abbreviated argument. | ||
| - | is acceptable, whereas "MAN NO" is not. Use wildcards if | ||
| - | necessary. | ||
| - | |||
| - | </ | ||
| - | Due to its size and complexity, it would be impractical to | ||
| - | produce a single-document sysop manual for XRouter. Therefore | ||
| - | the manual only exists as a series of standalone pages with | ||
| - | cross references. This makes it easier to keep the manual up | ||
| - | to date by distributing new / updated pages as required. At | ||
| - | present this is a " | ||
| - | masy one day be automated. | ||
| - | |||
| - | </ | ||
| - | HELP(1) -- General help system. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MAXFRAME.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MAXFRAME -- Display / Set port MAXFRAME value. | ||
| - | |||
| - | </ | ||
| - | MAX[FRAME] < | ||
| - | |||
| - | </ | ||
| - | MAXFRAME is a sysop-only command. | ||
| - | |||
| - | </ | ||
| - | The MAXFRAME command is used to display and set the AX25 L2 | ||
| - | MAXFRAME (window) value for the specified port. This is the | ||
| - | maximum number of unacknowledged frames allowed before the | ||
| - | link must stop and wait for an ack. The normal range is | ||
| - | between 1 and 7, although maxframes of up to 127 are allowed | ||
| - | in modulo-128 links. | ||
| - | |||
| - | If the second argument is ommitted, the current value is | ||
| - | displayed. | ||
| - | |||
| - | If the setting is changed, the new setting remains in force | ||
| - | until it is changed again, or until the router is restarted, | ||
| - | in which case it returns to the default value specified in the | ||
| - | port entry in the XROUTER.CFG file. | ||
| - | |||
| - | If the port PACLEN is set to 0, XRouter dynamically adapts | ||
| - | MAXFRAME (and PACLEN) to the link conditions, to maximise | ||
| - | throughput. | ||
| - | |||
| - | </ | ||
| - | MAX 2 - Display current maxframe setting for port 2 | ||
| - | MAX 2 6 - Set maxframe for port 2 to 6. | ||
| - | |||
| - | </ | ||
| - | MAXFRAME(7) | ||
| - | PACLEN(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHCLEAR.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHCLEAR -- Clear MHeard list | ||
| - | |||
| - | </ | ||
| - | MHC[lear] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The MHCLEAR command clears the MH list for the specified port, | ||
| - | and would typically be used if the radio had been changed from | ||
| - | one frequency to another. | ||
| - | are cleared. | ||
| - | |||
| - | </ | ||
| - | MHC 3 -- Clears port 3 MHeard list | ||
| - | |||
| - | </ | ||
| - | MHEARD(1) | ||
| - | MHFLAGS(1) | ||
| - | MHSIZE(1) | ||
| - | MHEARD(7) | ||
| - | MHEARD(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHEARD.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHEARD -- List recently heard stations. | ||
| - | |||
| - | </ | ||
| - | MH[eard] [nodecall] <portnum | ALL> | ||
| - | |||
| - | </ | ||
| - | The MHEARD command is available to all users. | ||
| - | |||
| - | </ | ||
| - | If the facility is enabled on the specified port, the MHEARD | ||
| - | command lists the most recently heard stations on that port, | ||
| - | along with the date / time of reception, the number of frames | ||
| - | heard, and various other information (see below). | ||
| - | |||
| - | This is useful for users to discover who else the router can | ||
| - | hear, to aid the search for suitable digipeaters, | ||
| - | diagnose problems. | ||
| - | only usually one partner, it provides a useful indication when | ||
| - | the frequency is being encroached, either by deliberate | ||
| - | squatting, unauthorised attempts to link, or lift conditions. | ||
| - | |||
| - | The command may be abbreviated to " | ||
| - | |||
| - | </ | ||
| - | A < | ||
| - | |||
| - | If the first argument is the callsign or alias of a known | ||
| - | node, the MHeard list of that node is requested, provided the | ||
| - | target node is XRouter v502s or later. In this case, the | ||
| - | second argument specifies the port number on the target node. | ||
| - | If a second argument is not supplied, or is 0 (zero), the | ||
| - | MHeard-enabled ports on the target node are listed. | ||
| - | |||
| - | If < | ||
| - | "MH KIDDER ALL", the response is a single MHeard list, | ||
| - | containing up to 100 entries from all MH-enabled ports, with | ||
| - | the most recently heard at the start of the list | ||
| - | |||
| - | </ | ||
| - | MH 3 - Display heard list for port 3 on this node | ||
| - | MH ALL - Display heard list for all ports on this node | ||
| - | MH KIDDER 16 - Display heard list for port 16 on KIDDER node | ||
| - | |||
| - | G8PZT: | ||
| - | Callsign | ||
| - | G1LOA-10 | ||
| - | G3TQG-2 | ||
| - | GB7PZT-15 09/06 13:18 708 | ||
| - | DY25 09/06 10:19 | ||
| - | |||
| - | Date - Date when this callsign was last heard. | ||
| - | Time - Time when this callsign was last heard. | ||
| - | Frames | ||
| - | Via - Digipeater relaying this station, direct if blank. | ||
| - | Type - Flags as follows: | ||
| - | D - This station is a digipeater | ||
| - | N - This station is a node | ||
| - | I - This station handles IP traffic | ||
| - | A - This station handles ARP traffic | ||
| - | Position - Position derived from APRS broadcast | ||
| - | Dist - Distance calculated from APRS broadcast | ||
| - | Dir - Bearing in degrees, calculated from APRS broadcast | ||
| - | |||
| - | </ | ||
| - | For each port, the MH facility can be enabled / disabled and | ||
| - | the maximum length of the list specified by appropriate | ||
| - | entries in the PORT sections of the XROUTER.CFG file, | ||
| - | e.g. " | ||
| - | " | ||
| - | |||
| - | </ | ||
| - | MHCLEAR(1) | ||
| - | MHFLAGS(1) | ||
| - | MHSIZE(1) | ||
| - | MHEARD(7) | ||
| - | MHEARD(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHFLAGS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHFLAGS -- Display / Set MHeard options. | ||
| - | |||
| - | </ | ||
| - | MHF[lags] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The MHFLAGS command is used to display and/or set the | ||
| - | MHEARD options for a specified port. These flags control | ||
| - | which callsigns are recorded in the MH list. | ||
| - | |||
| - | New settings override those read from the XROUTER.CFG file, | ||
| - | and remain in force until changed, or the system is restarted. | ||
| - | |||
| - | The minimum abbreviation of this command is MHF. | ||
| - | |||
| - | </ | ||
| - | The argument to MHF[lags] is the sum of the required options | ||
| - | from this list: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | 16 | ||
| - | |||
| - | The default is 255 (record everything). | ||
| - | |||
| - | </ | ||
| - | MHF 3 Enquire current MHFLAGS setting for port 3 | ||
| - | MHF 4 1 On port 4, show directly heard stations only | ||
| - | |||
| - | </ | ||
| - | MHCLEAR(1) | ||
| - | MHEARD(1) | ||
| - | MHSIZE(1) | ||
| - | MHEARD(7) | ||
| - | MHFLAGS(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | MHEARD(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MHSIZE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MHSIZE -- Adjust size of MHeard list. | ||
| - | |||
| - | </ | ||
| - | MHS[ize] < | ||
| - | |||
| - | </ | ||
| - | If MHEARD is enabled on the specified port, the MHSIZE | ||
| - | command allows the size of the table to be displayed or | ||
| - | changed. The command may be abbreviated to " | ||
| - | |||
| - | </ | ||
| - | When used without the [slots] argument, MHSIZE displays the | ||
| - | current size of the MHeard table for the specified < | ||
| - | |||
| - | If [slots] is supplied, the size of the MHeard table for the | ||
| - | specified < | ||
| - | |||
| - | </ | ||
| - | MHS 4 <-- show size of port 4's table | ||
| - | |||
| - | MHS 4 25 < | ||
| - | |||
| - | </ | ||
| - | If the table is made larger, existing entries are retained. | ||
| - | If it is made smaller, the oldest entries are discarded. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | MHEARD(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MINQUAL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MINQUAL -- Display / Set port minimum quality | ||
| - | |||
| - | </ | ||
| - | MIN[qual] < | ||
| - | |||
| - | </ | ||
| - | The MINQUAL command is used to display and set the Net/ | ||
| - | minqual (Minimum Quality) value for the specified port. | ||
| - | |||
| - | Within nodes broadcasts received on that port, any node | ||
| - | whose quality (after derating by port QUALITY) is less than | ||
| - | the minqual will not be accepted into the nodes table. | ||
| - | |||
| - | If the setting is changed, the new setting remains in force | ||
| - | until it is changed again, or until the router is restarted, | ||
| - | in which case it returns to the default value specified in | ||
| - | the port entry in the XROUTER.CFG file. | ||
| - | |||
| - | </ | ||
| - | If the second argument is omitted, the current value for | ||
| - | the specified port is displayed. | ||
| - | |||
| - | </ | ||
| - | MIN 2 - Display current setting for port 2 | ||
| - | MIN 2 30 - Set minqual for port 2 to 30. | ||
| - | |||
| - | </ | ||
| - | The MINQUAL value for a port is usually specified in the PORT | ||
| - | configuration block within XROUTER.CFG. If not specified, it | ||
| - | defaults to 10. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | QUALITY(1) | ||
| - | MINQUAL(7) | ||
| - | MINTXQUAL(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MINTXQUAL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MINTXQUAL -- Display / Set minimum quality to transmit | ||
| - | |||
| - | </ | ||
| - | MINT[xqual] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The MINTXQUAL command is used to display and set the minimum | ||
| - | Net/rom node quality to transmit on the specified port. | ||
| - | |||
| - | This would typically be used to limit the size of nodes | ||
| - | broadcasts on ports which are severely bandwidth limited, or | ||
| - | when the neighbour nodes have limited table capacity. | ||
| - | |||
| - | The neighbours could of course limit their table size using | ||
| - | their MINQUAL, but there is no point in transmitting | ||
| - | information which will be discarded. | ||
| - | |||
| - | If the setting is changed, the new setting remains in force | ||
| - | until it is changed again, or until the router is restarted, | ||
| - | in which case it returns to the default value specified in | ||
| - | the port entry in the CFG file. | ||
| - | |||
| - | </ | ||
| - | If the second argument is omitted, the current value is | ||
| - | displayed. | ||
| - | |||
| - | </ | ||
| - | MINT 2 - Display current setting for port 2 | ||
| - | MINT 2 30 - Include only the nodes with quality >= 30 | ||
| - | |||
| - | </ | ||
| - | The MINTXQUAL value for a port is usually specified in the | ||
| - | PORT configuration block within XROUTER.CFG. If not | ||
| - | specified, it defaults to 0, i.e. no minimum. | ||
| - | |||
| - | </ | ||
| - | MINQUAL(1) | ||
| - | MINTXQUAL(7) | ||
| - | QUALITY(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MMASK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MMASK -- Select which protocol(s) to monitor (trace) | ||
| - | |||
| - | </ | ||
| - | MM[ASK] [0 - FFFFh] | ||
| - | |||
| - | </ | ||
| - | The MMASK command is available only to console and remote | ||
| - | sysops. | ||
| - | |||
| - | </ | ||
| - | The MMASK command selects which protocol layers will be | ||
| - | monitored when traffic tracing is enabled on the current | ||
| - | console. | ||
| - | |||
| - | The optional argument is a HEX number between 0000h and FFFFh, | ||
| - | which is calculated by adding together the desired values from | ||
| - | this table: | ||
| - | |||
| - | 0001 - Incoming frames | ||
| - | 0002 - Outgoing frames | ||
| - | 0004 - Data payloads | ||
| - | 0008 - AX25 layer 2 0800 - SLIP/PPP | ||
| - | 0010 - Net/ | ||
| - | 0020 - ARP 2000 - PASSALL | ||
| - | 0040 - IP frames | ||
| - | 0080 - ICMP | ||
| - | |||
| - | If no argument is supplied, the current setting is reported. | ||
| - | |||
| - | The default setting for the first console is 03FF, which | ||
| - | displays all incoming and outgoing traffic from AX25 layer 2 | ||
| - | upwards. The settings for each console are independent. | ||
| - | |||
| - | This command duplicates the function of the <F4> key. | ||
| - | |||
| - | The console can override a remote sysop' | ||
| - | |||
| - | The PASSALL option enables frames which fail the validity | ||
| - | checks at one layer (e.g. KISS checksum) to be passed to the | ||
| - | next layer above for tracing. | ||
| - | |||
| - | </ | ||
| - | MMASK 0101 - display incoming TCP frames only, | ||
| - | MMASK 0142 - display outgoing TCP and IP frames. | ||
| - | |||
| - | </ | ||
| - | Remote sysops cannot trace activity on the port on which they | ||
| - | are uplinked | ||
| - | |||
| - | </ | ||
| - | Remote sysops must ensure that their link with the router is | ||
| - | capable of carrying the large volume of traffic resulting from | ||
| - | tracing. | ||
| - | on a slow link may result in poor performance. | ||
| - | warned! | ||
| - | |||
| - | </ | ||
| - | MONITOR(1) -- Enable / disable monitoring. | ||
| - | MPORT(1) | ||
| - | MTO(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MONITOR.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MONITOR -- Enable / disable traffic monitoring (tracing) | ||
| - | |||
| - | </ | ||
| - | MON[ITOR] [on | off] | ||
| - | MON[itor] IDS [on | off] | ||
| - | |||
| - | </ | ||
| - | Console and remote sysops only. | ||
| - | |||
| - | </ | ||
| - | The MONITOR command is primarily used to enable or disable | ||
| - | the display | ||
| - | |||
| - | The optional argument may be " | ||
| - | first enables the display, the second disables it, and the | ||
| - | third controls Intrusion Detection System monitoring. | ||
| - | argument is supplied, the current setting is reported. | ||
| - | |||
| - | If used at the console, this command enables and disables | ||
| - | tracing to the current console window, and works in | ||
| - | conjunction with the <F2> (monitor toggle) key. | ||
| - | |||
| - | If used by a remote sysop, there' | ||
| - | of monitored data could overload the link, so the MPORT | ||
| - | setting is cleared every time monitoring is enabled. The | ||
| - | sysop must then issue the MPORT command to select which | ||
| - | port(s) to monitor. | ||
| - | |||
| - | The MON IDS [on | off] sub-command controls IDS monitoring as | ||
| - | follows: | ||
| - | |||
| - | If MON is ON *and* MON IDS is ON, IDS warnings are echoed to | ||
| - | the console (or remote monitoring session if you are logged | ||
| - | on remotely). This allows you to keep an eye on the IDS while | ||
| - | doing other things. | ||
| - | |||
| - | This was mainly intended for use on remote monitorng | ||
| - | sessions, so the default for a *remote* monitor session is | ||
| - | ON. The default for consoles is OFF. | ||
| - | |||
| - | </ | ||
| - | MON ON - Enable tracing. | ||
| - | MON OFF - Disable tracing. | ||
| - | MON IDS - Show current state | ||
| - | MON IDS ON - Enable IDS warnings | ||
| - | |||
| - | </ | ||
| - | To prevent infinite recursion, remote sysops are prevented | ||
| - | from tracing activity on the port on which they are uplinked. | ||
| - | This is not entirely foolproof, especially where the egress | ||
| - | port may be uncertain (e.g a netrom or tunneled connection). | ||
| - | |||
| - | </ | ||
| - | Remote sysops must ensure that their link with XRouter is | ||
| - | capable of carrying the large volume of traffic resulting | ||
| - | from tracing. | ||
| - | detail on a slow link may result in poor performance. | ||
| - | |||
| - | </ | ||
| - | CAPTURE(1) -- Enable / disable tracing to disk file. | ||
| - | MPORT(1) | ||
| - | MMASK(1) | ||
| - | MTO(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MOTD.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MOTD -- Maintain " | ||
| - | |||
| - | </ | ||
| - | MOTD [< | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The MOTD command displays, sets or clears the " | ||
| - | Day", which is a single line of text sent only after L2 ctext. | ||
| - | If Ctext isn't sent, Motd isn't sent. | ||
| - | |||
| - | The < | ||
| - | stops being displayed when it reaches 0. It is meant for | ||
| - | displaying urgent notifications, | ||
| - | more permanent should go in CTEXT. | ||
| - | |||
| - | </ | ||
| - | If no arguments are supplied, the current MOTD (if any) is | ||
| - | displayed. | ||
| - | |||
| - | If the first argument is " | ||
| - | cleared. | ||
| - | |||
| - | If two arguments are supplied, the first one should be the | ||
| - | number of days to display the message, and the second should | ||
| - | be the message itself, which can be up to 80 characters and | ||
| - | may include spaces. | ||
| - | MOTD until midnight. | ||
| - | |||
| - | </ | ||
| - | MOTD 3 WyrePak Meeting Tues 21/8 8pm Sutton Arms | ||
| - | MOTD @ | ||
| - | |||
| - | </ | ||
| - | Message text may not exceed 80 characters, and | ||
| - | " | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MPORT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MPORT -- Select which port(s) to monitor (trace) | ||
| - | |||
| - | </ | ||
| - | MP[ORT] [0-FFFFFFFF | p+p+p | ALL | NONE] | ||
| - | |||
| - | </ | ||
| - | The MPORT command selects which port(s) will be monitored | ||
| - | when traffic tracing is enabled. | ||
| - | |||
| - | The optional argument is either a HEX number between 0 and | ||
| - | FFFFFFFF, a list of port numbers concatenated with " | ||
| - | the words ALL or NONE. | ||
| - | |||
| - | If no argument is supplied, the current setting is reported. | ||
| - | |||
| - | The hex form is preferable when monitoring is to be enabled | ||
| - | on many ports at once, but it only works up to port 31. | ||
| - | The hex value is calculated by adding together the desired | ||
| - | values from this table (see MORE INFO for details of hex | ||
| - | arithmetic): | ||
| - | |||
| - | Port HEX Port HEX Port HEX Port HEX | ||
| - | --------------------------------------------------- | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | The P+P+P form is preferable when selecting a small number | ||
| - | of ports to momitor, or when monitoring ports above 31. | ||
| - | |||
| - | This command duplicates the function of the <F3> key. | ||
| - | |||
| - | When a remote sysop enables tracing, the MPORT setting is | ||
| - | cleared to NONE, to avoid overloading the link with traffic | ||
| - | which might otherwise prevent him from issuing further | ||
| - | commands. The remote sysop must therefore always issue the | ||
| - | MON ON command first, followed by the MPORT command to select | ||
| - | which port(s) to monitor. | ||
| - | |||
| - | The console can override a remote sysop' | ||
| - | |||
| - | </ | ||
| - | MPORT 800 - Trace port 11. | ||
| - | MPORT 1803 - Trace ports 12, 11, 2 and 1. | ||
| - | MPORT 1+5+39 - Trace ports 1, 5 and 39 | ||
| - | |||
| - | </ | ||
| - | Port zero is a " | ||
| - | and going via the operating system' | ||
| - | "MPORT 0" traces port 0, instead of disabling tracing. You | ||
| - | must use "MPORT NONE" to disable tracing - or just use | ||
| - | MON OFF. | ||
| - | |||
| - | </ | ||
| - | Remote sysops are prevented from tracing activity on the | ||
| - | port on which they are uplinked, because this would cause | ||
| - | an endless loop. | ||
| - | |||
| - | Ports > 31 can only be traced using the P+P+P argument form. | ||
| - | |||
| - | </ | ||
| - | Remote sysops must ensure that their link with XRouter is | ||
| - | capable of carrying the large volume of traffic resulting | ||
| - | from tracing. | ||
| - | much detail on a slow link may result in poor performance. | ||
| - | |||
| - | </ | ||
| - | The MPORT command is available only to console and remote | ||
| - | sysops. It may be used in BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | Hexadecimal arithmetic is based on powers of 16, and uses | ||
| - | numbers 0-9 and letters A-F to represent numbers up to 15 | ||
| - | as follows: | ||
| - | |||
| - | Hex: 0 1 2 3 4 5 6 7 8 9 A B C D E F | ||
| - | Dec: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | ||
| - | |||
| - | Single " | ||
| - | except for the fact that letters represent 10-15, therefore: | ||
| - | |||
| - | The result of adding 1 and 4 is (unsurprisingly) 5 | ||
| - | The result of adding 4 and 8 is C (decimal 12) | ||
| - | The result of subtracting 8 from F (decimal 15) is 7 | ||
| - | |||
| - | Things get more complicated when the result of a calculation | ||
| - | is greater than 15, but fortunately that never happens when | ||
| - | adding MPORT values. | ||
| - | |||
| - | To create a composite MPORT value, simply add the desired | ||
| - | values from each column. For example, to monitor ports 1,2,3 | ||
| - | 6 and 7, the hex values 02, 04, 08, 40, and 80 must be added. | ||
| - | |||
| - | 02 | ||
| - | + 04 | ||
| - | + 08 | ||
| - | + 40 (note this is "Four zero", not " | ||
| - | + 80 (eight zero means "8 times 16 plus zero") | ||
| - | ------ | ||
| - | = CE (the decimal equivalent is (12*16)+14 = 206) | ||
| - | ------ | ||
| - | |||
| - | </ | ||
| - | MONITOR(1) | ||
| - | MMASK(1) | ||
| - | MTO(1) | ||
| - | BOOTCMDS.SYS(8) -- Commands to Execute at Bootup. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MQTT.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | MQTT -- MQTT Test Client / Commands. | ||
| - | |||
| - | </ | ||
| - | MQTT < | ||
| - | MQTT < | ||
| - | |||
| - | </ | ||
| - | The MQTT command is used either to initiate a client session | ||
| - | with an external MQTT " | ||
| - | to XRouter' | ||
| - | |||
| - | After successful connection to a server, the client accepts | ||
| - | the following commands: | ||
| - | |||
| - | BYE | ||
| - | DISC[onnect] | ||
| - | GET < | ||
| - | H[elp] | ||
| - | PUB[lish] [-options] < | ||
| - | PUT < | ||
| - | SUB[scribe] < | ||
| - | UNSUB[sribe] < | ||
| - | |||
| - | </ | ||
| - | If the argument is an ip address or host name, the optional | ||
| - | second argument can be used to specify a TCP port number. If | ||
| - | a port number is not supplied, the default is 1883. | ||
| - | |||
| - | If the argument is the callsign or alias of a known XRouter, | ||
| - | i.e. one that is currently in the netrom nodes table, the | ||
| - | connection is made to NetRomX service 1883. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | MQTT-CLI(9) | ||
| - | MQTT-SRV(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====MTO.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | MTO -- Monitor frames to/from specified destination. | ||
| - | |||
| - | </ | ||
| - | MT[o] [< | ||
| - | |||
| - | </ | ||
| - | Sysops-only. | ||
| - | |||
| - | </ | ||
| - | The MTO command allows you to selectively monitor (trace) | ||
| - | frames to/from a specified callsign or IP address. | ||
| - | |||
| - | This filter is additional to any filtering provided by MPORT | ||
| - | and MMASK, i.e. only frames on the specified MPORT(s), which | ||
| - | match the protocol specified by MMASK, and the address | ||
| - | specified by MTO will be displayed. | ||
| - | |||
| - | </ | ||
| - | "MTO < | ||
| - | and from AX25 < | ||
| - | |||
| - | "MTO < | ||
| - | to and from an IP address. | ||
| - | traffic to/from that IP address is monitored. | ||
| - | specified, only TCP and UDP frames to and from the specified | ||
| - | IP address are monitored, and only if the source or dest port | ||
| - | match the specified one. | ||
| - | |||
| - | "MTO ALL" disables selective tracing, allowing all packets | ||
| - | on the selected port, which match the MMASK to be displayed. | ||
| - | |||
| - | "MTO NONE" provides a quick means to cancel the existing MTO, | ||
| - | and results in no packets being displayed. | ||
| - | |||
| - | </ | ||
| - | MTO g8pzt | ||
| - | MTO 44.131.91.2: | ||
| - | |||
| - | </ | ||
| - | Only one MTO filter can be in operation on each console and | ||
| - | remote sysop session at any time. Setting a new MTO cancels | ||
| - | the previous one on that console or session. | ||
| - | |||
| - | </ | ||
| - | MMASK(1) | ||
| - | MONITOR(1) -- Enable / disable monitoring | ||
| - | MPORT(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NAT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NAT -- Network Address Translation commands. | ||
| - | |||
| - | </ | ||
| - | NA[t] A[dd] STATIC < | ||
| - | NA[t] A[dd] OVERLOAD < | ||
| - | NA[t] D[rop] < | ||
| - | NA[t] L[ist] | ||
| - | |||
| - | </ | ||
| - | The NAT commands controls Network Address Translation, | ||
| - | the process whereby the IP addresses contained in datagrams | ||
| - | are manipulated to allow hosts on one network to communicate | ||
| - | with hosts on a different network. | ||
| - | |||
| - | For example, hosts on a private intranet using unregistered | ||
| - | 192.168.0.x addresses cannot communicate with hosts on the | ||
| - | wider Internet because no-one would know where to route the | ||
| - | return datagrams. | ||
| - | addresses into registered ones and vice versa. | ||
| - | |||
| - | PAT (Port Address Translation) manipulates TCP and UDP service | ||
| - | port numbers, for example to allow several hosts to share one | ||
| - | IP address. | ||
| - | |||
| - | </ | ||
| - | The arguments for NAT commands are as follows: | ||
| - | |||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | < | ||
| - | e.g. 255.255.255.0 | ||
| - | |||
| - | NAT ADD adds an entry to the NAT table. | ||
| - | STATIC and OVERLOAD. | ||
| - | entries, i.e. those where there is a one-to-one mapping | ||
| - | between private and public IP addresses. | ||
| - | only for dynamic PAT, where several hosts share one public IP | ||
| - | address. | ||
| - | |||
| - | NAT DROP removes an entry from the NAT table. | ||
| - | |||
| - | NAT LIST lists the NAT table entries. | ||
| - | |||
| - | </ | ||
| - | NAT ADD STATIC 192.168.0.2: | ||
| - | NAT ADD OVERLOAD 192.168.0.0 44.131.91.3 255.255.255.240 | ||
| - | NAT DROP 192.168.0.5: | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The NAT ADD commands are usually used in IPROUTE.SYS, | ||
| - | may also be used in BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | NAT(9) -- Network Address Translation | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NETMASK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NETMASK -- Display / Set Port NETMASK. | ||
| - | |||
| - | </ | ||
| - | NE[tmask] < | ||
| - | |||
| - | </ | ||
| - | This command is sysop-only. | ||
| - | |||
| - | </ | ||
| - | This command allows the NETMASK for the specified port to be | ||
| - | displayed or changed. | ||
| - | |||
| - | The NETMASK is used together with the port IPADDRESS to | ||
| - | specify the range of IP addresses that are on the same | ||
| - | physical network segment as XRouter. If XRouter sees any | ||
| - | datagrams with a destination address within that range, and | ||
| - | not addressed to itself, it will not attempt to route them. | ||
| - | |||
| - | For example, if the NDISXPKT driver is being used, XRouter | ||
| - | and Windows will have different IP addresses, but will share | ||
| - | the same Ethernet address. Thus both XRouter and Window " | ||
| - | the same datagrams. Without a suitable NETMASK value, XRouter | ||
| - | would attempt to route any datagram not addressed to itself, | ||
| - | which means it would attempt to route any datagrams that are | ||
| - | addressed to the Windows IP address. | ||
| - | |||
| - | The netmask is specified in dotted-quad form, for example | ||
| - | " | ||
| - | specifies that the corresponding bit in the IP address should | ||
| - | be non-zero. Any zero bit specifies that the corresponding | ||
| - | bit in the IP address may be zero or one. e.g. if the port IP | ||
| - | address is " | ||
| - | XRouter will process datagrams addressed to " | ||
| - | will ignore datagrams addressed to any other 192.168.0.x | ||
| - | destination (where x represents a number between 0 and 255). | ||
| - | |||
| - | The default value for NETMASK is " | ||
| - | function. | ||
| - | |||
| - | The minimum abbreviation for this command is " | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, and it is a valid | ||
| - | port number, the current NETMASK for that port number is | ||
| - | displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies a | ||
| - | port number and the second specifies a new NETMASK for that | ||
| - | port. | ||
| - | |||
| - | </ | ||
| - | NET 1 - Display current NETMASK for port 1. | ||
| - | NET 2 255.255.255.0 | ||
| - | |||
| - | </ | ||
| - | IPADDRESS(1) -- Display / Set Port IP Address. | ||
| - | NETMASK(7) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NFTP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NFTP -- Netrom File Transfer Server / Client. | ||
| - | |||
| - | </ | ||
| - | NF[tp] < | ||
| - | |||
| - | </ | ||
| - | Client is sysop-only. Server is open to all. | ||
| - | |||
| - | </ | ||
| - | The NFTP command invokes either the NFTP client or the NFTP | ||
| - | server, depending on < | ||
| - | |||
| - | NFTP is used to exchange files with other sysops, over the | ||
| - | Netrom network. | ||
| - | |||
| - | </ | ||
| - | 1) If < | ||
| - | user is logged on, it invokes the local NFTP server at that | ||
| - | node. This mode is available to non-sysops, and uses fairly | ||
| - | standard FTP server commands, such as LIST, STOR, RETR etc. | ||
| - | |||
| - | 2) If < | ||
| - | any other node, and the user is a verified sysop, it invokes a | ||
| - | client which connects to the target server. | ||
| - | |||
| - | The client uses standard FTP client commands such as DIR, GET, | ||
| - | PUT etc. Most commands may be abbreviated. The full command | ||
| - | list is shown below: | ||
| - | |||
| - | ? | ||
| - | cd cdup close | ||
| - | get | ||
| - | ldir ls list lmkdir | ||
| - | lrmdir | ||
| - | nlist | ||
| - | restart | ||
| - | status | ||
| - | |||
| - | Most of these commands should be familiar to FTP users. | ||
| - | |||
| - | Typing "HELP < | ||
| - | NFTP> | ||
| - | |||
| - | </ | ||
| - | The NFTP client has full access to the local system, so is | ||
| - | available only to verified sysops. A sysop connection via | ||
| - | 44-net is not considered secure enough to use the client. | ||
| - | |||
| - | The client uses a " | ||
| - | rather than an " | ||
| - | rather clumsy connection sequence, but allows other software | ||
| - | authors to incorporate NFTP, if they so desire, without | ||
| - | needing to implement L4X. The next version of XRLin/XRPi will | ||
| - | use L4X if the target node supports it, otherwise it will use | ||
| - | normal L4. | ||
| - | |||
| - | A typical usage scenario would be like this: | ||
| - | |||
| - | Sysop ALICE is chatting with sysop BOB on XR sysop chat. | ||
| - | She wants his help, because her TUN interface doesn' | ||
| - | |||
| - | Bob says "send me your XROUTER.CFG and I'll have a look". | ||
| - | |||
| - | Alice types "NFTP BOB", then "PUT XROUTER.CFG" | ||
| - | informing BOB via the chatserver. | ||
| - | |||
| - | BOB studies Alice' | ||
| - | |||
| - | Meanwhile sysop CHARLES has downloaded the file from BOB, | ||
| - | and spots the error. He corrects it and uses "NFTP ALICE", | ||
| - | then "PUT XRNEW.CFG" | ||
| - | |||
| - | BOB downloads the new file and is enlightened. ALICE copies it | ||
| - | from FTP/public to her XRPI working directory and reboots. The | ||
| - | TUN interface now works. CHARLES is a genius! | ||
| - | |||
| - | CHARLES writes a useful HOWTO about the TUN interface, and | ||
| - | uploads it to ALICE' | ||
| - | FRANK etc can download it. | ||
| - | |||
| - | No-one needed to know anyone else's email address. No-one | ||
| - | needed to copy files from their node machine to an email | ||
| - | machine and back. There was no need to set up accounts and | ||
| - | passwords. No-one had privileged access to anyone elses | ||
| - | machine. It could all be done from XRouter' | ||
| - | |||
| - | </ | ||
| - | FTP(1) | ||
| - | NFTP-SRV(9) -- Netrom File Transfer Protocol Server | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NODESINT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NODESINT -- Display / Set global or port NODESINTERVAL. | ||
| - | |||
| - | </ | ||
| - | NODESI[nt] <port | 0> [value] | ||
| - | |||
| - | </ | ||
| - | This command is sysop-only. | ||
| - | |||
| - | </ | ||
| - | The NODESINT command allows the global and port-specific | ||
| - | NODESINTERVAL settings to be displayed or changed. | ||
| - | |||
| - | The NODESINTERVAL is the number of minutes between NetRom | ||
| - | nodes broadcasts, as specified in XROUTER.CFG. The default | ||
| - | is 60 minutes. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, and it is a valid | ||
| - | port number, the current NODESINTERVAL for that port number | ||
| - | is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies a | ||
| - | port number and the second specifies a new NODESINTERVAL for | ||
| - | that port only. | ||
| - | |||
| - | If the first argument is zero, the command displays and sets | ||
| - | the global NODESINTERVAL. This value is inherited by all | ||
| - | ports, except those with a port-specific value. | ||
| - | |||
| - | </ | ||
| - | NODESINT 0 - Display global NODESINTERVAL | ||
| - | NODESINT 0 30 - Set global NODESINTERVAL to 30 minutes | ||
| - | NODESINT 10 60 - Set port 10 NODESINTERVAL to 60 minutes | ||
| - | |||
| - | </ | ||
| - | NODESINT(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NODES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NODES -- Display / Modify the Nodes table. | ||
| - | |||
| - | </ | ||
| - | N[odes] [nodecall] | ||
| - | N[odes] + | ||
| - | N[odes] * | ||
| - | N[odes] > < | ||
| - | N[odes] < < | ||
| - | N[odes] A[dd] < | ||
| - | N[odes] B (y) < | ||
| - | N[odes] C (allsign) | ||
| - | N[odes] D[rop] < | ||
| - | N[odes] F (rames) | ||
| - | N[odes] H (ops) | ||
| - | N[odes] HE[lp] | ||
| - | N[odes] I (paddr | ||
| - | N[odes] J (BPQ) | ||
| - | N[odes] N (etrom) | ||
| - | N[odes] O (bsolete) | ||
| - | N[odes] P (osition) | ||
| - | N[odes] Q (ueue) | ||
| - | N[odes] R (tt) | ||
| - | N[odes] S (tats) | ||
| - | N[odes] T (imes) | ||
| - | N[odes] V (ia) < | ||
| - | N[odes] X (router) | ||
| - | |||
| - | </ | ||
| - | The NODES command is used to list the contents of the Netrom | ||
| - | nodes table in a variety of diferent ways, according to the | ||
| - | format of the command. | ||
| - | |||
| - | Sysops may also use the command to add and delete nodes. | ||
| - | |||
| - | Nodes may be listed in callsign or alias order, and wildcard | ||
| - | searches may be performed on either field. | ||
| - | |||
| - | The display may be restricted to those nodes whose NetRom | ||
| - | quality is greater or lesser than a specified figure, or to | ||
| - | those who are netrom-only, | ||
| - | |||
| - | Or the sysop may choose to display only those nodes for whom | ||
| - | an IP address or round trip time is known, or those who have | ||
| - | frames waiting, or those who have non-zero counters. | ||
| - | |||
| - | The command may also be used to find which nodes are routed | ||
| - | via which neighbour node. | ||
| - | |||
| - | </ | ||
| - | N List all nodes, excluding " | ||
| - | N * List all nodes, including hidden ones | ||
| - | N + List nodes with both time and qual metrics valid | ||
| - | N > < | ||
| - | N < < | ||
| - | N < | ||
| - | N A[dd] Add a node to the table (sysop only) | ||
| - | N B < | ||
| - | N C List nodes by callsign instead of in alias order | ||
| - | N D[rop] | ||
| - | N F List nodes with a non-zero " | ||
| - | N H List nodes with a non-zero Hop count | ||
| - | N HE[lp] | ||
| - | N I List nodes which have an IP address | ||
| - | N J List nodes which might be BPQ | ||
| - | N N List nodes whose only usable metric is Netrom | ||
| - | N O List only Obsolete nodes | ||
| - | N P List nodes whose position is known | ||
| - | N Q List nodes which currently have frames queued | ||
| - | N R List nodes for whom a RTT count is known | ||
| - | N S List nodes with a position, RTT or frame count | ||
| - | N T List nodes whose only usable metric is Trip Time | ||
| - | N V < | ||
| - | N X List confirmed XRouter nodes | ||
| - | |||
| - | </ | ||
| - | When used without arguments, this command lists all the NetRom | ||
| - | nodes (but not KA nodes) known to XRouter, except those | ||
| - | " | ||
| - | |||
| - | If the argument is an asterisk (*), all nodes, including | ||
| - | " | ||
| - | |||
| - | If the argument is a known node call or alias (e.g. N MLVN), | ||
| - | the preferred route to the specified node, and up to two | ||
| - | alternative routes will be displayed. Other information, | ||
| - | as the position (in APRS format) and IP address will be | ||
| - | displayed if known. The response looks like this: | ||
| - | |||
| - | G8PZT: | ||
| - | Info for: MLVN: | ||
| - | Pos=52.2321N 2.0213W Loc=IO82QJ Qth=Malvern | ||
| - | IP=44.131.92.50/ | ||
| - | Supports: INP3 L3ROUT NRR NCMP L4X NDP PMS XRCHAT RTCHAT | ||
| - | Updated: 18/10 14:43 Confirmed: 16/10 13:23 | ||
| - | |||
| - | Routes to: MLVN:G4FPV | ||
| - | Qty Obs Pt Via Stt Hop Obs2 | ||
| - | > 150 5 5 G4FPV | ||
| - | 110 5 9 GB7GH | ||
| - | 0 4 2 G1DKI-7 | ||
| - | |||
| - | Not all the above fields may be present, and additional | ||
| - | fields may be displayed if available. The following | ||
| - | information may be displayed after the callsign: | ||
| - | |||
| - | " | ||
| - | node. | ||
| - | |||
| - | " | ||
| - | (in seconds) taken to get a response from the node. | ||
| - | |||
| - | " | ||
| - | for that destination. | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | via the route. | ||
| - | |||
| - | " | ||
| - | host additional services, such as BBS, PMS, CHAT | ||
| - | etc. | ||
| - | |||
| - | " | ||
| - | System. | ||
| - | |||
| - | " | ||
| - | | ||
| - | |||
| - | Subsequent lines may display the following: | ||
| - | |||
| - | Pos= | ||
| - | Loc= | ||
| - | Qth= | ||
| - | IP= Amprnet IP address (if enabled) | ||
| - | TCP= TCP port for access via amprnet | ||
| - | v502y Software version | ||
| - | Updated: | ||
| - | Confirmed: Date and time confirmed by probe response | ||
| - | Supports: | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | In the " | ||
| - | |||
| - | ">" | ||
| - | active route. | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | how recently the route was heard about or used. It | ||
| - | is usually reset to OBSINIT (usually 5) upon being | ||
| - | seen in a nodes broadcast from the neighbour node, | ||
| - | and decrements by one every time XRouter makes a | ||
| - | node broadcast (typically once per hour). If it | ||
| - | drops below OBSMIN (usually 3) the route is | ||
| - | considered to be obsolete. | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | reached. | ||
| - | |||
| - | " | ||
| - | one-way transit time to the neighbour in seconds. | ||
| - | This field may not be present in all cases. | ||
| - | |||
| - | " | ||
| - | neighbour. It is one more than the number of | ||
| - | intermediate nodes. This field may not always be | ||
| - | available. | ||
| - | |||
| - | " | ||
| - | | ||
| - | INP3. This info is maintained independently of | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | "<" | ||
| - | from the route actually used at that instant. | ||
| - | |||
| - | If the requested nodecall or alias is not in the table, an | ||
| - | error message results. | ||
| - | |||
| - | If the specified callsign or alias contains wildcards, a list | ||
| - | of matching nodes will be displayed. | ||
| - | |||
| - | "N A[add]" | ||
| - | are < | ||
| - | are [alias] and lock flag [!]. | ||
| - | |||
| - | "N B < | ||
| - | < | ||
| - | reach. This is not necessarily the same as the nodes *routed* | ||
| - | via that neighbour, because some of the nodes may be | ||
| - | advertised with better metrics by other neighbours. | ||
| - | |||
| - | "N C" displays nodes in callsign order instead of the standard | ||
| - | alias order. If you wish the nodes to be displayed in callsign | ||
| - | order by default, use SORTBYCALL=1 in XROUTER.CFG. | ||
| - | |||
| - | "N D < | ||
| - | |||
| - | "N F" displays nodes with a non-zero " | ||
| - | count is only available for nodes with to whom XRouter has | ||
| - | routed some traffic. | ||
| - | |||
| - | "N H" lists the nodes which have a non-zero " | ||
| - | hop count is derived from actual measurements, | ||
| - | " | ||
| - | only a few nodes at most. | ||
| - | |||
| - | "N I" displays the nodes which have an amprnet IP address. | ||
| - | In practice this list is likely to contain only XRouter and | ||
| - | X(Net) nodes. | ||
| - | |||
| - | "N J" displays the nodes which MIGHT be BPQ. This information | ||
| - | is currently only available for nodes which have routed some | ||
| - | | ||
| - | |||
| - | "N N" displays the nodes whose only usable metric is NetRom | ||
| - | quality, i.e. those for whom a trip time is unknown or has | ||
| - | gone obsolete. | ||
| - | |||
| - | "N O" lists the " | ||
| - | metrics are too " | ||
| - | off-line or otherwise unreachable. | ||
| - | |||
| - | "N P" lists the nodes whose position is known. In practice, | ||
| - | the only nodes which curently show in this list will be | ||
| - | XRouters. | ||
| - | |||
| - | "N Q" displays the nodes which currently have frames waiting | ||
| - | to be delivered to them. The queues may be the result of | ||
| - | link bottlenecks, | ||
| - | |||
| - | "N R" displays the nodes for whom a Round Trip Time is known. | ||
| - | This is an averaged value for all connections between XRouter | ||
| - | and the target node, and may differ from the current | ||
| - | " | ||
| - | RTT is only available for nodes which XRouter has connected | ||
| - | to. | ||
| - | |||
| - | "N S" displays the nodes for whom some " | ||
| - | position, Round Trip Time or frame count. | ||
| - | |||
| - | "N T" lists the nodes whose only usable metric is Time, i.e. | ||
| - | those which have a valid trip time, but for whom the NetRom | ||
| - | quality is unknown or is considered obsolete. | ||
| - | |||
| - | "N V < | ||
| - | neighbour < | ||
| - | change with time, as the metrics fluctuate. | ||
| - | |||
| - | "N X" lists the nodes known to be XRouter. This may not show | ||
| - | | ||
| - | |||
| - | </ | ||
| - | N - List nodes except those beginning with # | ||
| - | N * - List nodes including those beginning with # | ||
| - | N MLVN - Display routes to MLVN node | ||
| - | N V VK2DOT | ||
| - | N > 100 - Display nodes with qualities greater than 100 | ||
| - | |||
| - | </ | ||
| - | The NODES command is available to all users, but the ADD and | ||
| - | DROP sub-command are sysop-only. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NPING.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NPING -- Send a Netrom echo request | ||
| - | |||
| - | </ | ||
| - | NP[ing] < | ||
| - | |||
| - | </ | ||
| - | The NPING command sends an NCMP (Network Control Message | ||
| - | Protocol) echo request to the specified target system. | ||
| - | |||
| - | If the target understands NCMP, a reply is returned, | ||
| - | allowing the round-trip-time and number of hops to be | ||
| - | determined. | ||
| - | |||
| - | </ | ||
| - | The command allows the user to specify an additional data | ||
| - | payload, and an interval between pings. | ||
| - | assess the consistency of link performance. | ||
| - | |||
| - | </ | ||
| - | nping gb7gc | ||
| - | G8PZT: | ||
| - | |||
| - | Pinging gb7gc with 0 bytes of data: | ||
| - | |||
| - | GB7GC: echo reply - rtt 17985 msec, 3 hop(s) | ||
| - | |||
| - | |||
| - | nping gb7gc 10 20 | ||
| - | G8PZT: | ||
| - | |||
| - | Pinging gb7gc with 10 bytes of data: | ||
| - | |||
| - | Target | ||
| - | GB7GC | ||
| - | GB7GC | ||
| - | GB7GC | ||
| - | |||
| - | </ | ||
| - | NCMP is under development and is currently implemented only | ||
| - | in XRouter, so you can only NPING another Xrouter at present. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | NRR(1) | ||
| - | NTRACERT(1) -- NetRom TraceRoute. | ||
| - | NCMP(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NRR.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | NRR -- Netrom Record Route | ||
| - | |||
| - | </ | ||
| - | NRR < | ||
| - | |||
| - | </ | ||
| - | This command sends a " | ||
| - | netrom target system. | ||
| - | Xrouter, Xnet, Flexnet?), the packet is returned otherwise | ||
| - | the packet is ignored by the target. | ||
| - | |||
| - | Each NRR-capable router along the path inserts its own | ||
| - | callsign into the packet, and these are displayed when the | ||
| - | reply is received. | ||
| - | question mark "?" | ||
| - | the outgoing and return routes are displayed because they may | ||
| - | differ. | ||
| - | |||
| - | </ | ||
| - | nrr gb7gc | ||
| - | |||
| - | G8PZT: | ||
| - | Route reply: | ||
| - | |||
| - | </ | ||
| - | Targets which are not NRR-capable (e.g. BPQ, TheNet, FPAC, | ||
| - | LinuxNode, JNOS, TNOS) will not respond to probes. | ||
| - | |||
| - | As of 2013, BPQ32 systems do NOT respond to NRR requests, | ||
| - | although they do correctly handle in-transit NRR traffic. | ||
| - | |||
| - | </ | ||
| - | NPING(1) | ||
| - | NTRACERT(1) -- NetRom TraceRoute. | ||
| - | NCMP(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NTRACERT.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | NTRACERT -- NetRom TraceRoute. | ||
| - | |||
| - | </ | ||
| - | NT[racert] < | ||
| - | |||
| - | </ | ||
| - | The NTRACERT commmand traces the route to a NetRom node. | ||
| - | |||
| - | It is a diagnostic tool for displaying the route to a NetRom | ||
| - | target, and measuring the transit delays of packets at each | ||
| - | step along the route. | ||
| - | |||
| - | It uses the replies from a series of NCMP (Netrom Control | ||
| - | Message Protocol) echo requests to produce a list of the | ||
| - | nodes that the packets have passed through. | ||
| - | |||
| - | NCMP is only understood by XRouters at present. Therefore | ||
| - | only XRouter nodes show in the trace. | ||
| - | |||
| - | 3 attempts are made at each hop, thus for each hop, 3 round | ||
| - | trip times are displayed, along with the nodecall at that | ||
| - | hop. | ||
| - | |||
| - | The 3 times indicate the consistency of the route. If no | ||
| - | response is received from a node within the timeout | ||
| - | period, a " | ||
| - | |||
| - | The operation can be aborted by sending a blank line. | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | |||
| - | [maxhops] | ||
| - | |||
| - | [maxwait] | ||
| - | | ||
| - | |||
| - | The only mandatory parameter is < | ||
| - | specify [maxwait], [maxhops] must also be specified. | ||
| - | |||
| - | </ | ||
| - | NT VA2OM - Trace to VA2OM with default parameters. | ||
| - | NT G7VJA-5 10 - Trace to G7VJA-5 to a max of 10 hops. | ||
| - | NT XBAL 5 20000 - Trace to XBAL, 5 hops, maxwait 20secs | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | NCMP(9) | ||
| - | NPING(1) -- Send NetRom Echo Request(s). | ||
| - | NRR(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====NTTY.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | NTTY -- Talk to a user or another sysop. | ||
| - | |||
| - | </ | ||
| - | NTT[y] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The NTTY command allows a sysop to have a one-to-one private | ||
| - | keyboard chat with the sysop of another XRouter. | ||
| - | |||
| - | This is not related to the "sysop chat" channel on the chat | ||
| - | server. It is the NetRom equivalent of the TTYLINK command, | ||
| - | and is very similar to the TALK command. It uses NetRomX | ||
| - | service 87. | ||
| - | |||
| - | The sysop of the target node has 90 seconds to respond. At | ||
| - | any point during or after the 90 seconds, the caller has the | ||
| - | option to leave a short one-line message (160 chars max) or | ||
| - | to abort the call. Messages are saved into the sysop' | ||
| - | |||
| - | If the target sysop takes more than 90 seconds to respond, | ||
| - | and the caller has not disconnected, | ||
| - | use the TALK command to initiate a chat with the caller. | ||
| - | |||
| - | </ | ||
| - | NTTY G8PZT-3 - Initiate chat with sysop of G8PZT-3 node | ||
| - | NTTY KIDDER | ||
| - | |||
| - | </ | ||
| - | This currently only works if the target node is running | ||
| - | a recent version of XRouter. Other types of node will not | ||
| - | respond to the request. | ||
| - | |||
| - | </ | ||
| - | NTTY-SVC(9) -- NetRomX TTYlink Service | ||
| - | TALK(1) | ||
| - | TTYLINK(1) | ||
| - | TTYLINK(9) | ||
| - | SERVICES(9) -- NetRomX Standard Services. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PACLEN.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PACLEN -- Display / Set global or port paclen values. | ||
| - | |||
| - | </ | ||
| - | PA[clen] <port | 0> [value] | ||
| - | |||
| - | </ | ||
| - | This command is sysop-only. | ||
| - | |||
| - | </ | ||
| - | The PACLEN command allows the global and port-specific PACLEN | ||
| - | settings to be displayed and changed. | ||
| - | data field length within an AX25 or Netrom packet. | ||
| - | |||
| - | The global PACLEN is specified (using PACLEN=n) in the L2 | ||
| - | global parameters section of the XROUTER.CFG file, and is | ||
| - | the default value, used where not overriden by a port-specific | ||
| - | paclen. | ||
| - | |||
| - | All frames originating at the router use the global or port | ||
| - | paclens specified, but Netrom frames originating at other | ||
| - | systems can not be fragmented, so we have no control over | ||
| - | them, and they may be larger than our paclen. | ||
| - | |||
| - | If the port PACLEN is set to 0, XRouter dynamicallys adapts | ||
| - | PACLEN (and MAXFRAME) to the link conditions, to maximise | ||
| - | throughput. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, and it is a valid | ||
| - | port number, the current paclen for that port number is | ||
| - | displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies a | ||
| - | port number and the second specifies a new paclen value for | ||
| - | that port. | ||
| - | |||
| - | If the first argument is zero, the PACLEN command displays | ||
| - | and sets the global paclen. | ||
| - | |||
| - | </ | ||
| - | PACLEN 0 - Display global default paclen | ||
| - | PACLEN 0 120 - Set default paclen to 120 | ||
| - | PACLEN 10 - Display current paclen for port 10 | ||
| - | PACLEN 10 160 - Set port 10 paclen to 160 | ||
| - | |||
| - | </ | ||
| - | MAXFRAME(1) | ||
| - | PACLEN(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PCAP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PCAP -- IP Packet Capture. | ||
| - | |||
| - | </ | ||
| - | PC[ap] [on | off] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The PCAP command controls IP packet capture. | ||
| - | |||
| - | If enabled, every IP datagram entering or leaving XRouter' | ||
| - | IP stack is recorded to a " | ||
| - | that can be examined with Wireshark. | ||
| - | |||
| - | This can be useful when chasing obscure crashes or doing a | ||
| - | security audit. Other node authors will no doubt use it to | ||
| - | reverse-engineer XRouter' | ||
| - | not secret, just as-yet undocumented! | ||
| - | |||
| - | The default packet capture state is controlled by LOG_PCAP | ||
| - | (bit 9, value 512) in the argument to the " | ||
| - | in the " | ||
| - | the LOG= directive, packet capture is on by default, | ||
| - | otherwise it is off. | ||
| - | |||
| - | Packet capture can generate huge files, especially if you are | ||
| - | using FTP to transfer large amounts of data, so it is not | ||
| - | recommended for long-term use. | ||
| - | |||
| - | </ | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PEERS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PEERS -- Show the nearest NCMP-capable nodes. | ||
| - | |||
| - | </ | ||
| - | PEE[rs] | ||
| - | |||
| - | </ | ||
| - | The PEERS command displays the closest NCMP (Netrom Control | ||
| - | Message Protocol)-capable neighbours, for example: | ||
| - | |||
| - | Nodecall | ||
| - | G8PZT 0 1 26/05 04:18 26/05 04:18 | ||
| - | ZL2BAU-3 | ||
| - | VK2DOT-1 | ||
| - | G8PZT-1 | ||
| - | VE2PKT-4 | ||
| - | VE3UIM-7 | ||
| - | |||
| - | (For reasons of clarity, the additional fields " | ||
| - | " | ||
| - | |||
| - | " | ||
| - | second, e.g " | ||
| - | show longer round trip times if traffic is heavy. | ||
| - | |||
| - | " | ||
| - | direct (netrom neighbour) link. | ||
| - | |||
| - | " | ||
| - | NCMP-capable, | ||
| - | from it. Over time, sysops may change from one brand of | ||
| - | software to another, retaining the same callsign and alias. | ||
| - | So it can't be assumed that a PEERS entry is valid unless | ||
| - | the last-comfirmed date/time is relatively up to date. | ||
| - | |||
| - | " | ||
| - | responded to a neighbour discovery request. | ||
| - | |||
| - | " | ||
| - | |||
| - | </ | ||
| - | At the moment, only XRouters (XR16 / XR32 / XRLin / XRPi) | ||
| - | are NCMP-capable. | ||
| - | |||
| - | The old DOS and Windows versions of XRouter are NCMP-capable, | ||
| - | so they will show up in the peers list. But they use an | ||
| - | earlier version of the protocol which doesn' | ||
| - | " | ||
| - | |||
| - | </ | ||
| - | XRouter uses NCMP peers as " | ||
| - | vanilla NetRom network, so that it can exchange all sorts of | ||
| - | informaton that makes packet more modern, interesting and | ||
| - | useful. | ||
| - | |||
| - | If all nodes were NCMP-capable, | ||
| - | seamlessly from neighbour to neighbour. Then there would be | ||
| - | no more need for neighbour discovery and the PEERS command, | ||
| - | as all nodes would be peers. Like that's ever going to | ||
| - | happen! | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | NPING(1) | ||
| - | NTRACERT(1) -- Trace route to a netrom node. | ||
| - | NCMP(9) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PERSIST.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PERSIST -- Display / Set the persist value for a port. | ||
| - | |||
| - | </ | ||
| - | PER[SIST] < | ||
| - | |||
| - | </ | ||
| - | The PERSIST command is available only to sysops. | ||
| - | |||
| - | </ | ||
| - | The PERSIST command is used to display and set the PERSIST | ||
| - | value for a port. This is the " | ||
| - | given time slot (see SLOTTIME), used as part of the CSMA | ||
| - | channel access procedure, to minimise media contention. | ||
| - | |||
| - | A low value is used when there are several stations sharing | ||
| - | the channel, giving each a fair chance to transmit. | ||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | If the command is used with a single numeric argument, the | ||
| - | current setting for that port number is displayed. | ||
| - | |||
| - | If two arguments are supplied, the PERSIST value for the port | ||
| - | specified by the first is set to the value of the second. | ||
| - | The new setting remains in force until changed again or until | ||
| - | XRouter is restarted, in which case the value specified in | ||
| - | the XROUTER.CFG file will apply. | ||
| - | |||
| - | </ | ||
| - | PERSIST 5 - Display current PERSIST value for port 5 | ||
| - | PERSIST 5 64 - Set port 5 PERSIST to 64 | ||
| - | |||
| - | </ | ||
| - | On KISS ports, you should allow up to 5 minutes for a new | ||
| - | setting to become active. | ||
| - | |||
| - | </ | ||
| - | PERSIST(7) | ||
| - | SLOTTIME(1) -- Display / Set CSMA interval timer | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PING.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PING -- Send ICMP echo request(s). | ||
| - | |||
| - | </ | ||
| - | PING < | ||
| - | |||
| - | </ | ||
| - | The PING command is available to all users except guests, | ||
| - | i.e. those who access from the public Internet without using | ||
| - | a password. | ||
| - | |||
| - | </ | ||
| - | Sends ICMP echo request(s) to the specified IP address or | ||
| - | hostname for the purposes of route testing. | ||
| - | |||
| - | An optional data portion of " | ||
| - | and the echo request may optionally be repeated every | ||
| - | " | ||
| - | |||
| - | If there is a reply it will be displayed. | ||
| - | the system displays the number sent/rcvd, the average round | ||
| - | trip time in milliseconds, | ||
| - | for reply" process may be cancelled at any time by entering | ||
| - | <CR> by itself. | ||
| - | |||
| - | If you specify a hostname (e.g. gb7pzt.ampr.org) instead of a | ||
| - | numeric IP address the request may take longer to action if | ||
| - | the hostname isn't found in DOMAIN.SYS, because the name will | ||
| - | have to be resolved by sending a DNS request. | ||
| - | |||
| - | </ | ||
| - | PING 44.131.91.2 | ||
| - | PING 44.131.91.2 50 Single ping with 50 bytes data | ||
| - | PING gb7pzt | ||
| - | PING 44.131.91.2 512 10 Ping 512 bytes every 10 secs | ||
| - | |||
| - | The response for a single ping looks like this: | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | |||
| - | And for a repeating ping it looks like this: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | The router must have an IP address and have IP routing defined | ||
| - | for this command to work. Unrealistic ping rates are | ||
| - | prevented. The run length of a repeating ping for non-sysops | ||
| - | is restricted to 5 to prevent abuse. | ||
| - | |||
| - | </ | ||
| - | GPING(1) -- Globalnet Ping | ||
| - | NPING(1) -- Netrom Ping | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PIPEFLAG.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | PIPEFLAG -- Display / Set Frame Piping Options. | ||
| - | |||
| - | </ | ||
| - | PIPEF[lag] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The PIPEFLAG command is used to display and/or set the | ||
| - | PIPE options for a specified port. These flags are only | ||
| - | used when piping is active, and they control which frames | ||
| - | are piped. | ||
| - | |||
| - | New settings override those read from the XROUTER.CFG file, | ||
| - | and remain in force until changed, or XRouter is restarted. | ||
| - | |||
| - | The minimum abbreviation of this command is PIPEF. | ||
| - | |||
| - | </ | ||
| - | The argument is the sum of the required options from this | ||
| - | list: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | 16 - UI frames transmitted by XRouter. | ||
| - | 32 - Non-UI frames transmitted by XRouter. | ||
| - | 64 - Allow budlisted users to be piped. | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | The default is 3 (pipe UI and non-UI frames not addressed to | ||
| - | Nodecall or Nodealias). | ||
| - | |||
| - | </ | ||
| - | PIPEF 3 Enquire current PIPEFLAG setting for port 3. | ||
| - | PIPEF 4 5 On port 4, pipe received UI frames only. | ||
| - | |||
| - | </ | ||
| - | PIPE(1) | ||
| - | PIPEFLAG(7) | ||
| - | PIPES(9) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PIPE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PIPE -- Display / Set "frame piping" | ||
| - | |||
| - | </ | ||
| - | PIP[e] < | ||
| - | |||
| - | </ | ||
| - | Displays the current PIPE setting for a port, and allows | ||
| - | it to be changed. Pipes " | ||
| - | another. Exactly which frames are piped is controlled by | ||
| - | PIPEFLAG. | ||
| - | |||
| - | If two numeric arguments are supplied, a "frame pipe" is set | ||
| - | up from < | ||
| - | for the specified port is displayed. | ||
| - | |||
| - | If the second argument is zero, piping is disabled. | ||
| - | |||
| - | Modified settings remain in force until changed or system is | ||
| - | restarted. | ||
| - | |||
| - | </ | ||
| - | PIPE 3 - Display current PIPE setting for port 3 | ||
| - | PIPE 3 5 - Create pipe from port 3 to port 5 | ||
| - | PIPE 3 0 - Remove pipe from port 3. | ||
| - | |||
| - | </ | ||
| - | Requires SYSOP status. | ||
| - | |||
| - | </ | ||
| - | PIPE(7) | ||
| - | PIPES(9) | ||
| - | PIPEFLAG(1) -- Display / Configure Piping Options | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PMS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PMS -- Access Personal Message System(s) | ||
| - | |||
| - | </ | ||
| - | PM[s] [nodecall | nodealias] | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The PMS command connects the user either to this node's | ||
| - | integral PMS (Personal Message System), or to the PMS on | ||
| - | another XRouter. | ||
| - | |||
| - | If the user accesses the PMS using the " | ||
| - | returned to XRouter' | ||
| - | otherwise he is disconnected. | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied, the user is connected to the | ||
| - | built-in PMS. | ||
| - | |||
| - | If the argument is the nodecall or alias of another XRouter, | ||
| - | which is in the nodes table, the user is connected to the | ||
| - | PMS of that node instead. | ||
| - | |||
| - | </ | ||
| - | PMS -- Connect to the PMS on this node | ||
| - | PMS G8PZT -- Connect to the PMS on G8PZT node. | ||
| - | |||
| - | </ | ||
| - | If a command alias, or an application, | ||
| - | is defined, it takes priority over the inbuilt PMS. | ||
| - | |||
| - | </ | ||
| - | PMS(9) | ||
| - | PMS-SVC(9) -- NetRomX PMS Service. | ||
| - | WALL(1) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PORTS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PORTS -- Display / Edit the ports. | ||
| - | |||
| - | </ | ||
| - | P[orts] | ||
| - | P[orts] A[dd] < | ||
| - | P[orts] D[rop] < | ||
| - | P[orts] L[ist] | ||
| - | P[orts] S[tart] < | ||
| - | |||
| - | </ | ||
| - | The PORT[s] command, which may be abbreviated to " | ||
| - | be used to add, remove and list the communication ports. | ||
| - | |||
| - | </ | ||
| - | " | ||
| - | They display XRouter' | ||
| - | descriptions as specified by the PORTID fields in the CFG | ||
| - | file. | ||
| - | |||
| - | The " | ||
| - | the INTERFACE (which must already exist) specified by | ||
| - | < | ||
| - | The new port is not operational until after a "PORT START" | ||
| - | command (see below). This allows for the port parameters to | ||
| - | be set up and adjusted without affecting anything else. | ||
| - | |||
| - | The " | ||
| - | anything is seriously wrong it will complain, allowing the | ||
| - | configuration to be changed bfore attempting START again. | ||
| - | |||
| - | The " | ||
| - | |||
| - | </ | ||
| - | The basic " | ||
| - | ADD and DROP and START sub-commands are sysop-only. | ||
| - | |||
| - | </ | ||
| - | The lack of a STOP sub-command is deliberate, to prevent | ||
| - | ports being stopped and forgotten about. | ||
| - | |||
| - | </ | ||
| - | Starting and stopping ports on a system with so many hardware | ||
| - | and protocol combinations is horrendously complex. It is not | ||
| - | practicable to test all combinations prior to release, | ||
| - | therefore this cannot be guaranteed to be bug free. Please | ||
| - | report any issues, so they can be corrected. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====PPP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | PPP -- Point to Point Protocol Configuration commands. | ||
| - | |||
| - | </ | ||
| - | PPP < | ||
| - | PPP < | ||
| - | PPP < | ||
| - | PPP < | ||
| - | PPP < | ||
| - | PPP < | ||
| - | PPP < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | Point to Point Protocol (PPP) is a protocol suite intended | ||
| - | for use over simple links which transport packets between two | ||
| - | peers, such as an RS232 link. The PPP commands are used to | ||
| - | configure the system. | ||
| - | |||
| - | </ | ||
| - | The IDLE subcommand is used to display or set the PPP link | ||
| - | inactivity timer, which disconnects the link after a period of | ||
| - | inactivity. | ||
| - | |||
| - | The IPCP subcommands control the IPCP (IP Control Protocol) | ||
| - | parameters for each end of the link. ADDRESS specifies the | ||
| - | IP addresses used for the link, and DNS specifies the IP | ||
| - | addresses of the Domain Name Server. | ||
| - | |||
| - | The LCP subcommands control the LCP (Link Control Protocol) | ||
| - | parameters for each end of the link. AUTH specifies the | ||
| - | authentication protocol (if any) which the link will use. | ||
| - | The only authentication protocol currently supported is PAP. | ||
| - | |||
| - | The MRU command specifies the Maximum Receive Unit, i.e. the | ||
| - | largest datagram the host is prepared to accept. | ||
| - | are 128 and 4096. DEFAULT restores the default LCP parameters | ||
| - | which all hosts understand. | ||
| - | |||
| - | The LOG subcommand displays or sets the PPP logging level, | ||
| - | which controls how much diagnostic detail is recorded in the | ||
| - | PPLOG.TXT file. The argument is as follows: | ||
| - | |||
| - | 0 No logging | ||
| - | 1 PPP start/ | ||
| - | 2 As 1, plus layer up/down events | ||
| - | 3 As 2, plus layer start/stop events | ||
| - | 4 as 3, plus option accept/ | ||
| - | 5 as 4, plus hexdump of configuration packets | ||
| - | |||
| - | The PAP subcommand displays or sets PAP (Password | ||
| - | Authentication Protocol) parameters. | ||
| - | parameter is USER, which specifies the username and password | ||
| - | for PAP login. | ||
| - | |||
| - | </ | ||
| - | PPP 1 IDLE 300 | ||
| - | PPP 1 IPCP LOCAL ADDRESS 62.31.45.67 | ||
| - | PPP 3 LCP LOCAL AUTH PAP | ||
| - | PPP 3 LCP LOCAL DEFAULT | ||
| - | PPP 3 LCP LOCAL MRU 1500 | ||
| - | PPP 3 LOG 3 | ||
| - | PPP 1 PAP USER g8pzt zedfrgc | ||
| - | |||
| - | </ | ||
| - | When used from the command line, or with a BOOTCMDS.SYS file, | ||
| - | the first argument must be a port number. | ||
| - | commands used within PPPHOST and dialler scripts *do not* | ||
| - | include a port number, because XRouter knows which port is | ||
| - | executing the script. | ||
| - | |||
| - | e.g. at the command line: PPP 3 IDLE 300 | ||
| - | in a dialler script: PPP IDLE 300 | ||
| - | |||
| - | You are advised against using the higher PPP LOG levels other | ||
| - | than on a temporary basis because they can create very large | ||
| - | logfiles. | ||
| - | |||
| - | </ | ||
| - | DUN(9) | ||
| - | PPP(9) | ||
| - | SCRIPT(9) -- Dialler script commands | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====QUALITY.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | QUALITY -- Display / Set default quality value for a port. | ||
| - | |||
| - | </ | ||
| - | Q[UALITY] < | ||
| - | |||
| - | </ | ||
| - | This command is only available to sysops. | ||
| - | |||
| - | </ | ||
| - | Displays or sets the default quality for nodes heard on the | ||
| - | specified port. It should be set to zero to suppress all | ||
| - | level 3/4 activity on a port, e.g. on user access frequencies. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current quality | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the quality for the | ||
| - | port specified by the first is set to the value of the second. | ||
| - | The new setting remains in force until changed, or until the | ||
| - | router is restarted, in which case the setting reverts to that | ||
| - | specified in the config file. | ||
| - | |||
| - | </ | ||
| - | QUALITY 3 - Display current quality for port 3 | ||
| - | QUALITY 3 40 - Set port 3 default quality to 40 | ||
| - | |||
| - | </ | ||
| - | QUALITY(7) -- Default NetRom Quality. | ||
| - | QUALADJ(7) -- NetRom Quality Manipulation. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====QUIT.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | QUIT -- Disconnect from the router. | ||
| - | |||
| - | </ | ||
| - | Q[uit] | ||
| - | |||
| - | </ | ||
| - | The QUIT command performs the same function as BYE, namely to | ||
| - | terminate your session with the router. | ||
| - | will occur only when all outstanding data has been sent to | ||
| - | you. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | BYE(1) -- Disconnect | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RADIO.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RADIO -- Add/ | ||
| - | |||
| - | </ | ||
| - | RA[dio] A[dd] < | ||
| - | RA[dio] C[ontrol] < | ||
| - | RA[dio] D[rop] < | ||
| - | RA[dio] L[ist] | ||
| - | RA[dio] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only? | ||
| - | |||
| - | </ | ||
| - | The RADIO command is used to add, remove, list and control | ||
| - | radios that are connected to XRouter. | ||
| - | |||
| - | This can be used for controlling the operating parameters of | ||
| - | a CAT-controlled radio that is being used for Packet, or for | ||
| - | controlling a voice receiver or transceiver, | ||
| - | operations. | ||
| - | |||
| - | Up to 5 radios can currently be supported. If there is any | ||
| - | need for more, this can be changed in a future version. | ||
| - | |||
| - | *** This system is unfinished and may change *** | ||
| - | |||
| - | Radios are usually added at boot-time using RADIO definition | ||
| - | blocks in XROUTER.CFG, | ||
| - | be added and removed during run-time. | ||
| - | |||
| - | There are TWO ways to control a radio. The first is by using | ||
| - | " | ||
| - | (see list below). | ||
| - | |||
| - | The second method is to start a " | ||
| - | which allows commands to be entered directly, e.g. "mode AM", | ||
| - | "tx on" and so on. | ||
| - | |||
| - | </ | ||
| - | " | ||
| - | |||
| - | The A[dd] sub-command adds a radio to the list. The < | ||
| - | must be within the range 1 to 5 inclusive. The [options] are | ||
| - | yet to be decided. | ||
| - | |||
| - | The D[rop] sub-command removes a radio from the radio list. | ||
| - | |||
| - | The L[ist] sub-command lists the radios. | ||
| - | |||
| - | The C[ontrol] command starts a "radio control" | ||
| - | which allows direct entry of the various control commands | ||
| - | listed below: | ||
| - | |||
| - | Radio Control Commands: | ||
| - | ~~~~~~~~~~~~~~~~~~~~~~~ | ||
| - | A[m] | ||
| - | CT[css] [frq | code] Display/set CTCSS frequency or code | ||
| - | CW | ||
| - | CWR Select ' | ||
| - | D[own] [Hz] Step frequency down by STEPsize or Hz | ||
| - | E[xit] | ||
| - | F[requency] [Hz] | ||
| - | FI[lter] [Hz] Enquire or set IF filter width, | ||
| - | FM | ||
| - | FMN Select Narrow FM mode | ||
| - | FMW Select Wide FM mode | ||
| - | LSB Select Lower Side Band mode, | ||
| - | M[ode] [mode | LIST] Enquire or set modulation mode | ||
| - | NFM Select Narrow FM mode | ||
| - | O[ffset] [Hz] Display / Set Repeater TX Offset | ||
| - | P[ower] [on | off] | ||
| - | S[hift] [- | 0 | +] Display / Set Repeater TX Shift | ||
| - | SQ[uelch] [0-100] | ||
| - | SSB Select Single Side Band mode | ||
| - | ST[atus] | ||
| - | STE[p] [Hz] Enquire / set step size for UP/DOWN | ||
| - | T[x] [on | off] Begin / end transmissions | ||
| - | TS[q] [freq | code] Display/set Tone Squelch freq or code | ||
| - | V[olume] [0-100] | ||
| - | U[p] [Hz] Increase frequency by STEP or Hz | ||
| - | USB Select Upper Side Band mode | ||
| - | WFM Select Wide FM mode | ||
| - | |||
| - | Not all radios support all commands. For example, the " | ||
| - | command is meaningless on a receiver, and " | ||
| - | on an FM-only radio. | ||
| - | |||
| - | </ | ||
| - | RADIO(7) | ||
| - | XROUTER.CFG(8) -- Main configuration file | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====REBOOT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | REBOOT -- Reboot machine. | ||
| - | |||
| - | </ | ||
| - | RE[boot] | ||
| - | |||
| - | </ | ||
| - | This command is available only in the DOS version of XRouter. | ||
| - | |||
| - | It reboots the machine immediately and ungracefully. | ||
| - | |||
| - | It is typically used by remote sysops to restart the machine | ||
| - | after editing autoexec.bat/ | ||
| - | version of the software, or to recover from potentially | ||
| - | dangerous situations such as a corrupt hard drive. | ||
| - | |||
| - | Console sysops can use the " | ||
| - | or interrupt the power instead. | ||
| - | |||
| - | </ | ||
| - | Remote sysops should only use this command if XRouter has been | ||
| - | started from AUTOEXEC.BAT, | ||
| - | |||
| - | It is recommended that you include an automatic disk check and | ||
| - | repair utility within AUTOEXEC.BAT to remove any problems | ||
| - | which resulted in the REBOOT command being used. | ||
| - | |||
| - | </ | ||
| - | RESTART(1) -- Restart XRouter. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RESPTIME.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | RESPTIME -- Display / Set L2 delayed ack time for port. | ||
| - | |||
| - | </ | ||
| - | RESPTIME < | ||
| - | |||
| - | </ | ||
| - | This is a sysop-only command. | ||
| - | |||
| - | </ | ||
| - | The RESPTIME command allows the value of the AX25 T2 (delayed | ||
| - | ack) time for a port to be displayed or altered. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies | ||
| - | the port number, and the second specifies the new value for | ||
| - | the parameter. | ||
| - | changed, or until XRouter is restarted, in which case the | ||
| - | value specified by RESPTIME in the relevant PORT block in | ||
| - | XROUTER.CFG is reapplied. | ||
| - | |||
| - | </ | ||
| - | RESPTIME 3 - Display current setting for port 3 | ||
| - | RESPTIME 3 150 - Set port 3 resptime to 1500 millisecs | ||
| - | |||
| - | </ | ||
| - | The RESPTIME parameter specifies how long XRouter waits, | ||
| - | after receiving a frame, before sending an ack for that | ||
| - | frame. | ||
| - | unnecessary acks. It allows a single ack to be sent when a | ||
| - | transmission contains several frames, instead of acking each | ||
| - | frame in turn. | ||
| - | |||
| - | The value must therefore be at least the length of time it | ||
| - | takes the link partner to transmit a single packet. | ||
| - | bauds (120 bytes/sec) a 120 byte packet lasts 1 second, a 180 | ||
| - | byte packet lasts 1500 millisecs and a 256 byte packet lasts | ||
| - | just over 2 seconds. | ||
| - | PACLEN used by the link partner. | ||
| - | compromise, but if the other end regularly uses high paclens, | ||
| - | 2000 or 2500 ms would be more appropriate. | ||
| - | |||
| - | At 9600 baud, or on AXUDP links, 200 millisecs is probably | ||
| - | adequate. | ||
| - | |||
| - | 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. | ||
| - | |||
| - | </ | ||
| - | FRACK(1) | ||
| - | PACLEN(1) | ||
| - | SLOTTIME(1) | ||
| - | RESPTIME(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RESTART.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | RESTART -- Restart XRouter. | ||
| - | |||
| - | </ | ||
| - | RES[tart] | ||
| - | |||
| - | </ | ||
| - | Sysops only. | ||
| - | |||
| - | </ | ||
| - | Re-starts the XRouter program immediately and ungracefully. | ||
| - | |||
| - | It is typically used by remote sysops to restart the program | ||
| - | after modifying the config files, or installing a new version | ||
| - | of the software. | ||
| - | |||
| - | All open links are closed, and the program starts again from | ||
| - | scratch. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RETRIES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | RETRIES -- Display / Set Maximum AX25 Retries. | ||
| - | |||
| - | </ | ||
| - | RETRIES < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The RETRIES command allows the value of the level 2 maximum | ||
| - | retry value for a port to be displayed or altered, i.e. the | ||
| - | maximum no. of attempts at sending a frame without a reply | ||
| - | being received. | ||
| - | means "try forever", | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies the | ||
| - | port number, and the second specifies the new value for the | ||
| - | parameter. | ||
| - | until the router is restarted, in which case the value | ||
| - | specified in the CFG file is reapplied. | ||
| - | |||
| - | </ | ||
| - | RETRIES 3 - Display current setting for port 3 | ||
| - | RETRIES 3 15 - Set port 3 max retries to 15 | ||
| - | |||
| - | </ | ||
| - | RETRIES(7) -- AX25 Maximum Retry Count. | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====RIP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | RIP -- Routing Interface Protocol configuration commands. | ||
| - | |||
| - | </ | ||
| - | RIP AC[cept] < | ||
| - | RIP A[dd] < | ||
| - | RIP D[rop] < | ||
| - | RIP L[earn] [ON | OFF] | ||
| - | RIP R[efuse] < | ||
| - | RIP S[tatus] | ||
| - | RIP T[imeout] [secs] | ||
| - | |||
| - | </ | ||
| - | RIP allows IP routers to learn of each other' | ||
| - | similar fashion to NetRom. | ||
| - | used by the IPEncap-based " | ||
| - | form optimised for radio, and the RIP commands are used to | ||
| - | configure the system. | ||
| - | |||
| - | </ | ||
| - | Peers which have been added to the refuse list using the RIP | ||
| - | REFUSE command can be removed using RIP ACCEPT, allowing the | ||
| - | router to learn information from them. < | ||
| - | IP address of the peer. | ||
| - | |||
| - | RIP ADD adds a peer to the list of those who will receive RIP | ||
| - | transmissions from us. The < | ||
| - | interval between transmissions, | ||
| - | agreement with the peer, so that < | ||
| - | quarter of the lifetime of their RIP entries. | ||
| - | to 4 transmissions to be lost before the route is purged. | ||
| - | |||
| - | RIP DROP removes a peer from the list of those who receive | ||
| - | RIP transmissions from us. | ||
| - | |||
| - | RIP LEARN turns route learning on or off. By default, RIP98 | ||
| - | route learning is OFF. If no arguments are given, the | ||
| - | current status is reported. | ||
| - | routes from its RIP98 peers, and " | ||
| - | recommend enabling LEARN mode. | ||
| - | |||
| - | RIP REFUSE is the opposite of ACCEPT. | ||
| - | refuse list so broadcasts from that peer will be ignored. | ||
| - | This command is provided in case you need to exclude a peer | ||
| - | which is advertising faulty routes. | ||
| - | |||
| - | RIP STATUS displays various RIP98 parameters such as the list | ||
| - | of peers who receive broadcasts from us, the list of peers we | ||
| - | are ignoring, the timeout value, and the setting of learn | ||
| - | mode. | ||
| - | |||
| - | RIP TIMEOUT is used to display and set the lifetime of | ||
| - | learned routes. | ||
| - | lifetime. | ||
| - | lifetime, it is removed from the routes table. | ||
| - | should preferably be 4 times the interval between broadcasts | ||
| - | from peers, and the default is currently 4 hours. | ||
| - | |||
| - | </ | ||
| - | RIP ACCEPT 44.131.95.2 | ||
| - | RIP ADD 44.131.95.240 3600 | ||
| - | RIP DROP 44.131.90.6 | ||
| - | RIP LEARN ON | ||
| - | RIP REFUSE 44.131.57.1 | ||
| - | RIP STATUS | ||
| - | RIP TIMEOUT 14400 | ||
| - | |||
| - | </ | ||
| - | The RIP ADD, LEARN, REFUSE and TIMEOUT commands may also be | ||
| - | used within IPROUTE.SYS or BOOTCMDS.SYS. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | BOOTCMDS.SYS(8) -- Commands to Execute at Bootup. | ||
| - | IPROUTE.SYS(8) -- IP Router Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====ROUTES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | ROUTES -- Add, Drop and List NetRom Routes. | ||
| - | |||
| - | </ | ||
| - | R[outes] [* | H | L | R | Q | T | X ] [portnum] | ||
| - | R[outes] A[dd] < | ||
| - | R[outes] D[rop] < | ||
| - | |||
| - | </ | ||
| - | The ROUTES command, which may be abbreviated to " | ||
| - | the immediately adjacent NetRom nodes, i.e. those who can be | ||
| - | heard directly, providing those nodes are making NetRom nodes | ||
| - | broadcasts. | ||
| - | |||
| - | For each neighbour node the display always shows the port | ||
| - | number, the neighbour' | ||
| - | number of nodes accessible via that neighbour. | ||
| - | |||
| - | G8PZT: | ||
| - | Port Callsign | ||
| - | > 5 G4FPV | ||
| - | > 7 GB7PZT | ||
| - | > 8 GB7WV-12 | ||
| - | > 9 GB7GH 150 104! | ||
| - | 10 GB7CL | ||
| - | > 11 GB7IPT-7 | ||
| - | 12 G1LOA-10 | ||
| - | |||
| - | A chevron (>) in the left-most column indicates a route which | ||
| - | is in use. A tilde (~) indicates that the connection is in | ||
| - | the process of being established. An " | ||
| - | route, and a blank space indicates a closed (but not failed) | ||
| - | route. | ||
| - | |||
| - | An exclamation mark (!) in the right-most column indicates | ||
| - | that the data has been " | ||
| - | |||
| - | Any additional information, | ||
| - | above, depends on which additional option is supplied, as | ||
| - | detailed in the next section. | ||
| - | |||
| - | </ | ||
| - | Some of the options give identical output, because they were | ||
| - | renamed and the old ones were retained for backward | ||
| - | compatability. | ||
| - | |||
| - | If no options are specified, the output is similar to the | ||
| - | example above. | ||
| - | |||
| - | The following options don't display any routes: | ||
| - | |||
| - | * displays a brief list of the available options. | ||
| - | ** lists the options with brief descriptions. | ||
| - | A[dd] is used to add a route. | ||
| - | D[rop] is used to remove a route. | ||
| - | H[elp] lists the options with brief descriptions. | ||
| - | |||
| - | Options which display routes and modify the display format | ||
| - | are as follows: | ||
| - | |||
| - | L[oad] displays traffic loading & connection percentage | ||
| - | Q[ual] displays estimated route qualities | ||
| - | R[etr] displays sent/resent frames & retry rates | ||
| - | T[ime] displays trip times & settings for time metrics | ||
| - | X[tra] displays running average & peak retry rates | ||
| - | Y is the same as T[ime] (deprecated) | ||
| - | Z is the same as L[oad] (deprecated) | ||
| - | |||
| - | If the first or second option is a valid port number, only | ||
| - | the information for that port is displayed. | ||
| - | |||
| - | </ | ||
| - | L[oad] displays information about connection percentage and | ||
| - | data throughputs, | ||
| - | |||
| - | | ||
| - | 98% 3024 3024 | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | Q[ual] displays the estimated route qualities, for example: | ||
| - | |||
| - | | ||
| - | 245 240 252 1 | ||
| - | |||
| - | These are based on measurements of actual link | ||
| - | | ||
| - | They are intended as a guide to help sysops make informed | ||
| - | | ||
| - | | ||
| - | | ||
| - | mean. | ||
| - | |||
| - | |||
| - | R[etr] displays the current MAXFRAME, FRACK and PACLEN | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | |||
| - | T[ime] displays information and settings concerned with | ||
| - | | ||
| - | |||
| - | | ||
| - | 63 0.03 | ||
| - | |||
| - | The displayed values are as follows: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | 1 - Route locked in by sysop. | ||
| - | 2 - Neighbour is INP3 compatible. | ||
| - | 4 - Neighbour responds to our L3RTT probes. | ||
| - | 8 - Neighbour is XRouter | ||
| - | 16 - Automatic route quality enabled. | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | The final figure is the neighbour' | ||
| - | may differ from ours. | ||
| - | |||
| - | |||
| - | X[tra] displays extended information about the retry rates: | ||
| - | |||
| - | | ||
| - | | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | The running average retry rate is more responsive to | ||
| - | | ||
| - | long term mean. | ||
| - | |||
| - | These stats often reveal links with low *mean* retry rates | ||
| - | that display some surprising short term highs. | ||
| - | | ||
| - | |||
| - | A[dd] adds a new route or modifies an existing one. The | ||
| - | arguments are as follows: | ||
| - | |||
| - | < | ||
| - | |||
| - | < | ||
| - | reached. | ||
| - | |||
| - | < | ||
| - | A quality between 256 and 511 will instruct | ||
| - | XRouter to use " | ||
| - | value of (qual-256). | ||
| - | |||
| - | [!] locks the entry to prevent it being overridden by | ||
| - | | ||
| - | |||
| - | [V digis] specifies a digipeated route, where " | ||
| - | is a string of digipeater calls seperated by | ||
| - | | ||
| - | |||
| - | | ||
| - | maxhops values to override the port defaults. | ||
| - | The format is: | ||
| - | |||
| - | [maxframe [frack [paclen [maxtt [maxhops]]]]] | ||
| - | |||
| - | i.e. in order to specify maxtt you must also | ||
| - | specify maxframe, frack and paclen | ||
| - | any field you don't wish to change. | ||
| - | |||
| - | </ | ||
| - | route add g8pzt 5 100 | ||
| - | route add g6yak 2 100 ! V G8EPR,G8NTU 5 7000 | ||
| - | route add g8klm 3 150 ! 0 0 245 2000 3 | ||
| - | route drop mb7uyl 14 | ||
| - | r 4 -- Display basic information for routes on port 4 | ||
| - | r t 5 -- Display TDR information for routes on port 5 | ||
| - | |||
| - | </ | ||
| - | The ROUTES command is available to all users, but the ADD | ||
| - | and DROP options are sysop-only. | ||
| - | |||
| - | </ | ||
| - | AUTOQUAL(9) | ||
| - | NODES(1) | ||
| - | PERMLINKS(9) -- Permanent NetRom Neighbour Links. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SAVENODES.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | SAVENODES -- Save Nodes and Routes Tables to Disk. | ||
| - | |||
| - | </ | ||
| - | SA[venodes] [filename] | ||
| - | |||
| - | </ | ||
| - | The SAVENODES command dumps the nodes and routes tables to | ||
| - | a " | ||
| - | and used to reconstruct the tables without having to wait | ||
| - | for nodes broadcasts to be received. | ||
| - | |||
| - | Table dumping occurs automatically to file XRNODES every | ||
| - | hour, and when XRouter is closed down using Alt-x, but this | ||
| - | command allows you to dump and examine the tables at any | ||
| - | time, without taking XRouter off line. | ||
| - | |||
| - | </ | ||
| - | The optional argument specifies the filename to dump to, and | ||
| - | if not specified it defaults to XRNODES. | ||
| - | |||
| - | </ | ||
| - | The XRNODES file is similar in format to the BPQNODES file | ||
| - | used with the DOS version of BPQ node, but is no longer | ||
| - | compatible with it. | ||
| - | |||
| - | XRNODES is a plain text file, which may be viewed with | ||
| - | Notepad by adding the extension .TXT | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | LOADNODES(1) -- Load Nodes and Routes. | ||
| - | XRNODES(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SCRIPT-CMD.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | < -- Execute XRouter Command Scripts. | ||
| - | |||
| - | </ | ||
| - | < < | ||
| - | |||
| - | </ | ||
| - | The "<" | ||
| - | XRouter commands contained therein. | ||
| - | |||
| - | This would typically be used to execute frequently used | ||
| - | command sequences. | ||
| - | |||
| - | </ | ||
| - | < MYCMDS.TXT | ||
| - | |||
| - | </ | ||
| - | The script must not include any commands which require | ||
| - | interaction with the sysop, otherwise it will stop XRouter. | ||
| - | |||
| - | </ | ||
| - | Sysops-only. | ||
| - | |||
| - | </ | ||
| - | SHELL(1) -- Run Command or Program in an O/S Shell. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SECTIONS.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SECTIONS -- List of Sysop Manual Sections. | ||
| - | |||
| - | </ | ||
| - | The manual is divided into several sections as follows: | ||
| - | |||
| - | | ||
| - | | ||
| - | 1 General Commands | ||
| - | 2 Chat Server Commands | ||
| - | 3 PZTDOS commands | ||
| - | 4 Mailbox commands | ||
| - | 6 Installation & Configuration Topics | ||
| - | 7 Configuration Directives | ||
| - | 8 Configuration / System Files. | ||
| - | 9 Miscellaneous Topics | ||
| - | |||
| - | For sections other than 1 and 8, the section is indicated | ||
| - | by a number appended to the topic name, e.g. MHEARD.9 | ||
| - | |||
| - | </ | ||
| - | MAN(1) -- The MAN command. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SEND.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | SEND -- Send unproto text | ||
| - | |||
| - | </ | ||
| - | SE[nd] < | ||
| - | |||
| - | </ | ||
| - | All users, except guests. | ||
| - | |||
| - | </ | ||
| - | Sends an unproto (UI) packet on the specified port. The | ||
| - | destination address and up to 8 digis may be specified. | ||
| - | |||
| - | This command is included to facilitate tests, and may be | ||
| - | called by entries in CRONTAB.SYS for sending extra beacons. | ||
| - | |||
| - | </ | ||
| - | Send 7 CQ V G8EPR,G8AKX Meet me on 144.800! | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SHELL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | SHELL -- Run a Command or Program in an O/S Shell. | ||
| - | |||
| - | </ | ||
| - | SH[ell] <cmd> [args...] | ||
| - | |||
| - | </ | ||
| - | The SHELL command is used for running commands, scripts and | ||
| - | simple programs in a temporary DOS, Windows or Linux shell | ||
| - | which terminates upon completion of the operation. | ||
| - | |||
| - | It is suitable for simple non-interactive commands such as | ||
| - | DIR, MD, and TYPE, or programs that run and terminate without | ||
| - | requiring any further input from the user. | ||
| - | |||
| - | The " | ||
| - | |||
| - | </ | ||
| - | SHELL DIR /W (on a DOS / Windows platform) | ||
| - | SHELL ls -l (on a Linux platform) | ||
| - | SHELL fetch_weather_data.sh | ||
| - | |||
| - | </ | ||
| - | Running interactive commands or programs via this means | ||
| - | (e.g. piping a directory listing via MORE) is not possible, | ||
| - | as XRouter is suspended while the external command or program | ||
| - | runs. | ||
| - | |||
| - | </ | ||
| - | Sysops only | ||
| - | |||
| - | </ | ||
| - | SCRIPT-CMD(1) -- Execute XRouter Command Scripts. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SLOTTIME.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | SLOTTIME -- Display / Set the slottime parameter for a port. | ||
| - | |||
| - | </ | ||
| - | SLOTTIME < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The SLOTTIME command allows the value of the CSMA interval | ||
| - | timer for a port to be displayed or altered. | ||
| - | setting is 100 milliseconds. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the slottime value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies | ||
| - | the port number, and the second specifies the new value for | ||
| - | the parameter. The new setting remains in force until | ||
| - | changed, or until XRouter is restarted, in which case the | ||
| - | value specified in XROUTER.CFG is reapplied. | ||
| - | |||
| - | </ | ||
| - | SLOTTIME 3 - Display current setting for port 3 | ||
| - | SLOTTIME 3 150 - Set port 3 slottime to 150 | ||
| - | |||
| - | </ | ||
| - | PERSIST(7) | ||
| - | SLOTTIME(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====SMS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | SMS -- Short Messaging System for XR sysops. | ||
| - | |||
| - | </ | ||
| - | SMS [nodecall [text]] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The SMS command can either invoke an SMS client, or directly | ||
| - | send a short message to the sysop of another XRouter. This is | ||
| - | a messaging service for XRouter sysops, and has nothing to do | ||
| - | with telephone SMS. | ||
| - | |||
| - | Sysops have a need to communicate with each other. Some of | ||
| - | them leave messages for each other on the sysop chat, but | ||
| - | that tends to scroll off the screen and get lost. It is also | ||
| - | very public, and unecessarily broadcasts the message to every | ||
| - | chat server. The PMS can be used, but it isn't very " | ||
| - | and has no sense of " | ||
| - | incoming messages. | ||
| - | |||
| - | To try and solve this problem, the SMS system was created. | ||
| - | |||
| - | Unlike the BBS system, SMS messages are delivered directly | ||
| - | from the source node to the recipient node, without | ||
| - | intermediate store and forward. Thus it curently only works | ||
| - | with nodes that are in your list. However, as most XRouter | ||
| - | nodes are known to each other, that's not much of a problem. | ||
| - | In future there will be no such restriction. | ||
| - | |||
| - | There is a "read receipt" | ||
| - | whether or not their message has been received and read. | ||
| - | |||
| - | The recipent is alerted to the presence of a short message | ||
| - | by a flashing " | ||
| - | used to display the messages, send relies etc. | ||
| - | |||
| - | The SMS Client | ||
| - | ~~~~~~~~~~~~~~ | ||
| - | Upon entering the client, any new message(s) are displayed. | ||
| - | If there is more than one new message in a conversation, | ||
| - | first unread one is displayed: | ||
| - | |||
| - | sms | ||
| - | G8PZT-1: | ||
| - | |||
| - | SMS Conversations: | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | R)ead | ||
| - | |||
| - | Note that unlike a PMS or BBS, this is CONVERSATION not | ||
| - | MESSAGE oriented. | ||
| - | |||
| - | Each {nodecall} in the above list indicates a conversation | ||
| - | with the sysop of that node. A conversation consists of one | ||
| - | or more messages between you and the other party in strict | ||
| - | chronological sequence. Both sides of the conversation are | ||
| - | included. | ||
| - | |||
| - | The argument to each command, with the exception of " | ||
| - | is a {nodecall}, i.e. a conversation. So " | ||
| - | archives the conversation to a file, removing it from the | ||
| - | list. | ||
| - | |||
| - | R)ead Reads a conversation | ||
| - | S)end Sends a message to a conversation | ||
| - | A)rchive | ||
| - | D)elete | ||
| - | E)xit Exits the client and returns to the node. | ||
| - | |||
| - | "R G8PZT" reads the conversation between you and G8PZT, | ||
| - | starting at the first unread message. If there are no unread | ||
| - | messages it displays the last message. | ||
| - | |||
| - | In this example there are both previous and subsequent | ||
| - | messages, which can be displayed using the Next and P)revious | ||
| - | commands: | ||
| - | |||
| - | r g8pzt | ||
| - | |||
| - | Sent: 18/05/21 03:27:20 | ||
| - | To: G8PZT | ||
| - | |||
| - | test at 03:25 tuesday | ||
| - | |||
| - | S)end, | ||
| - | |||
| - | The " | ||
| - | shows how unfinished the user interface is!! It really means | ||
| - | " | ||
| - | |||
| - | The C)onversations option returns you to the list of | ||
| - | conversations. | ||
| - | |||
| - | </ | ||
| - | Typing " | ||
| - | you view the conversations, | ||
| - | |||
| - | The "SMS < | ||
| - | and prompts for the message body. | ||
| - | |||
| - | The "SMS < | ||
| - | and returns to the command line. | ||
| - | |||
| - | </ | ||
| - | SMS | ||
| - | SMS G8PZT | ||
| - | SMS G8PZT I'll be on sysop chat at 3pm UTC | ||
| - | |||
| - | </ | ||
| - | CHAT(1) | ||
| - | PMS(1) | ||
| - | SMS-SVC(9) -- SMS Service | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====START.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | START -- Start a daemon process. | ||
| - | |||
| - | </ | ||
| - | ST[art] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The START command is used to start daemons, which in this | ||
| - | context are XRouter processes which run independently of any | ||
| - | controlling session. | ||
| - | processes are daemons. | ||
| - | |||
| - | </ | ||
| - | START IGATE | ||
| - | |||
| - | </ | ||
| - | Attempting to start a daemon which is already running will | ||
| - | have no harmful effect. | ||
| - | |||
| - | </ | ||
| - | STOP(1) -- Stop a daemon. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====STATS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | STATS -- Display XRouter statistics. | ||
| - | |||
| - | </ | ||
| - | S[tats] [ L1 | L2 | L3 | L4 | IP | TCP | * ] | ||
| - | S[tats] [AXIP | AXUDP | AXTCP | IDS] | ||
| - | |||
| - | </ | ||
| - | All users, but IDS stats can only be viewed by sysop. | ||
| - | |||
| - | </ | ||
| - | Displays information about the performance of XRouter, such | ||
| - | as the uptime, the no. of packets routed, error rates etc. | ||
| - | |||
| - | Stats may be displayed for a single ISO layer, or for all | ||
| - | layers. | ||
| - | |||
| - | </ | ||
| - | Entering S by itself will give a single page synopsis. | ||
| - | |||
| - | "S ?" displays a list of the subcommands, | ||
| - | |||
| - | "S *" displays the full stats for all layers. | ||
| - | |||
| - | "S < | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | AXUDP - "AX25 in UDP/ | ||
| - | AXTCP - "AX25 in TCP/ | ||
| - | |||
| - | "S IDS" displays brief stats for XRouter' | ||
| - | Detection System. This is mainly of use to remote sysops, | ||
| - | because all the information is already available to console | ||
| - | sysops via the " | ||
| - | |||
| - | A typical response | ||
| - | |||
| - | G8PZT: | ||
| - | |||
| - | TCP Scans: SYN=837 FIN=0 ACK=152 NUL=0 MAI=37 XMS=0 OTH=1632 | ||
| - | Bogus SYNs: 2083 | ||
| - | Rejected Logins: Telnet=77, Rlogin=0, FTP=7, TelProxy=0 | ||
| - | Malicious Logins: Telnet=334, Rlogin=0, FTP=47, TelProxy=0 | ||
| - | FTP directory hacks: 0 | ||
| - | IDS Notifications: | ||
| - | IP frames from banned senders: 3155 | ||
| - | IP Fragmentation attacks: Tiny=5 | ||
| - | Smurfs: 0 Fraggles: 0 | ||
| - | Honeypot Hits: 27 | ||
| - | |||
| - | Note that if your node is AX25-only, or completely hidden | ||
| - | behind a firewall, many of these stats will be 0, which is a | ||
| - | good thing :-) | ||
| - | |||
| - | </ | ||
| - | | ||
| - | S * | ||
| - | S IP Display only the IP-layer stats | ||
| - | |||
| - | </ | ||
| - | Screen width is only 80 characters, so on systems with many | ||
| - | ports and interfaces the display may wrap. | ||
| - | |||
| - | </ | ||
| - | STATS(9) -- Explanation of the individual stats fields. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====STOP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | STOP -- Stop a daemon process / List active daemons. | ||
| - | |||
| - | </ | ||
| - | STO[p] [process_name] | ||
| - | |||
| - | </ | ||
| - | The STOP command is used to stop an XRouter internal daemon | ||
| - | process whose name name is specified as the argument. | ||
| - | |||
| - | If STOP is used without arguments, a list of the active | ||
| - | processes is displayed. | ||
| - | |||
| - | </ | ||
| - | STOP IGATE | ||
| - | |||
| - | </ | ||
| - | Attempting to stop a process which is not running will simply | ||
| - | produce an error message. | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | START(1) -- Start a daemon. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TALK.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TALK -- Talk to a user or another sysop. | ||
| - | |||
| - | </ | ||
| - | TA[lk] <sessnum | nodecall> | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The TALK command allows a sysop to have a keyboard chat with | ||
| - | a locally connected user, or the sysop of another XRouter. | ||
| - | |||
| - | It is usually, but not always, invoked in response to a user | ||
| - | issuing the YELL command. | ||
| - | |||
| - | If the argument is a session number, e.g. "talk 123", it | ||
| - | allows the sysop to talk to a logged-in user. | ||
| - | |||
| - | If the argument is a node callsign or alias, for example. | ||
| - | "talk VK2DOT" | ||
| - | chat with the sysop of that node, if he is available. This | ||
| - | is not related to the "sysop chat" channel on the chat | ||
| - | server. It is the NetRom equivalent of the TTYLINK command, | ||
| - | and this form is identical to the NTTY command. | ||
| - | |||
| - | The sysop of the target node has 90 seconds to respond. At | ||
| - | any point during or after the 90 seconds, the caller has the | ||
| - | option to leave a short one-line message (160 chars max) or | ||
| - | to abort the call. Messages are saved into the sysop' | ||
| - | |||
| - | If the sysop takes more than 90 seconds to respond, and the | ||
| - | user has not disconnected, | ||
| - | "talk < | ||
| - | the user. | ||
| - | |||
| - | </ | ||
| - | TALK 21 - Initiate chat with session 21 on this node | ||
| - | TALK KIDDER - initiate chat with sysop of KIDDER node | ||
| - | |||
| - | </ | ||
| - | Sysops may interrupt users' command sessions, but may not | ||
| - | interrupt established circuits, because that might damage | ||
| - | the data being sent or received by the user. | ||
| - | |||
| - | The "TALK < | ||
| - | node is running a recent version of XRouter. Other types of | ||
| - | node will not (yet) respond to the request. | ||
| - | |||
| - | </ | ||
| - | NTTY(1) | ||
| - | YELL(1) | ||
| - | TTYLINK(1) -- Keyboard chat with another TCP/IP system. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TCP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TCP -- TCP status / configuration commands. | ||
| - | |||
| - | </ | ||
| - | TC[p] C[ache] L[ife] [secs] | ||
| - | TC[p] C[ache] SI[ze] [slots] | ||
| - | TC[p] C[ache] S[tatus] | ||
| - | TC[p] L[isteners] | ||
| - | TC[p] R[eset] < | ||
| - | TC[p] S[tatus] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The TCP command is used to display or modify various | ||
| - | settings in XRouter' | ||
| - | |||
| - | </ | ||
| - | "TC[p] C[ache] L[ife] [secs]" | ||
| - | the SYN cache lifetime. The default is 10 seconds. | ||
| - | |||
| - | "TC[p] C[ache] SI[ze] [slots]" | ||
| - | the size of the SYN cache. The default is 1000 slots. The | ||
| - | maximum is 9999 slots, which together with a 10 second | ||
| - | lifetime would cope with 999 SYNs per second. | ||
| - | |||
| - | "TC[p] C[ache] S[tatus]" | ||
| - | of the SYN cache. | ||
| - | |||
| - | "TCP L[isteners]" | ||
| - | numbers for the listener (server) sockets that XRouter is | ||
| - | using on both its own stack and the operating system' | ||
| - | An IP address of 0.0.0.0 indicates that the socket is | ||
| - | listening on all of XRouter' | ||
| - | |||
| - | "TCP R[eset] < | ||
| - | whose socket number is specified by < | ||
| - | typically be used to close a malicious or " | ||
| - | The socket number may be obtained by the STATUS subcommand. | ||
| - | |||
| - | "TCP S[tatus]" | ||
| - | connections. | ||
| - | |||
| - | The display shows the socket number, the remote and local | ||
| - | addresses, the state, and the amount of queued data in bytes. | ||
| - | The states are as follows (see RFC793): | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | </ | ||
| - | UDP(1) -- Display UDP status | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TELNET.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TELNET -- Establish a TCP " | ||
| - | |||
| - | </ | ||
| - | TELNET < | ||
| - | |||
| - | </ | ||
| - | The TELNET command allows users to " | ||
| - | systems, using a " | ||
| - | to be running TCP/IP as XRouter does all the TCP/IP <> AX25 | ||
| - | translation. | ||
| - | |||
| - | </ | ||
| - | The first argument < | ||
| - | hostname or the IP number of the target system. If the | ||
| - | hostname doesn' | ||
| - | suffix specified in XROUTER.CFG (default .ampr.org.) is | ||
| - | appended. | ||
| - | |||
| - | The optional < | ||
| - | on the target host. If not supplied, the default is 23, i.e. | ||
| - | the " | ||
| - | (Telnet), 25 (SMTP), and 87 (TTYLINK). | ||
| - | |||
| - | </ | ||
| - | TELNET 44.131.90.6 21 | ||
| - | TELNET gb7lgs.ampr.org | ||
| - | TELNET gb7pzt 25 Connect to SMTP server at gb7pzt | ||
| - | |||
| - | </ | ||
| - | This command will only work if XRouter has an IP address | ||
| - | and IP routing has been defined. | ||
| - | XRouter also needs to be connected to an IP-capable network! | ||
| - | |||
| - | </ | ||
| - | Specifying target hosts by their IP addresses will often | ||
| - | result in faster connection if the hostname is not in | ||
| - | domain.sys, as it will not have to wait for DNS resolution. | ||
| - | |||
| - | </ | ||
| - | All users except " | ||
| - | |||
| - | </ | ||
| - | PING(1) | ||
| - | TELNETPORT(7) -- TCP Port for Telnet Access | ||
| - | | ||
| - | </ | ||
| - | ---- | ||
| - | =====TIME.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TIME -- Show time at any XRouter / Set time here. | ||
| - | |||
| - | </ | ||
| - | TI[me] [node | hh:mm] | ||
| - | |||
| - | </ | ||
| - | Available to all users, but time setting is sysop-only. | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied, this command displays the current | ||
| - | setting of the PC clock. | ||
| - | |||
| - | If an argument of the form HH:MM is used, it sets the PC | ||
| - | clock to the specified time. (24 hour format) | ||
| - | |||
| - | If the argument is the callsign or alias of an XRouter which | ||
| - | is in the nodes table, the local date and time at that node | ||
| - | is shown. This may involve a connection to the target node's | ||
| - | time service, so please allow time for the response. | ||
| - | |||
| - | </ | ||
| - | TIME - Display current setting of PC clock. | ||
| - | TIME 23:06 - Sets PC time to 23:06 | ||
| - | TI G8PZT - Display time at G8PZT node | ||
| - | |||
| - | </ | ||
| - | DATE(1) | ||
| - | TSYNC(1) -- Synchronise with an Internet time standard | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TNC.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TNC -- Control TNC-style peripherals. | ||
| - | |||
| - | </ | ||
| - | TN[c] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The " | ||
| - | e.g. real TNC's or any applications or devices that use | ||
| - | plain text commands. | ||
| - | |||
| - | The < | ||
| - | PROTOCOL is " | ||
| - | |||
| - | After issuing the TNC command, the session talks directly to | ||
| - | the peripheral in plain text mode. This could be used for | ||
| - | example to interface with an ARDOP TNC. | ||
| - | |||
| - | </ | ||
| - | PROTOCOL(7) -- Protocol Used on INTERFACE. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TRACERT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TRACERT -- Trace Route to TCP/IP host. | ||
| - | |||
| - | </ | ||
| - | TR[acert] < | ||
| - | |||
| - | </ | ||
| - | The TRACERT command is a diagnostic tool for displaying the | ||
| - | route to an Internet Protocol host, and measuring the transit | ||
| - | delays of packets at each step. | ||
| - | |||
| - | It uses the replies from a series of ICMP echo requests to | ||
| - | produce a list of the routers that the packets have passed | ||
| - | through. | ||
| - | |||
| - | 3 attempts are made at each hop, thus for each hop, 3 round | ||
| - | trip times are displayed, along with the IP address of the | ||
| - | router at that hop. The 3 times indicate the consistency of | ||
| - | the route. If no response is received within the timeout | ||
| - | period, a " | ||
| - | |||
| - | </ | ||
| - | < | ||
| - | |||
| - | [maxhops] is the maximum number of hops to trace (default 30). | ||
| - | |||
| - | [maxwait] is the maximum time to wait for a reply from each | ||
| - | router. The default is 4 seconds. | ||
| - | |||
| - | The only required parameter is < | ||
| - | doesn' | ||
| - | specified in XROUTER.CFG (default .ampr.org.) is appended. | ||
| - | |||
| - | Entering TRACERT without any arguments displays a syntax | ||
| - | reminder. | ||
| - | |||
| - | </ | ||
| - | TR bbc.co.uk | ||
| - | TR 44.141.91.2 10 - Trace 44.131.91.2 to a max of 10 hops. | ||
| - | TR g8pzt 5 20 - Trace g8pzt.ampr.org, | ||
| - | |||
| - | G8PZT-12: | ||
| - | max. 5 hops | ||
| - | |||
| - | | ||
| - | | ||
| - | | ||
| - | |||
| - | Trace complete. | ||
| - | |||
| - | </ | ||
| - | TRACERT relies on ICMP messages, and therefore requires that | ||
| - | ICMP is correctly routed via front-end routers and firewalls | ||
| - | etc. It will fail to produce a response from systems that are | ||
| - | " | ||
| - | systems are indicated by "* * * Request timed out" lines. | ||
| - | |||
| - | The Traceroute function will not work unless XRouter has an | ||
| - | IP address, and IP routing has been correctly set up. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | IP(1) -- IP Configuration Commands | ||
| - | PING(1) | ||
| - | STEALTH(9) -- TCP/IP Stealth Issues | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TSYNC.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TSYNC -- Synchronise Time using Internet Time Server. | ||
| - | |||
| - | </ | ||
| - | TS[ync] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The TSYNC command causes XRouter to synchronise the PC time | ||
| - | with an Internet TIME server. | ||
| - | |||
| - | It is doubtful whether this relic from DOS-XRouter has | ||
| - | any purpose on a Windows or Linux platform, since those | ||
| - | operating systems contain tools to do the same job more | ||
| - | effectively. | ||
| - | |||
| - | </ | ||
| - | The only required option is the IP address of an RFC-868 TIME | ||
| - | server. Hostnames are not acepted in this field. A list of | ||
| - | TIME servers is available on the nist.gov web site. | ||
| - | |||
| - | If no options are supplied, a syntax reminder is displayed. | ||
| - | |||
| - | </ | ||
| - | TS 129.6.15.28 | ||
| - | |||
| - | </ | ||
| - | This command may set your PC clock to the wrong timezone if | ||
| - | the TZ environment variable is not set correctly. | ||
| - | |||
| - | NIST plans to phase out RFC-868 TIME servers in April 2013, | ||
| - | in favour of NTP (Network Time Protocol) servers, although | ||
| - | there may still be a few servers operated by other | ||
| - | organisations. | ||
| - | |||
| - | </ | ||
| - | DATE(1) -- Set PC Date. | ||
| - | TIME(1) -- Set PC Time. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TTYLINK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TTYLINK -- Keyboard To Keyboard Chat | ||
| - | |||
| - | </ | ||
| - | TT[YLINK] < | ||
| - | |||
| - | </ | ||
| - | The TTYLINK commmand allows users of any type (i.e. AX25, | ||
| - | console, wire link, TCP/IP) to chat directly to TCP/ | ||
| - | users. | ||
| - | |||
| - | This is similar to the TELNET comand, except that the default | ||
| - | port number is 87, which is reserved for keyboard to keyboard | ||
| - | chat. Other port numbers may be specified. | ||
| - | |||
| - | This command is deprecated, and may be removed from future | ||
| - | versions. | ||
| - | |||
| - | </ | ||
| - | The first argument < | ||
| - | hostname or the IP number of the target system. If the | ||
| - | hostname doesn' | ||
| - | suffix specified in XROUTER.CFG (default .ampr.org.) is | ||
| - | appended. | ||
| - | |||
| - | The optional [port] parameter specifies the desired service | ||
| - | on the target host. If not supplied, the default is 87. | ||
| - | |||
| - | </ | ||
| - | TTY 44.131.91.4 | ||
| - | TTY g8pzt - form if hostname is in domain.sys | ||
| - | |||
| - | </ | ||
| - | In order for this command to work, XRouter must have an IP | ||
| - | address and have IP routing defined. | ||
| - | |||
| - | </ | ||
| - | If the target hostname is not known to XRouter, it will be | ||
| - | more efficient to specify the target as an IP address, since | ||
| - | this will not require DNS resolution. | ||
| - | |||
| - | </ | ||
| - | All users except guests. | ||
| - | |||
| - | </ | ||
| - | PING(1) | ||
| - | TELNET(1) -- Make TCP connection | ||
| - | TTYLINK(9) -- About TTYLINK. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXDELAY.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXDELAY -- Display / Set Port Transmit Delay. | ||
| - | |||
| - | </ | ||
| - | TXD[ELAY] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The TXDELAY command allows the value of the transmit | ||
| - | delay for a port to be displayed or altered. This is the | ||
| - | interval between the transmitter being activated and the | ||
| - | start of a transmitted packet. (see NOTES). | ||
| - | |||
| - | Any changes made by this command override the settings | ||
| - | specified in the PORT sections of XROUTER.CFG, | ||
| - | force only until XRouter restarts. | ||
| - | |||
| - | On KISS TNC's, you should allow up to 5 minutes for any new | ||
| - | setting to take effect. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies the | ||
| - | port number, and the second specifies the new value for the | ||
| - | parameter in milliseconds. | ||
| - | |||
| - | </ | ||
| - | TXDELAY 3 - Display current setting for port 3 | ||
| - | TXDELAY 3 300 - Set port 3 txdelay to 300 millisecs | ||
| - | |||
| - | </ | ||
| - | TXDELAY is the interval between transmitter activation | ||
| - | and the start of a transmitted packet. | ||
| - | RF to reach its full value, and for the TX audio circuits to | ||
| - | stabilise. | ||
| - | or more) to allow the synthesiser to swing between RX and TX | ||
| - | frequencies, | ||
| - | to stabilise while oversized electrolytics charge up. | ||
| - | |||
| - | One factor which is often overlooked is the other end' | ||
| - | receiver. | ||
| - | if the rig has just been transmitting it may take a while to | ||
| - | stabilise back to receiving, especially with synthesised rigs. | ||
| - | | ||
| - | If your txd is too short, you will be sending replies before | ||
| - | the other end is ready to hear you, and unnecessary retries | ||
| - | will result. | ||
| - | |||
| - | 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! | ||
| - | |||
| - | </ | ||
| - | TXDELAY(7) | ||
| - | TXTAIL(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXOK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | TXOK -- Display / Set "ok to tx" for a port. | ||
| - | |||
| - | </ | ||
| - | TXO[k] < | ||
| - | |||
| - | </ | ||
| - | Displays the current TXOK flag setting for a port, and allows | ||
| - | it to be changed. | ||
| - | transmitter is allowed to key up, and whether or not the | ||
| - | receiver is enabled. | ||
| - | |||
| - | If two numeric arguments are supplied, the TXOK flag is set | ||
| - | to the second argument, otherwise the current setting for | ||
| - | the specified port is displayed. | ||
| - | |||
| - | Values are: 0 = TX disabled, RX enabled | ||
| - | 1 = TX enabled, | ||
| - | 2 = TX disabled, RX disabled | ||
| - | 3 = TX enabled, | ||
| - | |||
| - | State 2 would typically be used to disable all traffic on a | ||
| - | port, to time out troublesome connections, | ||
| - | |||
| - | By default, all ports have this flag set to 1 (TX and RX | ||
| - | enabled). | ||
| - | |||
| - | Modified settings remain in force until changed or system is | ||
| - | restarted. | ||
| - | |||
| - | </ | ||
| - | TXOK 3 - Display current setting for port 3 | ||
| - | TXOK 3 0 - Stop port 3 transmissions. | ||
| - | |||
| - | </ | ||
| - | Requires SYSOP status. | ||
| - | |||
| - | </ | ||
| - | It should be obvious, but setting TXOK=0 for the port you are | ||
| - | using to send commands, will cause you to lose control of the | ||
| - | node! | ||
| - | |||
| - | Setting TXOK=0 does not actually disable the transmitter | ||
| - | itself, it merely prevents any frames being sent to the TNC, | ||
| - | so if the latter has a built-in CWID, it will still key up | ||
| - | the TX so send the CWID. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXPORT.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXPORT -- Display / Set Port to Transmit On. | ||
| - | |||
| - | </ | ||
| - | TXP[ort] < | ||
| - | |||
| - | </ | ||
| - | Sysop only. | ||
| - | |||
| - | </ | ||
| - | Displays or specifies the port upon which outgoing frames | ||
| - | should be transmitted. This would typically be used where | ||
| - | there are several ports (e.g. multiple receivers) sharing a | ||
| - | common transmitter. | ||
| - | |||
| - | The minimum abbreviation of this command is TXP. | ||
| - | |||
| - | </ | ||
| - | If " | ||
| - | displayed. | ||
| - | |||
| - | If " | ||
| - | received and transmitted on the same port. | ||
| - | |||
| - | If " | ||
| - | normally be transmitted on < | ||
| - | " | ||
| - | |||
| - | </ | ||
| - | TXP 3 5 - Receive on port 3 and transmit on port 5 | ||
| - | |||
| - | </ | ||
| - | TXPORT(7) -- Port to Transmit On. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====TXTAIL.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | TXTAIL -- Display / Set Transmit Turnoff Delay. | ||
| - | |||
| - | </ | ||
| - | TXT[AIL] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The TXTAIL command allows the value of the transmit turnoff | ||
| - | delay for a port to be displayed or altered. | ||
| - | parameter used only by KISS TNC's, and you should refer to the | ||
| - | TNC documentation for an explanation. The default is 100 ms. | ||
| - | |||
| - | Any changes made by this command override the settings | ||
| - | specified in the PORT sections of XROUTER.CFG, | ||
| - | force only until XRouter restarts. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies | ||
| - | the port number, and the second specifies the new value for | ||
| - | the parameter in milliseconds. | ||
| - | |||
| - | </ | ||
| - | TXTAIL 3 - Display current setting for port 3 | ||
| - | TXDELAY 3 100 - Set port 3 txtail to 100 millisecs | ||
| - | |||
| - | </ | ||
| - | After modifying this value, you may have to wait up to 5 | ||
| - | minutes for it to take effect. | ||
| - | |||
| - | </ | ||
| - | TXDELAY(1) | ||
| - | TXTAIL(7) | ||
| - | XROUTER.CFG(8) -- Main Configuration File. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UDPLOCAL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | UDPLOCAL -- Display / Set a port's UDPLOCAL parameter. | ||
| - | |||
| - | </ | ||
| - | UDPLOCAL < | ||
| - | |||
| - | </ | ||
| - | The UDPLOCAL command allows the UDP service number (often | ||
| - | confusingly called a " | ||
| - | link to be displayed or altered. | ||
| - | |||
| - | This number must match the link partner' | ||
| - | destination service number in the frames from him to you. | ||
| - | |||
| - | If not specified, UDPLOCAL defaults to 93. | ||
| - | |||
| - | It is usually specified within a PORT configuration block in | ||
| - | the XROUTER.CFG file, but this command allows it to be | ||
| - | changed on the fly, without needing to take XRouter off line. | ||
| - | |||
| - | Please see the manual section on AXUDP for more information. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies | ||
| - | the port number, and the second specifies the new value for | ||
| - | the parameter. | ||
| - | changed, or until XRouter is restarted, in which case the | ||
| - | value specified in the XROUTER.CFG file is reapplied. | ||
| - | |||
| - | </ | ||
| - | UDPLOCAL 3 - Display current UDPLOCAL for port 3 | ||
| - | UDPLOCAL 3 9393 - Set port 3 UDPLOCAL to 9393 | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | AXUDP(9) | ||
| - | UDPLOCAL(7) | ||
| - | UDPREMOTE(1) | ||
| - | XROUTER.CFG(8) -- Main Configuration File | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UDP.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | UDP -- UDP status and statistics commands. | ||
| - | |||
| - | </ | ||
| - | UD[p] S[ockets] | ||
| - | UD[p} ST[ats] | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The UDP command is used to display the active UDP sockets, | ||
| - | their status, and UDP layer statistics. | ||
| - | |||
| - | </ | ||
| - | UD[p] S[ockets] display the active UDP sockets, along with | ||
| - | their local addresses and port numbers, the stack they are | ||
| - | using, and the number of frames queued for reception. For | ||
| - | example: | ||
| - | |||
| - | | ||
| - | 7338e0 | ||
| - | 733b78 | ||
| - | 737050 | ||
| - | 737768 | ||
| - | 731dc0 | ||
| - | |||
| - | " | ||
| - | on the operating system' | ||
| - | |||
| - | |||
| - | UD[p} ST[ats] produces a display like this: | ||
| - | |||
| - | 19 Segments sent, 921 bytes | ||
| - | 2178 Segments rcvd, 177583 bytes | ||
| - | 0 Malformed segments rcvd | ||
| - | 0 Segments rcvd with bad checksum | ||
| - | 2160 Unwanted segments rcvd | ||
| - | 0 Broadcast segments | ||
| - | 0 Segments ignored from banned IP's | ||
| - | 0 Attempted Fraggle attacks | ||
| - | |||
| - | The fields are largely self-explanatory. | ||
| - | |||
| - | " | ||
| - | a valid UDP header. | ||
| - | |||
| - | " | ||
| - | which there was no receive socket. | ||
| - | |||
| - | " | ||
| - | destination IP was the subnet broadcast address. | ||
| - | |||
| - | A " | ||
| - | amour of data with spoofed source addresses to the ECHO (7) | ||
| - | or CHARGEN (19) ports. XRouter does not implement those | ||
| - | services on UDP, but keeps records so that attacks can be | ||
| - | detected. | ||
| - | |||
| - | </ | ||
| - | TCP(1) -- Display TCP status | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UDPREMOTE.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | UDPREMOTE -- Display / Set a port's UDPREMOTE parameter. | ||
| - | |||
| - | </ | ||
| - | UDPREMOTE < | ||
| - | |||
| - | </ | ||
| - | The UDPREMOTE command allows the UDP service number (often | ||
| - | confusingly called a " | ||
| - | link to be displayed or altered. | ||
| - | |||
| - | This is the UDP destination number in the AXUDP frames from | ||
| - | you to your link partner. It must match the link partner' | ||
| - | UDPLOCAL, otherwise the link will not function. | ||
| - | |||
| - | If not specified, UDPREMOTE defaults to 93. It is only used | ||
| - | on AXUDP ports. | ||
| - | |||
| - | It is usually specified within a PORT configuration block in | ||
| - | the XROUTER.CFG file, but this command allows it to be | ||
| - | changed on the fly, without needing to take XRouter off line. | ||
| - | |||
| - | Please see the manual section on AXUDP for more information. | ||
| - | |||
| - | </ | ||
| - | If a single numeric argument is supplied, the current value | ||
| - | for that port number is displayed. | ||
| - | |||
| - | If two numeric arguments are supplied, the first specifies | ||
| - | the PORT number, and the second specifies the new value for | ||
| - | the parameter. | ||
| - | changed, or until XRouter is restarted, in which case the | ||
| - | value specified in the XROUTER.CFG file is reapplied. | ||
| - | |||
| - | </ | ||
| - | UDPREMOTE 3 - Display UDPREMOTE setting for port 3 | ||
| - | UDPREMOTE 3 9393 - Set port 3 UDPREMOTE to 9393 | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | AXUDP(9) | ||
| - | UDPLOCAL(1) | ||
| - | UDPREMOTE(7) | ||
| - | XROUTER.CFG(8) | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====UNPROTO.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | UNPROTO -- Display / Set Path for Unproto Broadcasts. | ||
| - | |||
| - | </ | ||
| - | UN[proto] < | ||
| - | |||
| - | </ | ||
| - | Sysop only. | ||
| - | |||
| - | </ | ||
| - | Displays or modifies the destination callsign, and digipeater | ||
| - | path for " | ||
| - | |||
| - | If " | ||
| - | and digipeater callsigns) is displayed. | ||
| - | |||
| - | If " | ||
| - | specified port is changed to the new value. | ||
| - | |||
| - | The " | ||
| - | |||
| - | < | ||
| - | |||
| - | where < | ||
| - | [digicall] are optional digipeater callsigns. | ||
| - | |||
| - | The minimum abbreviation of this command is UN. | ||
| - | |||
| - | </ | ||
| - | UNP 3 - Display current UNPROTO for port 3 | ||
| - | UNP 3 CQ, | ||
| - | |||
| - | </ | ||
| - | UNPROTO(7) | ||
| - | APRSPATH(7) -- Default Digipeater Path for APRS. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====USERS.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | USERS -- Show Who is Using XRouter. | ||
| - | |||
| - | </ | ||
| - | U[sers] | ||
| - | |||
| - | </ | ||
| - | The USERS command displays the ISO layer 7 sessions which | ||
| - | originate or terminate at XRouter. | ||
| - | traffic" | ||
| - | |||
| - | No arguments are required, and a typical response includes | ||
| - | the following fields: | ||
| - | |||
| - | Session | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | |||
| - | " | ||
| - | the session. | ||
| - | |||
| - | " | ||
| - | |||
| - | AGWH - AGW Host app APPL - Uplink to app | ||
| - | APRS - APRS Server | ||
| - | CHAT - Chat session | ||
| - | CONS - Console | ||
| - | DEDH - WA8DED Host app DSCD - Discard server | ||
| - | DXSV - DX Server | ||
| - | FING - Finger server | ||
| - | FTPS - FTP Server | ||
| - | HLIB - Hamlib | ||
| - | HTRM - HTTP Terminal | ||
| - | INFO - Info server | ||
| - | MQTT - MQTT Server | ||
| - | NTPX - NetRom/TCP Proxy NTRM - Netrom | ||
| - | PMS - Personal Msg System PRXY - Proxy | ||
| - | PSTN - Dial-in | ||
| - | RHPC - RHP Control Sess RHPP - RHP SeqPacket Socket | ||
| - | RHPS - RHP Stream Socket | ||
| - | RLOG - Remote Login SMS - Short Message | ||
| - | Sock - Socket app SOKH - Uplink to Socket host | ||
| - | SOKS - SOCKS Proxy Teln - Telnet | ||
| - | TPXY - Telnet Proxy TTY - Serial TTY | ||
| - | TTYL - TTYLink | ||
| - | |||
| - | " | ||
| - | |||
| - | CON - Console | ||
| - | TTY - Remote console | ||
| - | L2 - AX25 level 2 RHP - Remote Host Protocol app | ||
| - | L4 - NetRom level 4 DED - DEDHOST application | ||
| - | TRM - HTTP Terminal | ||
| - | |||
| - | " | ||
| - | user. There may be another user shown on the | ||
| - | downlink side. | ||
| - | |||
| - | In this context UPLINK is a connection from a user (who may | ||
| - | be located at another node) to the router, and DOWNLINK is a | ||
| - | connection from the router to a user. The combination of both | ||
| - | is called a CIRCUIT. | ||
| - | |||
| - | Established circuits are shown by <--> and circuits being set | ||
| - | up are shown thus: <~~>. | ||
| - | |||
| - | </ | ||
| - | Unlike the equivalent BPQ command, this does not show the | ||
| - | version number - use the VERSION command for that, or buffer | ||
| - | count (this system does not use fixed buffers). | ||
| - | |||
| - | </ | ||
| - | J(1) -- Show Recent Sessions | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====VERSION.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | VERSION -- Display software version and author. | ||
| - | |||
| - | </ | ||
| - | V[ersion] | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The VERSION command, which takes no arguments, displays the | ||
| - | software version, author and compilation date. | ||
| - | |||
| - | This information may be needed when upgrading to later | ||
| - | versions of the program or its files. | ||
| - | |||
| - | Please specify the version when reporting bugs. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WAIT.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | WAIT -- Pause Execution. | ||
| - | |||
| - | </ | ||
| - | WA[it] < | ||
| - | |||
| - | </ | ||
| - | Sysop-only. | ||
| - | |||
| - | </ | ||
| - | The WAIT command is intended for use only in BOOTCMDS.SYS. | ||
| - | |||
| - | It causes execution to pause for the specified time. This | ||
| - | can be used between commands that need time to execute, such | ||
| - | as the setting up of tunnel interfaces. | ||
| - | |||
| - | If the argument to WAIT is less than 60, it is treated as | ||
| - | SECONDS, otherwise it is treated as milliseconds. | ||
| - | |||
| - | The following example shows 300ms pauses betwen Linux shell | ||
| - | commands when setting up a tunnel interface. The sequence | ||
| - | does not work if the pauses are removed. | ||
| - | |||
| - | # BOOTCMDS.SYS | ||
| - | # | ||
| - | # For setting up tunnels: | ||
| - | # Assign the address 192.168.0.98 to the Linux end of tun99: | ||
| - | shell ip address add 192.168.0.98 dev tun99 | ||
| - | # | ||
| - | wait 300 | ||
| - | # | ||
| - | # Tell Linux that 192.168.0.99 is on the other end of tun99: | ||
| - | shell ifconfig tun99 dstaddr 192.168.0.99 | ||
| - | # | ||
| - | wait 300 | ||
| - | # | ||
| - | # Bring up the Linux end of the interface: | ||
| - | shell ip link set dev tun99 up | ||
| - | |||
| - | </ | ||
| - | SHELL(1) | ||
| - | BOOTCMDS.SYS(8) -- Commands to Execute at Bootup | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WALL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | WALL -- Access Message Wall(s) | ||
| - | |||
| - | </ | ||
| - | W[all] [nodecall | nodealias] | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The WALL command connects the user either to this node's | ||
| - | message " | ||
| - | |||
| - | The " | ||
| - | can leave short text messages, comments, suggestions, | ||
| - | reminders, observations etc. Think of it as a text-only | ||
| - | version of the old Facebook wall. | ||
| - | |||
| - | Unlike a BBS, wall messages are not forwarded to other systems, | ||
| - | and they do not expire. They have no " | ||
| - | they are just a string of text, like a tweet. | ||
| - | |||
| - | The wall may also be operated via the sysop' | ||
| - | via MQTT, and via REST. | ||
| - | |||
| - | The WALLFLAGS directive enables or disables the wall, and | ||
| - | controls whether the sysop is notified (via the PMS) of new | ||
| - | posts. It also controls whether postss and replies are | ||
| - | published to the MQTT broker. | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied to the WALL commmand, the user is | ||
| - | connected to the local wall. | ||
| - | |||
| - | If the argument is the nodecall or alias of another XRouter, | ||
| - | which is in the nodes table, the user is connected to the | ||
| - | wall of that node instead. | ||
| - | |||
| - | After the WALL command is issued, the user is shown the most | ||
| - | recent 5 messages in reverse chronological order, plus a menu | ||
| - | with the following options: | ||
| - | |||
| - | H[elp] | ||
| - | |||
| - | L[ist] | ||
| - | | ||
| - | i.e. the most recent at the top. | ||
| - | |||
| - | O[lder] | ||
| - | |||
| - | N[ewer] | ||
| - | |||
| - | W[rite] | ||
| - | | ||
| - | | ||
| - | |||
| - | D[elete] Deletes a message that the user has just entered. | ||
| - | The user cannot delete other people' | ||
| - | sysop can do that. | ||
| - | |||
| - | Q[uit] | ||
| - | |||
| - | </ | ||
| - | WALL -- Connect to the wall on this node | ||
| - | WALL G8PZT -- Connect to the wall on G8PZT node. | ||
| - | |||
| - | </ | ||
| - | BLOG(1) | ||
| - | MQTT-WALL(9) -- MQTT Interface to Message Wall. | ||
| - | PMS(1) | ||
| - | WALLFLAGS(7) -- Options For Message Wall. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WATCH.MAN===== | ||
| - | < | ||
| - | |||
| - | </ | ||
| - | WATCH -- Watch Packet Traffic on Port(s). | ||
| - | |||
| - | </ | ||
| - | WAT[ch] port[+port..] | [OFF] | ||
| - | |||
| - | </ | ||
| - | The WATCH command, which can be abbreviated to " | ||
| - | any user to monitor packet traffic on one or more of the | ||
| - | node's ports. | ||
| - | |||
| - | For security reasons, non-sysops are only allowed to watch | ||
| - | RADIO ports. The user can not watch the port upon which they | ||
| - | are uplinked to the node. | ||
| - | |||
| - | All the normal node commands are available whilst in " | ||
| - | mode. If the amount of monitored traffic exceeds the capacity | ||
| - | of the user's uplink, some traffic may be discarded. | ||
| - | |||
| - | </ | ||
| - | To watch a single port, use WATCH < | ||
| - | |||
| - | To watch multiple ports, either specify their numbers in a | ||
| - | string separated by ' | ||
| - | the command more than once. | ||
| - | |||
| - | Use "WATCH OFF" to terminate traffic monitoring. | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | LISTEN(1) -- Listen For Incoming Connections. | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====WX.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | WX -- Display Weather Information. | ||
| - | |||
| - | </ | ||
| - | WX [callsign | LOCAL] | ||
| - | |||
| - | </ | ||
| - | All users | ||
| - | |||
| - | </ | ||
| - | The WX command is used to display a list of up to 5 local | ||
| - | APRS weather stations, and to display a weather summary from | ||
| - | specified stations. | ||
| - | |||
| - | The information displayed includes: date and time of reading, | ||
| - | distance and direction of server, pressure, wind speed and | ||
| - | direction, gust speed, temperature, | ||
| - | |||
| - | </ | ||
| - | If no argument is supplied, the callsigns of the available | ||
| - | weather stations (if any) are displayed. | ||
| - | |||
| - | If the argument is the callsign of one of the stations in the | ||
| - | list, the weather summary from that station will be displayed. | ||
| - | |||
| - | However, if [callsign] is not in the list of stations | ||
| - | returned by WX", and it matches the callsign or alias of an | ||
| - | XRouter in the nodes table, a connection to that node's | ||
| - | weather service is attempted. If successful, the weather | ||
| - | information is returned, like this: | ||
| - | |||
| - | wx g8pzt | ||
| - | G8PZT-1: | ||
| - | G8PZT-1: | ||
| - | |||
| - | Observed: Mon 17 May 2021 06:01:23 +0001 | ||
| - | Pressure: 1007.2 mB | ||
| - | Temperature: | ||
| - | Humidity: 67 % | ||
| - | Wind: 23 mph | ||
| - | Direction: 178 deg | ||
| - | Gust: 31 mph | ||
| - | Rain-24h: 24.7 mm | ||
| - | Rain-Today: 19.7 mm | ||
| - | Rain-1h: 3.2 mm | ||
| - | |||
| - | G8PZT-1: | ||
| - | |||
| - | The special case "WX LOCAL" returns the local WX information, | ||
| - | if available. | ||
| - | |||
| - | </ | ||
| - | WX - Display local APRS weather stations | ||
| - | WX G6GUH-3 | ||
| - | |||
| - | </ | ||
| - | The collection of weather data requires at least one APRS RF | ||
| - | port, plus a weather station within range. Failing that, | ||
| - | weather data will be collected if the IGATE daemon is running | ||
| - | and connected to a suitable APRS server. | ||
| - | can be imported every minute from a file. | ||
| - | |||
| - | </ | ||
| - | WX-SVC(9) -- NetRomX Weather Service | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====XLINK.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | XLINK -- Establish a Temporary SLIP / PPP Interlink | ||
| - | |||
| - | </ | ||
| - | X[link] <SLIP | PPP> | ||
| - | |||
| - | </ | ||
| - | The XLINK command switches a dialled-in connection into the | ||
| - | specified mode, allowing TCP/IP operations to be conducted | ||
| - | between the caller and XRouter. | ||
| - | |||
| - | The temporary interlink persists until the line is | ||
| - | disconnected or, in the case of PPP, an inactivity timeout. | ||
| - | |||
| - | </ | ||
| - | XLINK PPP | ||
| - | |||
| - | </ | ||
| - | Temporary SLIP interlinks require no configuration. Temporary | ||
| - | PPP interlinks may optionally be configured by including PPP | ||
| - | commands in a PPPHOST.n file, where n is the port number. | ||
| - | |||
| - | </ | ||
| - | The command is available to all users, but is only actioned | ||
| - | on MODEM (dial-in) ports. | ||
| - | |||
| - | </ | ||
| - | PPP(1) -- PPP commands | ||
| - | |||
| - | </ | ||
| - | ---- | ||
| - | =====YELL.MAN===== | ||
| - | < | ||
| - | </ | ||
| - | YELL -- Yell for sysop | ||
| - | |||
| - | </ | ||
| - | Y[ell] | ||
| - | |||
| - | </ | ||
| - | All users. | ||
| - | |||
| - | </ | ||
| - | The YELL command attempts to attract the attention of the | ||
| - | sysop by making a distinctive sound on the console and | ||
| - | displaying a message. | ||
| - | break in on your session for a one-to-one chat. | ||
| - | |||
| - | </ | ||
| - | A yell may not always be successful because (a) the sound may | ||
| - | be disabled during unsociable hours, (b) the sysop may be | ||
| - | away from the console or busy talking to someone else, (c) | ||
| - | there may not even be a loudspeaker in the computer, or (d) | ||
| - | the node may be located on a remote hilltop or in someone' | ||
| - | garage. | ||
| - | |||
| - | </ | ||
| - | TALK(1) -- Talk to a user | ||
| - | |||
| - | </ | ||
| - | ---- | ||
packet/xrpi/manpages/section1.1745063392.txt.gz · Last modified: 2025/04/19 11:49 by m0mzf