NOSintro – TCP/IP over Packet Radio

An Introduction to the KA9Q Network Operating System

by Ian Wade, G3NRW



In the AX.25 PBBS world, it’s common for users to run their own personal messaging system (PMS), with automatic forwarding in both directions between the PMS and a local PBBS. People can log into the PMS, but they can only leave private messages there for the PMS owner.

In the NOS world, you also have a personal messaging system. Here it is called the NOS BBS, and is very much more powerful and flexible than an AX.25 PMS.

You can login to your own NOS BBS with the bbs command, and into a remote BBS with the telnet command. Ordinary AX.25 users can also login to the NOS BBS, simply by connecting to the station in the usual way.

The NOS BBS comprises six main parts:

The Mailbox Server

The Built-in NOS Mailer

File Server

Gateway Server

Finger Server

Remote Sysop Server


See Fig 18-1.

The mailbox server contains a command interpreter which understands simple one- or two-letter commands to invoke the BBS services.

The NOS mailer lets you create, send and receive mail. You can transport mail to other NOS stations using the SMTP protocol, and collect your mail using the POP protocol. You can also forward and reverse-forward mail to and from the conventional AX.25 PBBS network.

Fig 18-1: The NOS BBS. The individual capital letters in the boxes (e.g. A L R V K S) are BBS commands.


The file server lets you upload and download files, and, if you have permission, delete them also. File transfers are in 7-bit format. If you want to transfer 8-bit binary files, it’s necessary to encode them into 7-bit format first. The file server is really intended for AX.25 users who connect to the BBS — NOS users would normally use FTP instead.

The gateway server lets you make outgoing AX.25, NET/ROM and TELNET connections to other stations. The server is likewise intended for AX.25 users, so that after connecting to the BBS they can then initiate a new connection to another station, possibly on another network. The server also provides a chat facility, letting you talk direct to the sysop.

The finger server is also intended for AX.25 users, letting them read the finger files on the system; NOS users would normally use the finger command instead.

The remote sysop server lets you communicate directly with the NOS Session Manager on the system, giving you the power to do almost anything. This is particularly useful if you need to change settings on a difficult-to-get-to hilltop system, for example, without physically having to go there. For security reasons you need to have the sysop permission in the ftpusers file on the remote system, and you may also have to give an additional password, before you can go ahead and do your worst.


Mail Handling

Fig 18-2 shows the principal building blocks for handling mail within NOS. Starting at the top of the diagram, the main steps in composing, sending and receiving mail are as follows:

BBS Login

Composing Mail

Forwarding Mail with the SMTP Client

Receiving Mail with the SMTP Server

Reading the Mail

POP Mail Collection

PBBS Forwarding


BBS Login

There are several ways of logging into the BBS, depending on whether the BBS is local or remote, and whether the connection to the BBS is made via telnet or ordinary AX.25.


Fig 18-2: The NOS BBS and PCElm external mailer.

To login to your own built-in BBS (see Fig 18-3 below), give command:

net> bbs

Alternatively, if you prefer to use an external mailer, the command to start the mailer is:

net> mail

Note that before starting NOS and giving the mail command, you must set up the DOS environment variable MAILER, to specify which mailer you want to use. For example, in NOSENV.BAT:


You can even run an external mailer independently of NOS if you wish. For example, at the DOS prompt:




Fig 18-3: Logging in to your own NOS BBS (or external mailer).

To log into a remote BBS (Fig 18-4 below), you will normally use the telnet command; e.g.

net> telnet ns9ken

When you use telnet (or bbs), NOS will ask you for a user name and password. These must match an entry in ftpusers. If you can’t provide a suitable name and password, you could try connecting to the BBS with the AX.25 connect command instead. For example:

net> connect tnc0 NS9KEN-5

This sets up an ordinary AX.25 connection, and NOS will not ask you for a login name or password.

Ordinary AX.25 users can also connect to the NOS BBS, and AX.25 PBBS mailboxes can connect when they have mail to forward to the BBS.


Fig 18-4: Logging in to a remote NOS BBS (using telnet or an ordinary AX.25 or NET/ROM connection).

Composing Mail

Once logged in to the BBS, you can then give commands to the mailer (see Fig 18-5). To compose a message for sending, you use a command like:

NS9BOB-5} sp ns9liz@ns9liz

When you have finished preparing the message, you terminate it with CTRL-Z, in a similar way to conventional PBBS mailbox systems. The NOS mailer then checks to see if it is a bulletin which it has already received (the file /spool/history contains details of all received bulletins).


Fig 18-5: The mailer puts the message into the outgoing mail queue (/spool/mqueue).

Also, if necessary, the mailer converts the destination address into a more suitable format (by reference to the file /spool/rewrite) the history and rewrite files are described later. The mailer then places the message in the outgoing mail queue, in directory /spool/mqueue, and wakes up the local SMTP client.


Forwarding Mail with the SMTP Client

The SMTP client takes the message from the outgoing mail queue, and attempts to forward it to its destination (Fig 18-6).


Fig 18-6: To forward the mail, the SMTP client connects to the addressed SMTP server. This may be a local server (for local mail), or a remote server across the network. The smtp kick and smtp timer commands bring the SMTP client to life.

