TheNet X-1J release 4. Overview of Operation 1. INTRODUCTION This paper introduces the main features of TheNet X-1J release 4. This is an update to the previous paper on version X-1J2, and incorporates a number of changes including the following : * The buffer loss problem has been fixed * The ARP table is automatically updated from ARP requests & replies * The node maintains a second heard list of L3 Netrom nodes * that gateway through the node * The RxDeviation & Smeter ADC channels may also be used as * arbitrary inputs instead * A bug in the copying of digipeated frames in KISS mode 2 has been corrected * A defensive port flush function has been added * Link list integrity checking has been extended to check reverse links * A bug in handling of BBSALIAS, HOSTALIAS and DXCALIAS has been fixed * The USER list shows circuit choke status for patchcord connections. * The ADC* text messages may be up to 12 characters long * BBS, HOST and DXCLUSTER are cleared properly on cold start * The ACL for incoming L4 circuits checks the user callsign as well as node callsign * A default route entry may be made for the IP router * Lines that start with '#' are ignored by the switch The software is a derivative of TheNet 1.01 by NORD> commands SYSOP The following features have been added to the code An Internet Router Ability to respond to three additional aliases A CWID keyer The command processor has been extended KISS mode operation on the RS232 port HOST mode support on the RS232 port Remote configuration of all parameters Additional textual help messages Support for a 4 channel ADC used for measuring RX deviation, voltage and signal strength Other changes as detailed herein. In addition, a number of small changes have been implemented to satisfy the needs of specialist situations such as the ability to digi beacon packets. Network management in this context does not just mean 'setting parameters remotely'. It means the ability to set, read and interpret various monitors and diagnostic tools. Version X-1C included the first part of the network management, the MANAGER privilege and the AUDIT process. Version X-1D extends the auditing and statistics significantly including internal CPU monitors. Version X-1E includes most of the additions that are planned, and version 2 will complete the functions. No other release before version 2 was planned, but the need to produce a version with an IP router prompted X1J. Before moving to the joint development, I had agreed to finish off some long standing commitments hence release 2 of X-1J. Release 2 supported TexNet, an S meter, ADC commands for the other ADC channels, bug fixes, speedups and an enhanced command enable / disable syntax. 3.1 BYE or QUIT There are no parameters to these commands. When entered, they terminate the session. Both commands do the same thing. 3.2 BBS The syntax of the command is : BBS [ * | ? | callsign ] With no parameter, the command connects to a station previously specified by the sysop. Setting the BBS destination is done by the use of the BBS command with a callsign as a second parameter. Setting the BBS to allow this may only be done by a sysop. The '*' option may also only be executed by the sysop, this command clears a previously specified BBS. The '?' option ( or any text if not sysop ), prints out the current BBS station setting. If no BBS is set, the command issues an error message if it is invoked with no other parameters. The idea of this command is that, like with the 'BBS' command of the 'BPQ software, a user may connect to the local BBS from the node. The BBS, HOST and DXCLUSTER commands work by copying the callsign into a buffer. The copy operation does not compress the SSID into a single byte however, so a callsign such as KA2DEW-15 would occupy 9 bytes. I had the buffers set to 8 bytes length max in versions previous to X-1J release 2. Sorry. 3.3 HOST The syntax of the command is : HOST [ * | ? | callsign ] This command is very similar to the 'BBS' command. It allows connection to a local host, BBS or other server. The difference however, is that as long as the TNC is not in 'crosslink' mode ( i.e. pin 23 on the RS232 port is high ), and if a callsign is not set, the 'host' command connects to the local port. The idea of this command is that, like with the 'BBS' command of the 'BPQ software, a user may connect to the local BBS, another node or server from this node. For example, if a print server were connected to the node in 'host' mode, this command would allow connection to it ( like the 'connect' command with no other parameter ). In KISS mode, setting a callsign or node alias allows connection to another system. 3.4 STATS The STATS command has no parameters. It prints a number of internal TNC statistics. In this version, this is limited to the level 1 stats of the radio channel and the internal clocks, the level 2 ( AX.25 ), 3 and 4 statistics, and the CPU health checks. For level 1, six pairs of numbers are printed, corresponding to the percentage of time the transmitter was on followed by the percentage of time the receiver DCD was on, for each of the last six 10 minute periods. The data is presented most recent period first. Two pairs of numbers are then displayed showing the transmitter underrun and receiver overrun. These are formatted as per the level 2 stats with port 0 followed by port 1 for the current hour followed by the totals for the previous hour. In the case of the RS232 port, underruns are not possible, and an additional error ( framing ) is included. The RX overrun includes overruns and framing errors. For level 2, the following are displayed : Frame checksum errors Total packets heard Total packets received by the node ( ie sent to it ) Total packets sent by the node Total receiver not ready packets sent Total reject packets sent Total receiver not ready packets received Total reject packets received Total number of link timeouts For each of the level 2 statistics, four numbers are shown. The first two are cumulative totals over the period of one hour, incrementing in real time. The last two are the totals for the previous hour. Each pair of numbers is the total for the radio port followed by the total for the RS232 ( crosslink ) port. For checksum errors, port 0 shows CRC errors and port 1 shows ( when in 'crosslink' protocol mode only ), checksum errors. As HDLC errors can be triggered by noise, acceptance of CRC errors is conditioned by the state of the DCD line. If DCD is on and an error is signalled, it will be added to the count. This reduces the false counts, but does not eliminate them. Distant stations that keep the squelch open ( just ) without being properly heard will result in lots of apparent errors. For level 3, the number of level 4 frames gatewayed between nodes is displayed. For level 4, the number of transport frames sent and received by the node are shown. For level 3 and 4 statistics, two numbers are shown. The first is the number of frames accumulating for this hour, and the second number is the total number of frames for the previous hour. For CPU health checking, two statistics are shown, the CPU loading and the buffer usage. Each looks like the level 1 stats with 6 numbers corresponding to the last six 10 minute periods. The CPU loading shows the number of times, divided by 100, that the CPU makes it around its basic internal scheduler. For a node just switched on, receiving nothing, this will be about 470 ish for a 4.9 MHz clock. With lots of nodes, a heard list of 20 stations and 70-80% activity on the radio channel for it to listen to, this can drop to about 350ish. If it drops to double figures, worry, as the CPU is beginning to thrash. At low double figures, the CPU is pretty much working flat-out. Time to up its clock rate !. The BUFFERS statistic shows the minimum number of free buffers that the software had available to it during the last six 10 minute period. This indicates whether the TNC is failing to deliver data passed to it for onwards transmission, as well as how much data is backed up waiting. Additional stats needed to analyse this properly are not yet being collected. The display also shows the elapsed time since the last warmstart followed by the running time since the last coldstart. Each number is the number of hours of operation. The final set of statistics shown are the port flush values. These are reset on coldstart. The first parameter is for port 0 ( radio ) the second for port 1 ( RS232 ). Each shows the number of port flushes that have happened since coldstart. A port flush occurs when data is queued pending transmission and cannot be sent. It is designed to protect node integrity when a channel is blocked ( for example by a fault ). More specifically, for each port, the node sets a flag whenever data is queued. It sets a flag when data is sent. Every 10 minutes it has a look at the flags and if data was queued but not sent, it sets an internal warning flag. If the warning flag was also set in the previous period then evidently data is building up and nothing is being sent. It then purges the queue of pending data for that port and increments the counter. This is not a perfect defence, but should usually suffice. 3.5 MODE This command is similar to the PARMS command, and includes the new syntax described in section 3.32. It allows a number of other features of the software to be configured remotely. It removes the need for most of the host mode commands. The following parameters may be configured : The host mode The CWID send period The CWID keyer speed The port nodes broadcast control The crosslink / kiss control The Tx delay The full duplex flag The RS232 port node broadcast interval The node broadcast algorithm The beacon period The 'connect' redirector The 'help message enable' flags, case sensitivity & TALK 8 bit flag The 'hash' node broadcast port control Whether the node will listen for the extra aliases Whether remote disconnect causes reconnection to the switch Control over 'slime trails' Control over digipeating up/down links In operation, it behaves just like the PARMS command. The parameters are as follows : 3.5.1 Host mode control This parameter controls the 'host' mode. This is the mode of operation of the RS232 port when pin 23 is 'high' The valid values are 0 or 1. 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 C and D commands are disabled and the other commands do not operate when connected. Instead, hardware handshakes are used to control connections to and from the TNC. The TNC monitors pin 20 to determine the state of the host, and signals state changes to the host with pin 5. 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 with by changing the state of pin 5. It handles disconnects in a similar manner. Either the node or the host may initiate disconnects. 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. 3.5.2 CWID control The next two parameters control the CWID keyer. The first parameter is the CWID repeat period in seconds. Valid values are 0 to 3600. 0 disables it but do not set it below 120 apart from to disable it. The second 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. 3.5.3 Node broadcast control This parameter allows control to be exercised over which ports nodes broadcasts are sent. Valid settings are 0 - 3. Value 0 disables node broadcasts. Value 3 ( the default ) works as normal. A value of 1 enables broadcasts on the HDLC port only whilst a value of 2 enables broadcasts on the crosslink port only. 3.5.4 Crosslink / kiss This parameter is used to set the communications protocol used on the crosslink port when pin 23 is tied low. The valid values are 0, 1, 2 or 3 Mode 0 - standard crosslink protocol enabled Mode 1,2,3 - use KISS instead of crosslink. 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. In mode 3, all packets received on one port are copied to the other port as well as being analysed by the node. These modes are not simply KISS implementations that replace the node, they run with the node. 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 whilst leaving the node running to allow others to use it. 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. 3.5.5 Tx keyup delay This parameter sets the TX keyup delay in 10's of milliseconds. This was previously done using an escape command. 3.5.6 Full Duplex This parameter sets or clears the full duplex control flag. This was previously done using an escape command. 3.5.7 RS232 nodes broadcast interval 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 an hour to be notified to the others. 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. 3.5.8 Node broadcast algorithm This value controls the algorithm used. Bits within the value set have significance as shown below. There is a problem with the nodes broadcast algorithm when many TNCs are crosslinked on RS232. 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. 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. 3.5.9 Beacon period This parameter sets the beacon interval in seconds. In TheNet 1.01, this was fixed at 10 minutes ( 600 seconds ). In this version, this parameter may be used to change it according the prevailing license conditions. 3.5.10 'Connect' redirector 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. 3.5.11 'help message enable' flags 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 : BIT FUNCTION ========================= 0 Whether the 'please wait, trying xxxx' operates 1 Whether all commands appear in help for sysop 2 Whether the 'goodbye' message is given 3 Whether a welcome message is enabled ( CTEXT ) 4 Whether nodes are shown as 'alias:callsign' 5 If set, TALK data is passed as 8 bit data rather than clearing the most significant bit 6 If set, node aliases are deemed to be case sensitive 7 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. 3.5.12 'hash' node port control 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. 3.5.13 Extra aliases 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. 3.5.14 Reconnect to Switch If this parameter is set to 0, the node operates as normally. If set to a non zero value ( i.e. 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, then they are automatically reconnected to the node with a 'welcome back' message. 3.5.15 NoSlime 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 typified by having no alias associated with them. Each bit in the NoSlime parameter controls a different function. Bit 0, if set, causes any stations without aliases to be 'hidden' when a nodes command is given. Bit 1. if set, causes the node to refuse to make slime trail entries in the node table. Before you use this feature, be careful to make sure that you understand the implications of doing so, as without fixed entries the node will refuse to accept level 4 connections from a station until it has heard their node broadcast. 3.5.16 NoDigi This parameter controls the node's willingness to accept digipeated level 2 connections or to allow digipeated downlinks from the node. Each bit of the parameter controls a different function, as shown below : BIT FUNCTION ======================================= 0 If set, do not allow digipeated connections to the node 1 If set, do not allow digipeated downlinks from the node switch 3.6 MHEARD The TNC can be instructed to keep a list of the last 'nn' stations heard, where 'nn' is an integer between 1 and 100. It can also be disabled. The syntax of the command is : MHEARD [ nn ] The parameter is optional and only operates for the sysop. It sets the maximum length of the list. Setting to zero disables the function. The heard list uses free buffers for the list, so a large setting means less RAM for the node software. The list is maintained as linked list, with the most recently heard station first. The display shows the number of packets heard from that station and the time since it was last heard, in hours minutes and seconds. In addition, it shows the port on which the station was heard together with an indication as to whether the station is a node and / or a TCP/IP or a TexNet station. It does this by examining the PID byte. Every hour the list is checked for stations that have not been heard for 12 hours, and any such stations are removed from the list. To disable the internal updating of the list ( and thereby stop the CPU expending effort on the function ), set the size to zero rather than just disabling the command as described in 3.8. Note though that the node will not clear the list as updates have been disabled, so it will be up to 12 hours before the buffers used are freed. To accelerate this process, set the size to 1, wait until it has heard a station ( any one will do ) then set it to zero. This will free up all but one buffer immediately. The heard list is the user interface to the receive deviation meter. Its operation is explained in section 3.31. If enabled ( ie if the METER parameter is not set to 0 ), then an additional column will be displayed in the heard list that will show the received deviation in kilohertz ( as nn.n ). It must be remembered that this is derived by measuring the received signal audio level, and will not be correct in the case of a badly distorted signal. The heard list may also show received signal strengths if enabled by the Sysop. In this case, the signal strength will be shown for each station in the list after the deviation level ( if enabled ). The display will be either dBm or the common 'S1 to S9' format according to its configuration. How accurate it is depends on the accuracy of its calibration. At best it may typically be +- 1dB relative accuracy, at worst totally misleading. In the same way that you can use the deviation meter to set up your station, pay heed of the signal level too. If you are 40 dB over the noise into a local node, consider dropping your signal 20 dB ( for example from 10 W to 100 mW ). Those around you also running high power may however make this difficult. The idea is to get in reliably with the snallest signal not to see how big a signal you can put into the node. 3.7 CQ When CQ is disabled, the command now reports apologetically rather than simply ignoring the request. 3.8 ALL COMMANDS There is often a requirement to be able to disable the connect command whilst allowing level 3 relaying. This is achieved by the use of a command qualifier, the syntax of which is : CONNECT [ + | - ] If '-' is entered by the sysop, then the connect command will politely refuse to work. This can be reversed by the '+' command. This has no effect of layer 3 relaying. Also, the BBS and HOST commands will still allow connections to be made if they are enabled and set. Further, the syntax is valid for ALL commands, for example the CQ command can also be disabled in the same way. Be careful though. The command is only accepted from the sysop, so if you disable the sysop and manager commands you will lock out remote management !. 3.9 NODES When information on a node that is not known is requested, the program prints out an error message rather than giving the names of all known nodes. When a node entry is made by the sysop, callsign checking is forced ON rather than being determined by the callsign checking parameter. Don't forget that node alias handling may be case sensitive - see section 3.5.11. The entire contents of the node table routes may be obtained by the sysop or manager by the command NODES * * This will dump info on all nodes, one node per line, with the following format: Alias:call route1 route2 route3 where route1, route2 and route3 comprise the quality, obsolescence count and port followed by the neighbour callsign for each of the 3 route entries for that node. If any of the routes are in use, a chevron will be shown by that route. The extended command is only for sysop use as it, like auditing and conferencing, causes the node to be a source of a significant amount of data ( dumping a large number of node details can consume hundreds of buffers !!! ). It is quite possible that used indiscriminately, it could cause a warmstart of the node. Be careful. 3.10 RESET The syntax of the command is now RESET [ anything-else ] Entering the reset command alone will do a warmstart. If any other parameter is entered, a coldstart is performed. 3.11 MANAGER The MANAGER command gives the user extra privileges. In this version, this amounts to the ability to receive audit messages from the node. The level of auditing is set by the AUDIT command. The privilege remains in force until cleared by a command that affects the user state. Specifically, these are, entering the TALK state, executing the SYSOP command, entering the MANAGER command and getting the password wrong, or disconnecting from the node. Failing to get the second password right when using the closedown command will also remove the manager privilege. If the MANAGER command is executed by a user who connected to the node by a level 4 circuit rather than by a level 2 circuit, and if the level 2 timeout is less than the no activity timeout, the connection will never timeout as the clearing and reconnecting of the level 2 circuit will keep the process alive provided level 2 auditing is enabled. This allows the operation of the node to be logged remotely and continuously. Alternatively, if the level 4 timeout is greater than 10 minutes, level 1 or CPU auditing will keep it alive if level 2 is switched off. NOTE : I have a nasty feeling that there is something not quite right here - the link sometimes dies !. A user with MANAGER privilege also has SYSOP privilege. 3.12 AUDIT The syntax of the audit command is : AUDIT [ new-value ] where new value is an integer value. If no value is given, or the user does not have SYSOP status, the current mask value is displayed. Otherwise, the mask is updated and the new value displayed. The mask controls the auditing of various events in the node. Not all values are used yet, but those that are, are : BIT USE ============================================ 0 Level 1 statistics on 10 minute updates 1 Level 2 connects & disconnects 2 reserved for future use 3 Level 4 connects & disconnects 4 Level 7 limited events ( use of sysop ) 5 Full level 7 auditing 6 CPU auditing messages ( 10 minute updates ) It is suggested that the usual settings can simply be 0 or 255. For level 1, messages are sent every 10 minutes showing the percentage of time that the receiver detected carrier and the percentage of time that the transmitter was on. At level 2 & 4, the messages are of all connects and disconnects, shown in 4 different ways : C Connect message received by node CA Connect message sent / Acknowledge received D Disconnect message received by node DA Disconnect message sent / Acknowledge received In each case, 2 callsigns are shown. At level 2 these are the source and destination of the AX.25 link. At level 4, it is the remote node callsign and user callsign. Each message is preceded by an indication of the source of the message, such as "L2" or "L4". At level 7, with bit 4 set and bit 5 clear, the only event currently audited is the use of the Sysop command, either directly or via the manager command. If bit 5 is set, then all commands given to the switch are audited, preceded by the callsign of the user who entered the command. Bit 6 controls CPU health check auditing. If set, then whenever the internal CPU statistics are updated, messages are sent showing the CPU processor loading total and the minimum buffers level ( see STATS for more information ). The audit mask value should be set to 0 when not actually being used. Do not leave it set to another value as this wastes processor time. Note also that full auditing on a busy node makes things worse. Treat it as a debugging feature !. 3.13 TALK Talk is a conferencing command. It allows a number of stations to hold a simultaneous conference ( a bit like the CONFERENCE command of a DX cluster ). There is only one conference, and stations may connect to it by connecting to the node and issuing the TALK command. It may be exited by disconnecting or issuing the command '/EXIT' at the start of a line. ( /EXIT may be abbreviated to /EX, and it is not case sensitive ). Each line sent by a user is copied to all other users in the conference, preceded by the callsign of the user. The data will be sent as 7 bit data ( ie the most significant bit will be cleared ) unless the appropriate bit is set in the help flags ( see section 3.5.11 ). Whenever a new station enters the conference, or a station leaves the conference using the '/EXIT' command, the other conference users get a message informing them of the event. These status messages are sent with the callsign of the node rather than the user. Finally, when entering the TALK command, a message may be sent to all those users who are connected to the node but not otherwise doing anything. For example if GxABC enters the line TALK Hello fred, can I have a chat, type 'TALK' Then all other stations connected to the node, present in the USER list but idle, get the message GxABC>> Hello fred, can I have a chat, type 'TALK' displayed on their terminal. Note that merely connecting to the node does not constitute being connected to the switch. Stations connected to the switch appear in the USER list. 3.14 SYSOP The SYSOP command has been enhanced to increase the level of security offered. One problem of the old system is that the password is easily visible unless the user repeats the SYSOP command a number of times. Even then, correlation between passwords is easy, so the password needs frequent changing. To reduce the change period, and make it harder to discover, the node will accept a string of characters and scan it for the password. Hence a response of, say, 30 or 40 characters can be sent, with a random number of random characters preceding the actual data and a random number following it. This does not eliminate such attacks, but if used carefully, it makes it quite a bit harder to attack. 3.15 LINKS This command shows the current level 2 links to the node. Displayed one per line, the two callsigns are shown followed by the link state, port number and current retry count. 3.16 CALIBRATE This command allows remote calibration checks of the transmitter deviation. Its syntax is CALIBRATE period [ toggle ] The period ( 1 to 60 seconds ), is the time for which the transmitter will key up for with constant tone. It is undefined as to which tone will be sent. If the second parameter is given, the node will toggle between the tones every [toggle] seconds. The toggle must be between 1 and [period] seconds. If a period is not given, the user is not sysop or manager, or if it is out of range, the command is ignored. If the tone generator is busy because it is about to send a CWID sequence, a 'busy' message is returned. Note - quite often it can appear that the node has locked up having failed to transmit the full calibrate period. In fact, this is usually the hardware PTT watchdog in the TNC. The node thinks it is still sending but the hardware timer has removed the PTT signal. 3.17 DXCLUSTER The DXCLUSTER command operates just like the BBS command in that it may be used to effect a connection to a DXcluster (assuming there is one nearby). It should be disabled if it is not intended to be used to access a cluster. The syntax of the command is : DXCLUSTER [ * | ? | callsign ] With no parameter, the command connects to a station previously specified by the use of the DXCLUSTER command with a callsign as a second parameter. Setting the DXCLUSTER to allow this may only be done by a sysop. The '*' option may also only be executed by the sysop, this command clears a previously specified DXCLUSTER. The '?' option ( or any text if not sysop ), prints out the current DXCLUSTER station setting. If no DXCLUSTER is set, the command issues an error message if it is invoked with no other parameters. The idea of this command is that, like with the 'bbs' command of the 'BPQ software, a user may connect to the local DXCLUSTER from the node. 3.18 HELP The HELP command gives a message from the ROM. In general, it is expected that the message will be designed to assist new users in understanding the operation or configuration of the node. The message may span many lines, and may be changed when the ROM is programmed. As delivered, it contains a brief help screen detailing the main ( user ) changes to the code. 3.19 CTEXT The CTEXT command sets or displays a message sent to a user who connects to the node by uplinking to the node's alias. The syntax of the command is : CTEXT [ * | message ] With no parameter, the current message is displayed. If the user is also a sysop, and if text follows the command, that text is added to the current connect text. If the message starts with a '*', the connect text message is deleted. Hence, to clear the message, type the command 'ctext *'. This is a change in version X-1J from previous versions. For further information, see section 3.33 A message is only sent if there is a ctext message set and if the relevant bit is set in the mode command parameter as described in section 3.5.11. 3.20 BTEXT The BTEXT command sets or displays the additional beacon text sent along with the beacon packets. The syntax of the command is : BTEXT [ * | message ] With no parameter, the current message is displayed. If the user is also a sysop, and if text follows the command, that text is added to the current beacon text. If the message starts with a '*', the beacon text message is deleted. Hence, to clear the message, type the command 'btext *'. This is a change in version X-1J from previous versions. For further information, see section 3.33 Normally, beacon packets are UI frames that contain the node callsign and alias. If a beacon message is set, the text of the message follows the alias in the same packet. It is strongly suggested that beacon packets be kept brief !!!. 3.21 ACL This is probably the most complex additional command in the program. It should be used with care, and only when you really understand its operation - mistakes can result in the need to go out to a remote site ( probably when it is cold and wet ) to reconfigure the node. The command allows selective control, based on callsign, of a list of different events. The ACL contains two types of entry, a default value and zero or more callsigns, each of which are associated with a value. When one of the controlled events occurs ( such as an incoming level 2 connection or a nodes broadcast ), the ACL is scanned for an entry that matches the callsign of the sender. If a match is found ( but see below ), the value associated with that callsign is used to determine the action the node will take. If no match is found, the default value is used. An ACL function mask is provided. This enables specific ACL functions to be disabled to speed up the node. Each bit of the mask enables ( if set ) or disables ( if clear ) the corresponding function. For example, if the mask is set to 2, the node will only check its ACL for outgoing level 2 connections. Each bit of the value or mask controls a different function, as shown below : BIT OPERATION ===================================================== = 0 bar incoming level 2 connection 1 bar outgoing level 2 connection ( downlink ) 2 ignore nodes broadcasts from this station 3 bar gatewaying at level 3 to/from this station 4 bar incoming level 4 connections 5 bar outgoing level 4 connections 6 ignore SSID in matching an entry So if for example an entry exists for a callsign G99XXX of 6, then the node will not allow outgoing level 2 connections to the node ( downlinks ), and will ignore node broadcasts from that station. Note that these commands only operate on the events themselves - if G99XXX creates a level 2 connection, the node will quite happily use it itself. The 'ignore ssid' bit is used to match a callsign without regard to its SSID. This makes life interesting when finding a match, so the list is scanned twice, once for an exact match, and then for a match ignoring SSID if an exact match is not found. There can only be one exact match, but when searching for a match without using SSID, the first entry found will be used. The syntax of the command is as follows ( 4 versions ) ACL * value ACL & value ACL callsign + value ACL callsign - If you are not sysop, or if ACL is given on its own, the current contents of the ACL are shown. The first form of the command changes the default value, the second form sets the mask enable value, the third makes an entry in the list, and the last form removes an entry from the list. It complains about syntax errors. A few moments thought will show that the sequence of commands connect to node execute sysop or manager command type the command ACL * 127 type the command ACL & 127 disconnect is quite catastrophic. You will not be able to get back in again apart from via the host port and noone will be able to connect to or from the node. If you intend to experiment with the command, you should start by entering your own callsign with a value of zero to ensure that you can get back in again !!!. The list can be used as an 'accept' or 'reject' list by judicious use of the default. To create a list that excludes specific calls, put them into the list with the required bits set in the value. The default should be zero. To create an 'accept' list, put entries in with the required bits zero and set the corresponding bits in the default. Individual bits may be used to create accept or reject lists for each function. The command steals buffers at a rate of one buffer per four entries in the ACL. Also, a long ACL will slow the node down nicely - so think before you enter a long list. This command is for experimental purposes - if you find any bugs, let me know please ( I have not fully tested the gateway bit for example ). Also, it is not intended for malicious use but to allow fine control to be exercised over backbone networks. If I get lots of negative responses back, the command will go ! The mask value should be set so that only those functions actually being used are enabled. For example, if the node has an ACL set to control level 2 uplinks and downlinks, it will also check its ACL for all other controlled operations such as level 3 gatewaying. This will result in much time being wasted searching the list for a result that is going to always succeed. In the example cited therefore, the mask would be set to 3. On reset, the mask value is set to zero, SO ALL ACL FUNCTIONS ARE DISABLED AND MASK MUST BE SET TO ENABLE THEM !. The level 4 function has been extended so that it examines not only the originating node callsign but also the user callsign from that node in deciding whether to refuse a connection. Previous to X-1J release 4, it only looked at the node callsign. 3.22 CLOSEDOWN The closedown command is used to shut down the node remotely. If successfully executed, the node will effectively stop operating until it is reset ( e.g. by a power up ). The node's configuration ( routes, messages etc. ) are not destroyed - the node simply hits a HALT instruction. You must be sysop to execute the command. The syntax of the command is: CLOSEDOWN A The node will respond with 5 numbers just as for when the sysop or manager command was executed. Yes, you guessed, the node expects another password. Give it correctly and the node closes down completely. Get it wrong and you lose your sysop status. This obtuse and awkward syntax is designed to make sure it is not accidentally executed. 3.23 ALIAS The ALIAS command allows the node's alias to be changed. The syntax is : ALIAS [ * | new-alias ] If no parameter is given, or if the user is not SYSOP or MANAGER, the current alias is displayed. If the alias is deemed to be a valid alias, the node's alias is changed to the new one entered. Note that the algorithm that checks for the alias structure is a bit queer. It is however, the original algorithm of TheNet and I am loathe to change it for fear of side effects. Note too that the companion CALLSIGN command is NOT included - chaos is not something I crave. If the sysop gives the parameter of '*', the node's alias is cleared. 3.24 BBSALIAS HOSTALIAS DXCALIAS These commands are used to enable the node to respond to up to three additional aliases. The syntax of each is the same, and by way of example the BBSALIAS syntax is : BBSALIAS [ * | new-alias ] If not sysop, if no new alias is specified, or if it does not pass the weird alias syntax checker ( see 3.23 ) then the current alias is displayed. If not, the alias is changed. If '*' is given, the alias is cleared. The aliases so entered are nothing to do with the node's identity. If a BBS alias is set, for example to MXMBBS, then the node will listen for level 2 connects to that alias. It will respond to them and will automatically invoke the BBS command. The use will also get the optional welcome (ctext) message and 'trying to connect to ....' messages if enabled by the appropriate 'mode' parameter. The idea is that where a node sits on a channel that does not have access to the local host, BBS or cluster, the normal aliases of those stations may be enabled in the node to allow consistent access to the local services. Note that the three stations do not have to be a BBS, Host and cluster, it could be three BBSes or any other combination. 3.25 IPSTATS The IPstats command has the same basic syntax as the PARMS and MODE commands. When invoked without parameters, it displays the current stats. Each statistic may also be altered by sysop, as defined in section 3.32. In addition to the standard IP MIB, there is an additional parameter used to set the level 2 default modes, and the first entry in the MIB is used to enable or disable the router. The complete set of IP MIB stats are included for compatibility with other IP systems, but several are not used. Also, the stats are 16 bit counters not 32 bit counters as in NOS. Like NOS however, the stats do not reset every hour, they must be cleared by the sysop. They will however wrap around at zero. The entries are: 1 Port default modes 2 Enable / Disable the IP router functions 3 Default IP Time To Live 4 IP Received frames 5 IP Header Errors 6 IP Input Address Errors 7 IP Forwarded Datagrams 8 IP Unknown Protocols 9 IP input frames Discarded 10 IP Input frames Delivered 11 IP Output Requests 12 IP Output Discards 13 IP Output No Routes errors 14 IP Reassembly Timeout errors 15 IP Reassembly Required errors 16 IP Reassembly OKs 17 IP Reassembly Fails 18 IP Fragmentations completed OK 19 IP Fragmentation Failures 20 IP Fragmentation Creates The default mode word may be set to 0, 1, 2 or 3. Each bit controls a port, with bit 0 controlling port 0 ( radio port) and bit 1 controlling port 1 ( RS232 port ). When set to 1, the default mode for that port when sending on a level 2 connection will be Datagram. When set to 0 it will be by Virtual Circuit. The default mode is used when no other information is given, either by the ARP table or by the TOS bits in the IP header. The enable / disable word may be set to 0 or 1. When set to 0, the operation of the router is stopped, when set to 1 the router functions. The IP Time To Live ( TTL ) word is used to set the number of routers through which an IP frame may pass before it is discarded. It is similar to the node layer 3 TTL word. It may be set to any value up to 255, but values below 2 make no sense and are therefore not permitted. The IP fragmentation reassembly timeout counter is not used as the node is just a router. It is left set to 30 seconds just to show which one it is ! The rest are just statistics. The patient user can have hours of fun working out which ones are not used ( or just think about it for a second or two ). 3.26 IPADDRESS & IPBROADCAST These commands are used to set or display the IP addresses used by the node. The syntax of each is (by way of example): IPADDRESS [ ipaddress ] where ipaddress is in the form nnn.nnn.nnn.nnn where nnn is an integer in the range 0..255 So to set the node IP broadcast address to that used over here, the command would be : IPBROADCAST 44.131.0.0 The IPADDRESS is the address that the node will respond to. It is used only as detailed in section 7. The IP broadcast address is the one used to denote broadcast packets that will be largely ignored. Note that port addressing is NOT currently supported. Anyone who finds this limiting, drop me a line and I'll see if I can change it. 3.27 IPROUTE This is one of the two main databases used by the node. The IP Route table is used to tell the router where to send a frame for a specific destination. It maps addresses or address ranges to a gateway IP address and to sub-network ports. The ARP database then tells the node what station corresponds to that address and protocol. The node supports two subnet protocols, AX25 and Net/Rom. The database is stored in an ordered list, in decreasing order of the number of relevant bits. This is to permit searching of the database when trying to find a specific destination. Given an address, it scans addresses with decreasing numbers of bits until it finds a match. The syntax of the command is as follows : IPROUTE [address [ / bits ][ + port [gateway [metric]]]] or IPROUTE [address [ / bits ][ - ]] In the first form, it makes an entry in the table, in the second it deletes one. Only sysop or manager may effect such a change. The parameters are as follows : address The amprnet address in the form nnn.nnn.nnn.nnn bits The number of significant bits (eg 44.131.0.0 /16) port The port, either 0 or 1 for AX25 or n for Net/Rom gateway The optional gateway for this dest. nnn.nnn.nnn.nnn metric Currently not used, a numeric value When an entry is made with a specific number of bits, the address is 'masked off' to that many bits, so enter an address of 44.131.16.31 / 24 and it will get entered as 44.131.16.0. The valid range for the number of bits is 0 - 32. Entering a route with bits set to 0 will cause an entry to be made in the IProute table of 0.0.0.0 which will function as a default route entry. 3.28 ARP The ARP table maps a pair of address+port to hardware address+subnetwork mode. The address is either a destination or a gateway in the form nnn.nnn.nnn.nnn. The protocol is either Net/Rom or AX25. The hardware_address is a callsign and the subnetwork mode is DG or VC ( only has significance for level 2 links ). The syntax of the command is : ARP [ destination [ + [ P ] protocol callsign [ mode ] ] ] or ARP [ destination [ - protocol ] ] In the first form an entry is made in the table, in the second an entry is deleted. This is only permitted for sysop or manager. The parameters are : destination An address of the form nnn.nnn.nnn.nnn P If present, marks the entry as 'published' protocol AX25 or Net/Rom callsign A valid amateur callsign, e.g. G8KBB-5 mode DG or VC If 'P' is entered, then the node will publish the address. Specifically, if an ARP request is seen by the node for a station with the address given, it will send a response advising the caller of the callsign to be used. More details on the operation of the router are contained in section 7. The ARP table also shows a further parameter of TIMER. This is only shown when it has a value other than 0. When non zero, it is a timer showing the number of minutes before the ARP entry is automatically deleted. Entries made by means of the ARP command have timer values of zero and therefore persist. Entries made from the network by ARP protocol frames have the timer entries set to the ARPtimer initial default. 3.29 UI The UI command allows a string to be sent as a Level 2 UI frame. The syntax is UI dest string_of_text_ending_in_return Dest is a callsign like destination such as 'MAIL'. What will happen is that a single UI frame will be sent with a source callsign of the user who entered the command, a destination callsign of dest, and the rest of the string as text. It is designed to be used in situations where a local BBS does not have access to a common channel and wishes to send mail notification packets. Not surprisingly, the ability to do this is BBS specific. 3.30 MTU command The MTU command is used to configure the node's Maximum Transmission Unit figures ( primarily for TCP/IP support ). In general, they should be left at the default values. Do not experiment unless you are sure you understand the significance of what you are doing !!!! The syntax of the command is identical to the syntax of the PARMS and MODE commands, as defined in section 3.32. There are 5 values configured by the command. These are : Number Default Function ========================================================== 1 256 Sets the MTU for the IP router, AX.25 Level 2, Radio port ( port 0 ) 2 256 Sets the MTU for the IP router, AX.25 Level 2, RS232 port ( port 1 ) 3 236 Sets the MTU for the IP router Net/Rom interface 4 257 Sets the maximum number of data bytes permitted in an AX.25 level 2 frame before an error response is returned to the sender ( frame too long ) 5 328 Sets the maximum number of bytes permitted in a level 2 packet. Above this, frames are discarded. If a packet may contain 256 data bytes, and a maximum length address of sender, recipient and 8 digis comprises 70 bytes, and 2 bytes are used for control bits, the total ( 256+70+2 ) is the setting of this parameter. This command replaces the ROM patching needed for TheNet X- 1H. The minimum that an MTU may be set to is 64, the maximum is 1024, but large packets increase the probability of crashing the node. Beware !!!!!!. The MTU for the Net/Rom port should not in general be set higher than 236 or it will not be compatible with Net/Rom. The limits on the other two correspond to those necessary to support frames in the range 256 - 1024 data bytes long. 3.31 METER command This command's syntax is similar to the PARMS command, and includes the new syntax as described in the overview guide, section 3.32. It allows the following parameters to be controlled. Note that the parameter list differs from TheNet X-1J, where the first ( and only ) parameter was the deviation meter scaling factor. 1 The meter mode flags 2 The deviation meter scaling factor 3 The signal strength meter noise floor value 4 The S meter display format multiplier 5 The dBm meter display format multiplier 6 The dBm noise floor value 7 The voltmeter channel 1 multiplier 8 The voltmeter channel 2 multiplier 9 The voltmeter channel 1 offset value 10 The voltmeter channel 2 offset value 11 The voltmeter channel 3 multiplier 12 The voltmeter channel 4 multiplier 13 The voltmeter channel 3 offset value 14 The voltmeter channel 4 offset value 3.31.1 The meter mode flags Each bit of this parameter controls a different aspect of the meters as shown below BIT If set, then .... ====================================================== 0 The deviation meter is enabled 1 The signal strength meter is enabled 2 The signal strength is shown as S points rather than dBm 3 ADC channel 3 is enabled ( voltmeter channel 1 ) 4 ADC channel 4 is enabled ( voltmeter channel 2 ) 5 Voltmeter channel 1 divisor is 1000 rather than 100 6 Voltmeter channel 2 divisor is 1000 rather than 100 7 Voltmeter channel 1 displays fine resolution rather than integers 8 Voltmeter channel 2 displays fine resolution rather than integers 9 ADC channel 1 is enabled ( voltmeter channel 3 ) 10 ADC channel 2 is enabled ( voltmeter channel 4 ) 11 Voltmeter channel 3 divisor is 1000 rather than 100 12 Voltmeter channel 4 divisor is 1000 rather than 100 13 Voltmeter channel 3 displays fine resolution rather than integers 14 Voltmeter channel 4 displays fine resolution rather than integers 3.31.2 The deviation meter scaling factor This is the parameter previously described in section 3.31 of the overview guide. It scales the deviation meter display. One change however from X-1J. Setting it to zero does not disable the deviation meter - bit 0 of the meter mode word as described above controls whether it is enabled. When set to a value in the range 1 - 255, the meter is enabled and the value is used as a scaling factor. The ADC is an 8 bit device, so it will give a response in the range 0 - 255, corresponding to an ADC input voltage in the range 0 - 3 volts DC. If optimally configured, this corresponds to the maximum audio level possible for the given receiver discriminator. The ADC reading ( 0 - 255 ) is multiplied by the meter parameter value ( 1 - 255 ) to give an answer in the range 0 to 65 KHz ( approx. ). This is the value displayed in the mheard list. Hence, if, for example, a DC voltage of 2 volts at the input to the ADC corresponds to 3.4 KHz deviation, the ADC reading will be 171 ( +- a few ) and the Meter parameter will need setting to 20 ( ie to 3400 / 171 ). If the ADC reading is 254 or higher, then in order to indicate an overrange, the symbol '>' will precede the corresponding deviation entry in the heard list. 3.31.3 The signal strength meter noise floor value This parameter sets the 'no signal' offset applied to input readings from the signal strength meter. It is subtracted from the count read from the ADC to give a reading based on a no signal value of zero. If the no signal ( noise ) reading is, for example 0.65V, corresponding to an ADC count of 256 * 0.65 / 3 or 54, then 54 is subtracted from each ADC signal strength reading to give an integer from 0 to 201 for an input reading between 54 and 255. 3.31.4 The S meter display format multiplier This parameter operates in a similar manner to the dBm multiplier ( section 3.31.5 ) but having divided the intermediate result by 256, that value is displayed as an integer in the range 0 to 9 preceded by the letter 'S'. If the value exceeds 9, it is displayed as 'S9+'. If the dBm multiplier has been set up correctly, then set this parameter to the dBm multiplier divided by the number of dB per S point. 3.31.5 The dBm meter display format multiplier This parameter is used to convert an ADC reading for the signal strength meter into a dB count. The ADC reading is converted into a count from 0 to n, according to the description contained in section 3.31.3. It is then multiplied by this parameter and divided by 256. When added to the dBm noise floor value ( section 3.31.6 ), this gives the displayed dBm value in the heard list. 3.31.6 The dBm noise floor value This is the noise floor ( dBm ) reading that corresponds to the zero count in section 3.31.3. It is entered as a positive count corresponding to a negative value. For example, if the zero point in the example of section 3.31.3 is -113 dBm, the noise floor value entered is 113. 3.31.7 The voltmeter channel 1 multiplier This is the multiplier that controls voltmeter channel 1 ( ADC channel 3 ). It is set as described in section 3.34 below. 3.31.8 The voltmeter channel 2 multiplier This is the multiplier that controls voltmeter channel 2 ( ADC channel 4 ). It is set as described in section 3.34 below. 3.31.9 The voltmeter channel 1 offset value This is the value subtracted from the ADC reading before it is multiplied by the multiplier parameter. It is described more fully in section 3.34 below. 3.31.10 The voltmeter channel 2 offset value This is the value subtracted from the ADC reading before it is multiplied by the multiplier parameter. It is described more fully in section 3.34 below. 3.31.11 The voltmeter channel 3 multiplier This is the multiplier that controls voltmeter channel 3 ( ADC channel 1 ). It is set as described in section 3.34 below. 3.31.12 The voltmeter channel 4 multiplier This is the multiplier that controls voltmeter channel 4 ( ADC channel 2 ). It is set as described in section 3.34 below. 3.31.13 The voltmeter channel 3 offset value This is the value subtracted from the ADC reading before it is multiplied by the multiplier parameter. It is described more fully in section 3.34 below. 3.31.14 The voltmeter channel 4 offset value This is the value subtracted from the ADC reading before it is multiplied by the multiplier parameter. It is described more fully in section 3.34 below. 3.32 PARM, MODE, MTU, METER & IPSTATS command syntax The syntax of these commands has changed. All use the same syntax, which may be either of two types, the original TheNet 1.01 syntax ( as used in versions previous to X-1J ) or an 'offset & value' type. The original syntax was, by way of example, PARM { [ * | new_value ] [ * | new_value ] .......... } so to set the 10th PARM ( the L4 retries ) to 1, the syntax would be : PARM * * * * * * * * * 1 The equivalent new syntax command would be : PARM / 10 1 The '/' command signifies that what follows is the parameter number followed by the new value. As for the old command syntax, the complete list of parameters is displayed. Setting the parameters may only be done by a Sysop. Note that BOTH command syntaxes are supported - you can use whichever you prefer. 3.33 BTEXT, INFO and CTEXT Command Syntax In Version X-1J, the syntax of these commands changed. In addition, the Info message was doubled in size to 160 bytes. If someone who is not Sysop uses the command, the current settings are displayed. If a Sysop uses it without any additional parameters, the current setting is displayed. If a Sysop enters one of the commands followed by a parameter of '*', the current message is deleted. If a Sysop enters a string of text, that text is added to the current message, followed by a newline. It is therefore possible to build up multiple line messages. If you wish to start a message with a blank line, enter a message with a non display ( or innocuous display ) character such as control-A. It will get entered followed by a newline. On most systems this will not display. On some systems such as PCs running NOS, it will display as a smiley face. 3.34 The ADC command This command is used to read the voltages on the ADC channels 3 and 4 ( referred to as the 'voltmeter channels 1 and 2' in the documentation. It also displays the ADC channels 1 and 2 ( referred to as the 'voltmeter channels 3 and 4' in the documentation ) if these optional channels are enabled. ADC channels 1 and 2 are normally used for the deviation meter and S meter respectively. If one or other of these functions is not wanted, then the corresponding ADC channels may be used as general purpose inputs just like channels 3 and 4. In this case, the METER Mode Flags are used to enable the channels, the ADC3 and ADC4 commands are used to set the textual descriptions and the ADC command is used to read the channels. If the S meter or deviation meter are enabled and the channels are also in use as ADC command channels then the ADC command readings will read true but the deviation meter or S meter may occationally read incorrectly if the ADC command is issued by a user and actioned at the same time as the software is reading on a received packet. A typical display is shown below : IPNET:G8KBB-5} 13.2 V DC -5 deg C Each channel is associated with a scaling factor in the METER command, an offset value, two control flags and each meter may be enabled or disabled by setting or clearing the appropriate bit in the meter control flags word ( see section 3.31 ). Finally, each has a textual string that may be appended to the reading, as shown in the above examples. The displayed voltage is shown as ( meter_reading - offset_value ) * Scaling_factor / n where n is 100 or 1000 depending on the setting of the resolution bit ( see section 3.31.1 ). The calculation is done with 16 bit signed registers, so it is important that the intermediate result of (meter_reading - offset_value ) * Scaling_factor lies in the range -32768 to + 32767, hence the choice of n. It is shown with a resolution of either 1 or 0.1 depending on the resolution flag, as described in section 3.31.1. By way of example, with a scaling factor of 71, a resolution of 'fine', an offset of 0 and a divisor of 1000 will give a display ranging from 0 to 18.1V in steps of 100 mV for an input in the range 0 to 3V DC input to the ADC. By setting the scaling factor and divisor accordingly, it is possible to create a meter with full scale readings up to 320V. For the 18 V fsd meter, a resistor from ground to the ADC input of 2.2K with a resistor from the ADC input to the voltage to be measured of 11K will give the correct display with a scaling factor of 71 and an ADC reference of 3V ( with a slight error that can be corrected by tweaking the ADC reference ). The facility may be used to create a temperature meter by connecting a suitable sensor to the ADC input. This will usually give a value that ranges over a portion of the input range for a range of temperatures. The reason for the offset value and use of signed arithmetic is to allow the input reading to be converted into a direct display of temperature. Full details are contained in the file 'temp.doc', but by way of example, if the input probe gives a range of 0 to 2.6 V for a temperature display of -40 to +90 degrees Celcius, the settings would be offset = 68 scaling factor = 59 divisor = 100 ( control bit cleared ) resolution = coarse ( control bit cleared ) and for a corresponding Farenheit display of -40 to +194, the settings would be offset = 38 scaling factor = 106 divisor = 100 ( control bit cleared ) resolution = coarse ( control bit cleared ) Note that there is little point using the fine resolution mode for these displays. The ADC channels are read whenever the ADC command is issued, interrupts being disabled for 100 microseconds for each reading on a 4.9 MHz TNC2. The ADC needs 40 microseconds to convert the data, and the 100 microseconds allows for a 10 MHz TNC2 to be used. 3.35 ADC1, ADC2, ADC3 and ADC4 commands These commands are used to set a textual string that follows the ADC readings. The format and parsing is the same as for the INFO and similar commands ( see section 3.31 ), but the length is only 8 characters. The same routines were used to save space but this is not really an ideal way to do it. To set a string, the previous must be cleared with the '*' option, and a new string entered. If the string is less than 12 characters long it will be followed by a newline. These strings are not preset in the EPROM and will need to be entered after a coldstart. All other meter parameters may have ROM defaults. 3.36 L3MHEARD The L3 Heard list records the identity of nodes that use this node for gatewaying their Net/Rom frames. Every time that the node receives a Net/Rom frame from another node it is either destined for the node or it is for gatewaying to another node. When a frame is received for gatewaying, its passage is recorded in the L3 Heard list. It functions and is managed in a manner similar to the main heard list, with the callsign of the sending node, time since it was last heard, total number of frames gatewayed and level 2 port number from which it was received being recorded. In addition, each entry records the callsign of the last destination node. Each Net/Rom frame contains an originating node callsign and a destination node callsign. The entry in the table is associated with the originating node callsign and the final entry on each line shows the destination node of the last frame gatewayed from each origination node. The L3 heard list is managed in a manner identical to the main heard list. It has a length set by the sysop and will drop old entries from the end of the list when the list is full or when a node hasn't gatewayed through the node for more than 12 hours. The initial size of the L3 heard list is the same as the size of the main heard list with both set to the ROM default size. 3.37 BRATE This command only works with the PK96. The PK96 hardware does not have the TNC2 hardware switched baud rates. Instead, it has software selected baud rates and a 9600 baud modem as well as the 1200 baud modem. The node software supports this by the inclusion in the ROM default values of initial baud rates and by a sysop only switch command to allow those to be changed during operation. Each baud rate may be set in the range 300 to 19200 baud to one of 7 standard rates. This does not imply the code will reliably handle data at 19200 but it seemed fun to include it. The rom defaults may be overridden by the BRATE command. The syntax of this is similar to the PARMS, MODE etc. commands, and has two parameters. The first is the radio port rate, the second the RS232 rate. Values are in the range 0 to 6 and have the following meanings : Setting Baud Rate 0 300 1 600 2 1200 3 2400 4 4800 5 9600 6 19200 When the BRATE command is used to change a setting, it DOES NOT take immediate effect. It will take effect after a warmstart. Coldstart will, of course, restore the ROM defaults. A warmstart may be effected by the RESET command ( as sysop ) or by powering off and on again the PK96. The radio baud rate setting also controls the modem selection. If the selected baud rate is 1200, then the 1200 baud modem is selected. If any other rate is selected, the 9600 baud modem is selected, but with the baud rate requested. When a CWID is sent ( if enabled ), the code will reselect the 1200 baud modem regardless of which modem was in use in order to send a valid ID in tone. It also keys the tone on and off rather than switching between tones as the TNC2 version does. If the 9600 baud modem was in use, the 9600 baud modem will be reselected after the CWID. 3.38 ARPTIMER The ARP timer is managed as for other parameter based commands such as PARMS, MODE etc. and is used to control the ARP protocol machine. The ARP table has, until now, been managed manually. With this version, the node will automatically update its ARP table by issuing ARP requests and by interpreting ARP requests and ARP replies. The ARPtimer command has two parameters. The first enables (1) or disables (0) the ARP service routine. The second is the ARP timer in minutes. When the node receives an ARP request or reply, it will if appropriate make an entry in the table and set the timer to the ARPtimer value. It will then decrement once a minute. When it reaches 0, the ARP entry is deleted. The ARP timer may be set to any value between 15 and 1440 ( i.e. quarter of an hour ans 24 hours ). ARP requests/replies DO NOT apply to Net/Rom encapsulation. Entries will only be made automatically for AX.25 connections. For Net/Rom encapsulation, make the entry manually. If the ARP function is disabled, the system does two things. Firstly, it will stop processing received ARP frames. Secondly, it will stop decrementing the ARP table entry timers thereby freezing the ARP table entries. As a warning to any attentive sysop, it will still generate ARP requests if it lacks a table entry but will ignore any response. Note that any entries in the ARP table made by the SYSOP using the ARP command will not be overwritten by received frames and will not age. One final difference between this code and NOS. When NOS receives a frame for transmission for which it needs to request an ARP entry, it will queue the frame pending address resolution. It will also send an ICMP source quench if further frames are received whilst the request is pending. This code will not. The IP frame that causes the ARP request to be sent will be lost. So, if you PING it and it sends an ARP request you will get a response to the PING the next time you ping it. 4. Other Changes This section covers the other miscellaneous changes to the software. 4.1 Command Processor The command processor has been altered. In general, but not in all cases, commands only appear on the 'help' menu when they are enabled, so for example the 'BBS' command will not be shown unless it has been enabled with the 'BBS +' command. The exception is the sysop commands, like MODE, LINKS and PARMS, which are never shown to users but are of interest to them. If the appropriate bit is set however in the MODE command ( see 3.5.11 ), then for the sysop or manager, all commands appear in the help prompt - EVEN IF DISABLED. The help screen now shows commands in a combination of upper and lower case characters. Some commands however are never displayed in the command lists, even when enabled. An example of this is the PARMS command. This is controlled by a flag associated with each command in the same way that the command enable / disable bit is associated with each command. An addition to the command syntax controls this. A command is displayed to a user only when it is enabled and its display bit is set. The display bit is set by using the '+' command with the letter 'D' following the '+'. Conversely it is cleared by using the '-' option followed by 'D'. Hence to display the PARMS command in the user command list, the sysop enters parms + d or to hide the STATS command whilst still leaving it open to users to use, the sysop enters stats - D The 'D' may be in upper or lower case. The full syntax of the command modifier is therefore command [ - | + [ D ] ] If no letter follows the '+' or '-', or if it is not 'D', then the command enable / disable flag is modified. The letter 'D' may be in upper or lower case. It is frequently the case that a configuration file is created that can be uploaded to the node following a reset. It is also useful to be able to put comments into such a file. In order to assist this, any lines that start with a '#' are ignored by the switch. 4.2 Beacon digi It is possible to set a digi in the address used for beacon packets. Details of how to do this are contained in the configuration guide. Note that this is provided for those rare occasions when there is a genuine need. This is rarely the case and should not be done unless really necessary. 4.3 Nodes Broadcasts after power-up The node will now broadcast its node table 60 seconds after power-up. This is to ensure that the network is back to an operational state as soon as possible following a node reset. The reason for the short delay is to cater for the situation where the Sysop switches on the node before the radio. 4.4 TexNet interface handling The TexNet interface is controlled by bit 7 of the user help messages word ( MODE parameter number 12 ). If set to a value between 128 and 255, the TexNet interface is enabled. With values between 0 and 127 it is disabled. When disabled, operation is as normal. When enabled, the node will react to the TexNet "*** LINKED to.." messages. When a level 2 connection to the node is made, the node will examine the first line of text received by the node. It must be a line of text terminated by a return character, and it must be the first line of text received. If any other line is received first, the node will issue an error message. The line is checked to see if it starts with the text *** LINKED to It must start in the first character of the line and match exactly the string shown. If it does, the text that follows the string is scanned for a valid callsign. If one is found, the user call is remapped so that any subsequent actions of that user are attributed to that new callsign. Any text that follows the callsign ( including any TexNet SSID ) is ignored. So, for example, if the string *** LINKED to WB4DDP E something else is received by a node ANODE:G8KBB from a station G9BF, then the session, otherwise attributable to G9BF will be remapped to WB4DDP. The 'E' that followed was an SSID of 14, which is ignored. The heard list will show the following ANODE:G8KBB} TheNet X-1J4 (644) TexNet(G9BF WB4DDP) Any actions by that user, such as conferencing or onwards connection to other nodes will use the callsign WB4DDP. If a remote disconnect causes reconnection to the node, the remapped callsign will continue to be used. Note that only one station at a time may use a connection between a TexNet node and a TheNet node as it references a remapped level 2 connection. It is however possible to connect to the callsign or alias of the node and invoke the remapping function. When the TexNet remapping is done, then the connect text message will be sent to the user if the connect message is set and enabled. If the node sees a packet with a TexNet PID, it will note that station as TexNet in the heard list. 4.5 The USER command and CHOKE status The USER command shows stations connected to the node. When a user connects on to another node or downlinks, an entry is formed showing the two links on either side of a "<-->" or "<..>" symbol. In this version, the '-' characters will be replaced by another character if one or other link is choked. The first '-' character is associated with the left hand connection ( circuit or uplink ). The second with the other circuit or downlink. For a level 2 uplink or downlink, the "-" is replaced by 'C' if the connection is choked. For Level 4 connections, the "- " is replaced by one of 3 characters, "R" if it is choked from the other end, "L" if it is choked from this end or "C" if it is choked from both ends !. 5. CWID keyer. The CWID keyer sends the station callsign in CW by alternating between the two modem tones ( TNC2 ) or keying a single tone ( PK96 ). This is nominally sent at 20 wpm once every 30 minutes, but the speed and period can be changed remotely. After a delay of 30 minutes, the callsign is sent appended to the end of the next data packet that is sent over the air. There is a 500 ms delay after the end of the data packet before the call is sent. The program prefers to send CWIDs appended to ordinary data packets. However, if one minute after the CWID has supposed to be sent it is still pending because no data packets have been sent, it will key up the transmitter anyway. Persist, TxDelay and other parameters are honoured, but the process involves changing the SIO mode and this will have an annoying effect on any packets being received in full duplex mode. 6. Version X-2. X-1 was the first release of this code. The objective is to get some practical feedback and test the code before the full release, version X-2, which I hope will be very similar to this release ( X-1J2 ). I have been saying this for some time now, but things keep getting added. Version X-1A added the escape-N command and the change to the connect, nodes and reset commands. The timers were also added to the stats command. Version X-1B removed all the escape commands apart from C, D and P. It also added the MODE command and extended the + and - command qualifiers to all commands. Version X-1C added TALK, MANAGER and AUDIT. The SYSOP command was enhanced and the INFO command was altered to limit the length of a message ( a bug in the original version of TheNet ). The help screen was changed to display commands in a combination of upper and lower case. Version X-1D extended the auditing and statistics to cover auditing everything but level 3, and statistics of the CPU, Level 1, Level 2 and timers. Version X-1E added beacon timer control, the connect redirector, the nodes dump facility, level 3 & 4 statistics and the LINKS and CALIBRATE commands. Version X-1F added the CLOSEDOWN, DXCLUSTER, ACL, CTEXT, HELP and BTEXT commands. Another parameter was added to the MODE command to control textual messages. The mod suggested by DF2AU to correct the DCD latchup was included. Additional statistics were added covering CRC errors, receiver overrun, transmitter underrun and framing errors. Version X-1G added mainly the IP router, with the following commands to control it - IPROUTE, ARP, IPSTATS, IPADDRESS, IPBROADCAST. In addition, the ALIAS, BBSALIAS, HOSTALIAS and DXCALIAS commands crept in, as did QUIT as an alternative to BYE. The help messages extended to enable nodes in the routes list to appear as alias:callsign, and an extra byte on the MODE command allowed '#' nodes to be selectively NOT broadcast. The order of HELP and HOST commands changed so that 'h' on its own gave help not host. The code was optimised with some time critical parts being recoded in assembler and a peephole optimiser being used for additional improvements. Version X-1H fixed 3 bugs in X-1G. Version X-1J added the deviation meter support with the Meter command and Mheard changes. In addition, parameters were added to the MODE command for slime trail control, control of digipeating and reconnection to node. The command syntax of Info, Btext and Ctext was changed to support multiple lines and the Info message space was doubled to 160 bytes. Nodes broadcasts now occur 60 seconds after power up and the ARP Digi bug fix was included. The level 4 minimum retries was dropped to 1 and the PARM, MODE, IPSTATS, METER and MTU command syntax was extended to support 'offset & value' type operation. An MTU command was added to allow IP MTU limits to be changed under software control. The node alias case sensitivity bit and TALK 8 bit data bits were added. Version X-1J Release 2 fixed a couple of bugs, added the S meter function, voltage reading functions, TexNet handling and extended the command enable / disable switches with the 'command - D' syntax. Version X-1J release 3 was an interim version for testing. If you have it trade up to release 4 ! Version X-1J Release 4 fixed the buffer loss problem and implemented the automatic update of the ARP table by ARP REQUEST and ARP REPLY. The node also maintains a second heard list of L3 Netrom nodes the gateway through the node, and a bug in the copying of digipeated frames in KISS mode 2 has been corrected. A defensive port flush function has been added and link list integrity checking has been extended to check reverse links. A bug in handling of BBSALIAS, HOSTALIAS and DXCALIAS has been fixed as has the clearing of BBS, HOST and DXCLUSTER on cold start. The USER list shows circuit choke status for patchcord connections. If you read this and say 'Pah. it doesn't do XXXXX' or 'It still doesn't do YYYYY' or anything of a similar nature, don't keep it to yourself. Tell me. I may well do it. An example of this are the many changes introduced into X1-J as a result of suggestions mainly by KA2DEW. 7. The IP router The IP router co-exists in the node with the other software. It is connected to the L2 and L3(Net/Rom) protocol machines, and is managed from the L7 switch. It will accept data from L2 Datagrams, L2 Virtual Circuits or NOS protocol extended Net/Rom frames. It will output to these 3 depending on the setting of the IProute and ARP tables. The router supports the IP options of NOS and also does IP fragmentation. Level 2 segmentation is not supported. In addition, ICMP is implemented in so far as it is needed to respond to errors or PINGs. No higher layer support is provided, i.e. TCP is not implemented, ip_send() and ip_receive() are only implemented in so far as they are needed for ICMP. You can therefore PING it but anything else will solicit an ICMP error message. The default MTU is 256 for AX.25 and 236 for Net/Rom. It will accept longer datagrams than this and fragment the output but it is not recommended as it merely wastes RAM. The MTU command may be used to change this. It is possible to be creative in the use of L2 datagram and virtual circuits by use of the port default settings and the ARP table. The algorithm used is : When a frame is to be sent, the ARP table is scanned for the appropriate entry. The entry tells it what callsign to use. For Net/Rom encapsulation, it is sent to the Net/Rom protocol handler. For AX.25 encapsulation the following applies. The ARP table may indicate DG or VC. In this case, that mode is taken. If there is no DG or VC entry, the TOS bits are examined. If the delay bit is set, a datagram mode is selected. If not, and the reliability bit is set a virtual circuit is selected. If neither bit is set, the default mode for that port is used to select a mode ( see IPstats command, first parameter ). Port addressing is not supported at the moment. When a node stack is being used, it is possible to set all nodes or a subset of them to the same IP address. For more information, see the file 'IPXLINK.DOC'. The IP router is manually controlled - no rspf or rip. The node will manage its ARP table automatically now. See the section on the ARPtimer for more details. 8. MISC Anyone interested in a copy of the program, drop me a message on GB7MXM.#36.GBR.EU Also, any suggestions for change gratefully received. 9. The AEA PK96 This section describes the implementation of TheNet X-1J release 4 for the PK96. The PK96 version will not work in a TNC2 and vica versa. It is important to read this section as it describes the differences from the TNC2 version and how to install it in the PK96. The main documentation set reflects the TNC2 version !. In summary : The PK96 version does not have the ADC support and associated commands such as METER, ADC, ADC1 and ADC2. It does not include meter displays in the heard list. A command has been added to set the radio and RS232 port baud rates ( BRATE ) The software supports the hardware of the PK96 ( sic ) The RS232 DCDB ( pin 23 ) signal to control the crosslink protocol selection has been implemented using a hardware change to the PCB unless the PCB of the PK96 is version C or later. The MAIL LED gives a health check signal by flashing once a second The STA LED flashes whenever the node routes ( as opposed to sources or sinks ) a Net/Rom L3 or IP frame The rear panel push switch may be used to perform a coldstart 9.1. Rear panel push switch Pressing the rear panel switch will perform a coldstart. This may be done at any time other than straight after a reset when interrupts are ignored. The easy way to perform a warmstart is to switch the power off and on again. Be careful not to accidentally push the reset switch when the power is on ! 9.2. ROM differences All traces of the ADC have been removed. This also extends to the ROM parameters, and the default baud rates are stored in address offsets 0x151 and 0x152 in THENET1.X1J respectively. Please be sure to use the new patcher and the correct version of SETHELP. Using the PK96 commands on the TNC2 files or vica versa will corrupt the code. Also, note that bank switching is different with the PK96. No need for wires, just plug the EPROM in. The EPROM is the same 27C512 as is needed for the TNC2 version and it needs both files THENET1.X1J and THENET2.X1J in just the same way. Only THENET1.X1J needs to be patched with the ROM defaults however, and THENET2.X1J is 4K shorter as a consequence. The HELP text in THENET2.X1J may not however be 4 K longer. It may only extend to 0x6fff. The patcher therefore only modifies THENET1.X1J. 9.3. CROSSLINK selection The PK96 prior to version C of the PCB does not support the pin 23 RS232 mode selection signal for crosslink or dumb terminal mode. If you have version C or later, insert JP5 to connect the signal to RS232 pin 23. IMPORTANT - the signal goes directly to a CMOS gate input, so it must either be left open circuit ( for terminal mode ) or connected to GROUND ( for crosslink or KISS protocol mode ). Do not connect it to any other voltage. The easy way to ground it is to connect JP4 in the TNC which puts ground on pin 10. Connect pin 10 to pin 23 for crosslink, and remove the connection, JP4 or JP5 for terminal mode. If you have version B of the PCB it can be modified with a bit of care. To see if it is version B, take the cover off and look at the type number next to the power on / off switch. It should read something like 013-135 B The 'B' signifies revision B. If you want to modify it, proceed as follows. IMPORTANT - I suspect that your supplier will take a dim view of this with respect to the warranty. Your decision. 1. Find yourself an anti-static work area and use it. You will be soldering to CMOS inputs. 2. Switch off. Remove power cord and other cables. Remove the case by removing the four case screws (two down each side ), the RS232 connector mounting pillars on the back of the unit and the fixing ring for the audio connector jack socket, also on the rear. 3. Remove the battery link connector ( next to the battery ) and subsequently take care not to short circuit the battery. 4. Remove the 4 PCB mounting screws ( two at the front on each side, one near the DIN connector behind the reset switch, one at the site of the 5V regulator behind the fuse ). 5. Slide the PCB backwards to clear the LEDs and power switch from the front panel and lift it clear. 6. Locate pin 52 of the CPU. The CPU is the 64 pin device ( 0.07 inch pin spacing ) located between the 40 pin 8530 chip, the ROM and the RAM. It is denoted U1 on the PCB silk screen. This pin is connected to ground by tracks on both the top and the bottom of the board. Use desoldering braid or a desoldering tool to completely desolder it and carefully bend it up and out of the hole so that it can have a wire soldered to it. If you cannot completely desolder it, get a very fine screwdriver behind the pin on the top of the board and gently bend it out whilst applying minimum heat to the pin with a soldering iron from below. Do it carefully and the pin will come out without damaging the PCB tracks. 7. Locate pin 12 of U15. This is a 74HCT04 or similar located between the CPU, the 8530 and the modem disconnect header. Connect a short fine wire on the top of the board from pin 12 of U15 to pin 52 ( the one you bent out ) of the CPU. 8. Turn the board over. There is a short piece of track between pins 13 and 14 of U15. Cut it with a scalpel. 9. Connect a 10K resistor between pins 13 and 14. Keep it close to the board as you will need to replace the board in the case soon. 10. Locate pin 23 of the RS232 connector on the bottom of the board. ( remember that RS232 connectors number their pins along each row, so pin 23 will be third from the end nearest the power connector of the shorter row of PCB pins ). Connect a short piece of wire on the bottom of the board from RS232 pin 23 to pin 13 of U15. 11. Remove the EPROM and replace it with the TheNet EPROM. 12. Connect a short piece of wire from pin 10 of the RS232 connector to ground. A convenient point to use is one of the connector mounting points where the metal parts of the connector body are soldered to ground. 13. Replace the PCB in the case and refit the four mounting screws. Check that there are no shorts from the wiring to the case. 14. Connect a voltmeter to pin 52 of the CPU with the negative lead to ground. Apply power the TNC and switch on. All LEDs apart from the XMT LED should light and extinguish again if the node is working. The MAIL LED will then start to flash once per 2 seconds. The voltmeter should read low ( i.e. about 0 Volts ). Link pin 10 to pin 23 of the RS232 connector. The voltmeter should read 5V ( approx. ). If this does not work correctly, switch off and recheck it. 15. Switch off and remove the power lead. 16. Replace the battery link connector. 17. Check the PCB mounting screws are tight and replace the case. Replace the RS232 mounting posts, audio connector ring and all 4 case screws. 18. Reconnect the cables, switch on, and check it all works. 19. Go get a beer, wine, cup of tea, coffee or whatever else tickles your fancy. 9.4. Crosslink connections and other RS232 matters The RS232 connections differ to those of a TNC2. The RTS input controls whether the node can send data on the RS232 interface, and as there is no input on pin 20, it must be used for the crosslink handshake. Unfortunately, the crosslink handshake signals work the 'wrong way up' for the input, so it will be necessary to invert the signal into pin 4. This only applies if you have a diode matrix or similar active coupler. To crosslink 2 nodes just ignore the handshake signals. Finally, pin 4 will stop the node sending data to the RS232 port if it is grounded. It can be grounded by switching off a computer that drives this input. The effect is that data would be backed up waiting to be sent indefinitely. The node would eventually run out of buffers. To prevent this, a modification has been done to the code. Every ten minutes, the node checks to see if there was data to be sent and whether any was sent. If there was, and no data was sent, and if this also happened in the previous 10 minute period, it will purge the send list of all data waiting to be sent. It will also increment the 'port flush' counter. Just in case DCD gets stuck on ( this is not likely for the PK96 but can occur with some TNC2 clones and the code is also implemented in the TNC2 version ) the same process will apply to the radio port. The 'port flush' counters have been added to the STATS, at the end of the list. Two numbers are shown, the first being the counter for the radio port, the second for the RS232 port. Under normal operations, neither should increment. If a port gets stuck, then the counter for that port will increment every ten minutes for which the port has data to send and can't send it. Finally, the 64180 CPU in the PK96 does not have the capability to interrupt the CPU when the CTS line changes state. The code normally uses this to implement the crosslink CSMA protocol where a number of nodes share a common diode matrix connection. Instead the code polls the line status every 10 milliseconds. This means that it will not be very agressive in seizing the channel and other nodes will tend to get a bigger share of the channel. How well this will perform is not known - so if it gives problems let me know and I'll increase the polling speed - at the expense of processing power. A better alternative is to use one of the many active crosslinks that poll nodes in sequence. Dave G8KBB 7, Rowanhayes Close Ipswich IP2 9SX England