Net/Rom Node Information for the Sysop - Part Fourteen

by Andy Nemec, KB9ALN


This is part 14 of a series designed to help node Sysops learn more about the popular TheNet X-1J series of nodes. This month, we'll finish up our alphabetical exploration of these commands with the SYSOP, TALK, UI and USERS commands. While TALK and USERS are technically user commands, there are some additional features associated with these commands that you may want to be familiar with.

SYSOP

This command allows one to enter the Sysop mode to change node parameters. Node operating paramters can't be changed by users unless they enter into this mode. A sysop enters this mode by sending the appropriate password in the appropriate format.

First, a password phrase has to be worked out and "burned" into the EPROM that the X-1J firmware resides on. The password phrase can be nearly any combination of letters, numbers or printable symbols. No limit is specified on the length of the password, although 80 characters seems to be the limit. When picking the password, don't use characters that the node uses for command, like * ? / . , + or -.

Each letter of the password phrase is numbered. When the sysop prompts the node for the password by sending "SYSOP", the node returns with a set of numbers. If the Sysop sends back the appropriately numbered characters of the password phrase (this is case-sensitive, by the way), the node then allows Sysop commands to be accepted and acted upon.

There are two ways to make the password phrase virtually undetectable. First, choose a long one that is not real words. Second, you can send additional "fooler" characters between the legitimate password characters. The node scans the incoming text for the correct characters that can be embedded in text, in the correct sequence (not necessarily next to each other). We won't use any examples here, for obvious reasons. Consult the X-1J documents to learn more about this.

TALK

This is a nice conference feature that allows packet operators to engage in a "round table". To enter the talk mode, the user sends the phrase:

TALK

and the node responds with:

WX9APR-1:WAPR1} Entering Talk. Send /EX to exit.

Other participants will see your call sign and a message that you've joined them. Text from other stations is preceeded by their respective call-signs. When a station leaves this mode, a message informs the group of this fact. Unlike some converse bridges you'll find on BBSs and the like, there is only one conference "channel", used by everyone who is engaged in the "Talk" mode. That's the simple, straightforward way to use TALK. There is another way to use it, however.

You can send a broadcast message inviting other node users who aren't engaged in the conference session to join you. When you're engaged in the session, type:

TALK Conference in session, if anyone wants to join in, type 'Talk'

Anyone who is connected to the node but idle will see the message.

There are some limitations to this conference feature, however. First involves the number of users that can successfully engage in the conversation. This seems to be limited to about 4 or 5 at 1200 baud, depending on the settings of timers on the participant's TNCs. There is simply not enough time to send and acknowledge every packet sent in a typical keyboard conversation before the appropriate timers expire and the connection is closed. For that reason, it's best to suggest to your users that they use the TALK feature at off-peak times.

Another limitation is the text buffer. Anything past the 80th character will be dropped into the "bit bucket". For those terminal and packet programs that do not have "word wrap", this may present a problem. You may want to tell your users to change their "Paclen" to 70 or so. Also suggest that they find the command to add a Carriage Return/Line Feed character to each packet. This is necessary for the node to know how to format the text.

UI

This is another user command that is useful for the sysop to know about. UI allows a connected user to send an unproto packet through the node. The packet appears as another SSID of the user. This can be good for sending out a LAN-wide announcement or invitation for a connection. This command, like most user commands, can be disabled from the sysop mode with:

UI -

Likewise, it can be enabled with:

UI +

All text intended to be sent out as UI needs to end with a Return (Carriage Return/Line Feed), or it won't be sent.

USER

This command is a user-level command from which Sysops can get some useful information. When the User command is given, you may see something like this in return:

WAPR1:WX9APR-1} TheNet X-1J4 (633)

Uplink (WX9ABC)
Downlink (WX9DEF)
Circuit (WAPRBBS:WX9APR KB9ALN)

First, you see that the node firmware version is displayed along side the node's call and alias. Secondly, you see the type of connection, "Uplink", "Downlink", or through "Circuit". In the above example, you see that WX9ABC is connected to WX9DEF through the node, and that KB9ALN is connected to WAPRBBS through the network, using this node as one of the links. Normally, you'd see something like this.

However, there is something else you may see from the User display, the node's "Choke" status. A node connection is "Choked" when there is data waiting to be sent, but can't be accepted by the destination station or node for one reason or another.

In uplink or downlink situations, you will see the letter "C" next to the choked station or node. For circuit connections, you will see something like this:

Circuit (WAPRBBS:WX9APR <----+> GRBBBS:KB9ALN)

Notice the + sign? This means that the connection to GRBBBS is choked on that end. In reality, this isn't always a + sign, it can be some other character. The importance is the difference between the --- and some other character. If there is a different character on both ends, then the connection is choked on both ends.

This can be very useful when trying to find the cause of slow connections. One choked node can slow an otherwise good network path. Choking can also be caused by a poor path, of course. Or it can be caused by a "slow" or faulty TNC.

That's all for our alphabetical exploration of the Sysop commands for these nodes. Next time, we'll explore what is needed to set up a node for TCP/IP operation. Until then, 73 from Andy.

Coming Soon: Node Operator TCP/IP Information

Back to the Node Sysop Information Index

Back to the WAPR Home Page