If the destination is on a remote system, the SMTP client will make a connection with the SMTP server on that system. If the message is addressed to a user on the local system, the SMTP client will make a direct connection with the SMTP server on the same system.

Normally the SMTP client attempts to forward messages as soon as the mailer places them on the outgoing mail queue. However, if the attempts are unsuccessful, the client will try again at regular intervals — you can set up the retry interval with the smtp timer command.

Sometimes you may find that the SMTP client appears to have gone to sleep for too long (it doesn’t seem to be forwarding any messages). In this case you can give it a nudge with the smtp kick command.


Receiving Mail with the SMTP Server

The SMTP server listens continuously for incoming connection requests from local and remote SMTP clients (again, see Fig 18-6). When a connection is made, the client passes the message to the server. The server then checks to see if the addressee has an entry in the file /alias. If there is an alias, it is expanded; depending on the alias entry, this may result in several copies of the original message.

The server then places the original message (and any copies) into the appropriate queue. Messages to be sent onwards to another station go back into the outgoing mail queue, for forwarding by the SMTP client.

Messages intended for local users go into the incoming mail queue (by default, in directory /spool/mail), and a message pops up on the screen saying that mail has arrived.

Each message goes into a text file in the incoming mail queue. There is a separate file for each addressee; for example, all mail addressed to ns9bob goes into file /spool/mail/ns9bob.txt, mail addressed to tcpip goes into /spool/mail/tcpip.txt, and so on.


Reading the Mail

To read incoming mail, you first have to select the correct mailbox area. The default mailbox area name is the same name that you used to login to the BBS. If you logged in as ns9bob, the default area is ns9bob, which means that you can read all messages in /spool/mail/ns9bob.txt (using the BBS R command).

If you logged in via an AX.25 connection (and therefore did not provide a login name or password), the default area is your callsign.

The file /spool/areas defines public areas to which you are allowed access (in addition to your default area), and you can switch to any of these areas with the BBS A command.

For example, the BBS command A TCPIP (or a tcpip) switches you to the tcpip area, and then you can read all the messages and bulletins in /spool/mail/tcpip.txt (see Fig 18-7).

You can only switch to areas listed in the areas file, plus your own private login area. If you want to see the private mail of another user, you have to login first as that user.


Fig 18-7: Reading the mail. The file /spool/areas specifies public bulletin mailboxes.


POP Mail Collection

Normally, mail delivery to a remote host takes place automatically, provided that the remote host is actually switched on and ready to receive it. In many instances, however, this will not be the case — many people shut down their systems when they are not actually using them. This can lead to network overload, where a machine makes repeated attempts to forward mail which can never succeed.

A solution to this problem is to nominate a machine as a "poste restante" — a system which will hold mail indefinitely for people, and which will only deliver the mail when those people wake up and ask for it. See Fig 18-8.

The poste restante machine arranges for such mail to go into the incoming mail queue in .txt files. The POP server on this machine listens continuously for requests from POP clients on neighbouring machines. When it receives a POP request, the server checks the user name and password against the file /popusers, and if they match, the server transfers the corresponding .txt file across the network to the client.

The POP client on the receiving machine then deposits the file in the incoming mail queue, and displays a message on the screen saying that the mail has arrived.


PBBS Forwarding

Mail for forwarding onto the PBBS network is handled specially in NOS. Irrespective of whether you create messages locally for PBBS forwarding, or whether they come into the system from another machine, they eventually find themselves in one or more .txt files in the incoming mail queue. See Fig 18-9.

On their journey to the incoming mail queue, the destination addresses for the messages will probably be changed, by reference to the rewrite file. PBBS addressing rules are quite different from SMTP, varying considerably throughout the world, and the rewrite file serves as an address swap file — it contains all the necessary rules for converting addresses into formats which the PBBS network will understand.


Fig 18-8: POP Mail Collection. Mail for ns9liz resides in Bob's incoming mail queue awaiting collection. When Liz is ready to collect the mail, her POP client connects to Bob's POP server, which then forwards the mail. The file /popusers in Bob's system authenticates Liz's POP request.


At regular intervals, the mailbox client wakes up and examines the file /spool/forward.bbs, to see if the time is right to forward PBBS mail. You can define different timeslots in forward.bbs for different PBBSs if you wish. If there is any outstanding PBBS mail in the incoming mail queue when a timeslot becomes valid, the mailbox client connects to the designated PBBS and then forwards the mail to it.

After forwarding any mail to the PBBS, the roles are then reversed and the PBBS forwards any outstanding mail that it has for the NOS system.

You can define the mailbox client scan interval, using the NOS mbox timer command. If you want to force the client to forward mail immediately to a PBBS, you can use the NOS mbox kick command.

Fig 18-9: PBBS forwarding. Mail for forwarding onto the PBBS network resides on the incoming mail queue. The file /spool/forward.bbs specifies when the mailbox client is to forward the mail, and to which PBBSs it is to go. The mbox kick and mbox timer commands bring the mailbox client to life. When forwarding is complete, any outstanding mail on the PBBS is reverse-forwarded to the NOS system.


Back to Contents Page

Back to NOSintro Main Page.

[Copyright 1992-2009 Dowermain Ltd. All Rights Reserved. This page last modified: 21 May 2009]