This document is taken in the most part from the TheNET X1J Release 4
documentation file overview.txt. Although it is available with every X1JR4
distribution disk, it is being repeated here as an aid to the person reviewing
the NEDA Recommended Parameters document. Also there are additional explanatory
notes and adaptations reflecting use in the NEDA Network Plan. This document is
a companion to a similar document reviewing the definition of PARM parameters.
The MODE command is similar to the PARMS command, and includes the new syntax described below.
It allows a number of other features of the software to be configured remotely. It removes the need for most of the host mode <escape> commands used in earlier TheNET implementations.
The following MODE parameters are explained:
In operation, the MODE command behaves just like the PARMS
command.
The MODE parameters are as follows :
This parameter controls the 'host' mode. This is the mode of operation of
the RS232 port when pin 23 (on a DB-25 connector - pin 9 for a DE-9 connector)
is 'high'.
In mode 0, the port operates as per the standard node specification. Mode 1
is designed to allow connection to hosts or modems or similar equipment that
expects a 'CD' type of signal to signify that an incoming / outgoing
connection is called for.
In mode 1, the <escape> C and <escape> D commands are disabled
and the other <escape> commands do not operate when connected. Instead,
hardware handshakes are used to control connections to and from the
TNC.
The TNC monitors pin 20 (DE-9 pin 7) to determine the state of the host,
and signals state changes to the host with pin 5 (DE-9 pin 8). When an
incoming connect request is received (by the 'c' command with no parameters or
by the 'host' command), the TNC raises pin 5 to signal the connection and
expects pin 20 to change state in response.
When the host wishes to connect to the TNC, it signals on pin 20 and the
TNC responds by changing the state of pin 5.
It handles disconnects in a similar manner. Either the node or the host may
initiate disconnects.
As this mode is experimental, changes may be made to its operation. It is designed for modems, print servers or hosts such as UNIX system TTY login drivers.
This parameter is the CWID repeat period in seconds. Valid values are 0 to
3600. 0 disables it but do not set it below 120 except to disable it.
This parameter controls the keyer speed. Specifically, it sets the number of 10 millisecond periods per dot and per inter symbol delay.
The speed of sending is 120/n, so setting n to 6 gives 20 wpm. Valid values
are 4 to 10, corresponding to speeds of 30 and 12 wpm respectively.
This parameter allows control to be exercised over which ports, node
broadcasts are sent out on. Valid settings are 0 - 3.
Value 0 disables node broadcasts.
This parameter is used to set the communications protocol used on the
crosslink (RS-232 or serial) port when pin 23(on a DB-25 or pin 9 on a DE-9
connector) is tied low. The valid values are 0, 1, 2 or 3
Mode 0 enables standard crosslink protocol while Modes 1,2 and 3 use KISS
instead of crosslink protocol.
In mode 1, KISS simply replaces the crosslink protocol.
In mode 2, packets received from the radio part, that are not intended for the node, are copied to the RS232 port in KISS mode. Similarly packets received on the RS232 port that are not intended for the node are sent to the radio port.
Mode 2 is designed to allow a KISS application and a node to share a radio without interference with each other. The point is that the PC TCP/IP system can be switched off while leaving the node running to allow others to use it.
In mode 3, all packets received on one port are copied to the other port as well as being analysed by the node.
Mode 3 is a debugging mode. One problem when faultfinding on a node is that it is impossible to see what the node is seeing on the channel without replacing the ROM. By setting this mode, it is possible to connect a KISS application to the RS232 port and observe what the node is seeing.
Mode 3 is also designed to allow a PC running AXSTATS to be connected to
the RS232 port to allow logging and analysis of channel performance from the
node itself. Note that packets initiated by the node for one port will not
get copied to the other.
These modes are not simply KISS implementations that replace the node, they
run with the node.
This parameter sets the TX keyup delay in 10's of milliseconds.
This parameter sets or clears the full duplex control flag. A value of 1
turns on the full-duplex and the DCD no longer controls the transmit. A value
of 0 turns off full- duplex.
When a crosslinked TNC is reset, it takes some time to learn about the
nodes that the other TNCs can hear. Also, nodes heard by one TNC can take 15
minutes or more to be notified by node broadcast.
In order to improve this, this parameter may be used to change the
frequency of nodes broadcasts on the RS232 port. When set to 0, the node
operates as normal. When set to a non zero value, it will broadcast the nodes
on the RS232 port at that interval. Hence setting it to 600 would cause nodes
broadcasts at 10 minute periods. The nodes broadcasts on the radio port will
continue to occur at the basic rate set by the PARMS setting. The obsolescence
count will be decremented at the basic rate, not at the faster RS232
rate.
This value controls the node broadcast algorithm used on each port. Bits
within the value set have significance as shown below.
There is a problem with the NETROM nodes broadcast algorithm when many TNCs are crosslinked on the RS232 serial port that can generate numerous "trivial" node routes. In order to address this, a variation to the algorithm has been implemented for experimental purposes. Feedback on its use is requested. Bit zero affects the HDLC port and bit 1 affects the RS232 port. When a bit is set to 1, the node broadcast algorithm is modified so that it will not rebroadcast on the same port a node heard on that port when the best quality neighbour is on that port. The author stated originally that "It makes little sense to use it on the HDLC port but what the heck, it is implemented for completeness. The only settings therefore that make sense are 0 and 2. These correspond to 'normal' and 'modified on the RS232 port' respectively. Setting it to 1 or 3 will result in some pretty weird effects."
In spite of the author's reservations, experiments have found that the alternate algroithm was in fact very useful on the radio port. Especially when digital repeaters are used, it prevents a serious problem of trivial routes through other stations on the repeater. It was useful even on normal shared ports. Experience so far has not shown any ill effects on the radio port. Therefore NEDA has been recommending that this parameter be set to 3 on all nodes with one exception.
Note: Using this alternate broadcast algorithm on the radio port will
prevent any L3/L4 routes between other nodes on the channel from using this
node in its routing. As the NEDA network recommendations call for no
node-to-node communications on a user port and reliable
This parameter sets the beacon interval in seconds. In TheNet 1.01, this
was fixed at 10 minutes ( 600 seconds ). In this version of TheNET, this
parameter may be used to change it according the prevailing license
conditions.
In TheNet 1.01, when 'connect' is given with no destination callsign, the
node attempted to connect to the local host port. In a crosslinked system,
this vanished down a black hole. In previous versions of this code, the node
attempted to connect to the station set by the HOST command, only trying the
local host port if no destination was set by HOST. With this version, the node
may be configured to connect to the station set by the BBS, DXCLUSTER or the
HOST command depending on this parameter. When zero, connect attempts will go
to the HOST station, when set to '1', it will attempt to connect to the BBS
callsign. When set to 2 it will attempt to connect to the DXCLUSTER
callsign.
This word controls the sending of help messages, with each bit of the word
controlling a separate function. Currently, only 8 bits are effective, these
being as follows :
| Binary | FUNCTION | |
|---|---|---|
| BIT | Value | |
| 0 | 1 | Whether the 'please wait, trying xxxx' operates |
| 1 | 2 | Whether all commands appear in help for sysop |
| 2 | 3 | Whether the 'goodbye' message is given |
| 3 | 8 | Whether a welcome message is enabled ( CTEXT ) |
| 4 | 16 | Whether nodes are shown as 'alias:callsign' |
| 5 | 32 | If set, TALK data is passed as 8 bit data rather than clearing the
most significant bit |
| 6 | 64 | If set, node aliases are deemed to be case sensitive |
| 7 | 128 | If set, enables the TexNet "*** LINKED to"
interface |
When bit 0 is set, and the BBS, HOST or DXcluster commands are given, then a message is sent from the node telling the user that a connect attempt is being made. This does not affect the 'connect' command itself, unless the command is given with no parameter as this is then equivalent of the BBS or HOST command.
When bit 1 is set, and if a sysop gives an incorrect command, the help screen shows all commands possible, including those currently disabled (as by definition they are not disabled for the sysop!).
When bit 2 is set, then the use of the 'bye' command will solicit a
'goodbye' message from the node.
Bit 3 switches on and off the 'CTEXT' message. When enabled, and when a CTEXT message is set, then whenever someone uplinks to the node alias, the ctext message is sent immediately on connect.
Bit 4 switches the way in which nodes are shown when the ROUTES command is used. When set to '1', nodes are shown as 'alias:callsign'. When set to 0, they are shown only as 'callsign'.
Bit 5 controls only the passing of data in TALK mode. Normally, all data sent to the node has its most significant bit cleared, to eliminate parity or similar problems. This is not ideal for those countries that use the extended character set. When this bit is set, and only when in TALK, data is passed as 8 bit data. Note that this does not apply to an initial message sent on the same line as the TALK command.
Bit 6 makes node handing case sensitive. Normally, node aliases are forced to upper case for searching in the table and for user 'connect requests'. If this bit is set, these operations will become case sensitive. This could be very confusing for users unless they are aware of it and expect it. It allows node aliases to be entered as lower case, for example in setting the node alias and in forcing routes. Don't set this bit unless it is actually needed!.
Bit 7 controls the TexNet interface. If set, the TexNet "*** LINKED to" command string handling is enabled so that a TexNet to Net/Rom interface may be effected. This is described further in section 4.4. If the bit is not set, then a TexNet "*** LINKED to" string will solicit an error message.
Add up the Binary values from the table above and that gives the value of
In certain networks (notably the American), there is a need to restrict the
propagation of local nodes. This is done by using node aliases that start with
a hash character (#) and instructing specific nodes not to broadcast routes to
nodes that start with this character. This parameter does this by enabling
each port to be individually enabled or disabled in respect to 'hash' node
broadcasts. Bit 0 controls the radio port and bit 1 controls the RS232 port.
When one of these bits is set, hash nodes will never be broadcast on that
port. Note: The propagation of hidden # nodes are handled differently in
TheNET Plus 2.xx and TheNET X1J. As the result, hidden nodes may propagate one
hop further than intended when 2.xx and X1J nodes are used together.
If this is set to '1', then the node will listen for (and accept uplinks
to) the aliases set in HOSTALIAS, DXCALIAS and BBSALIAS if they are set. If
this parameter is set to '0', or if the respective aliases are not set, it
will do nothing. If you do not use the aliases, set it to 0 to avoid wasting
processor time.
If this parameter is set to 0, the node operates as normally. If set to 1,
it operates in 'reconnect' mode. When a station connects to the switch, then
uses the BBS, HOST, DXCluster or Connect commands to connect to another
station, and then causes that remote station to disconnect them, they are
automatically reconnected to the node with a 'welcome back' message.
This parameter controls 'slime trails'. A 'slime trail' is caused when a
remote node, whose identity is not known to the node, sends a transport
connect request to the node. Subject to the settings of the port qualities,
the node may make an entry in the node table in order to reply to them. Such
entries are identified in the node list by having no alias associated with
them.
Each bit in the NoSlime parameter controls a different function. Bit 0, if set to the value of 1, causes any stations without aliases to be 'hidden' when a nodes command is given. Bit 1. if set to 1, causes the node to refuse to make s