NOSintro – TCP/IP over Packet Radio

An Introduction to the KA9Q Network Operating System

by Ian Wade, G3NRW



This chapter provides a brief overview of the KA9Q Network Operating System (NOS).

NOS is a multi-tasking operating system that provides an extremely flexible and powerful set of communications services for use on packet radio networks, telephone lines and local area networks. NOS supports most of the commonly used Internet protocols such as TCP, IP, TELNET, FTP, SMTP and so on, plus the packet radio protocols AX.25, NET/ROM and PBBS mail.

With NOS you can communicate with virtually any kind of computer (Fig 4-1). An Amstrad can talk to an Apple, an Amiga can talk to an IBM mainframe, a laptop PC can talk to a Cray, and so on. What’s more, you can send electronic mail via worldwide networks, and you can even log into remote systems, just as if you were directly connected to them.

NOS supports the AMPRnet (Amateur Packet Radio network), which rides on the back of the Internet protocols. These protocols are operating system independent. This means, for example, that you can run NOS on a PC running DOS or UNIX/XENIX, or a DEC VAX running VMS, or a Sparc workstation running SunOS. You can send binary or ASCII files between them, handle mail, and set up gateways to link different types of network.

Probably the most important aspect of NOS is that all of these protocols and services conform to internationally agreed standards, and are available in one form or another on virtually every micro, mini and mainframe system in use today. This means that you are not locked into non-standard software (such as YAPP or 7PLUS) that nobody outside the amateur world understands, and you can communicate with almost any type of computer in the world in exactly the same way. NOS is truly an Open System.

Fig 4-1: NOS provides connectivity with AMPRnet, Internet, NET/ROM and AX.25

There’s more. As well as supporting TCP/IP and AX.25, NOS also understands NET/ROM. You can even set up your own NET/ROM node if you want to.

Why support NET/ROM? Well, in the ideal world, all NOS systems would talk TCP/IP directly to each other, and would handle node-to-node routing at the IP level. Unfortunately we have yet to reach this ideal state, so in most cases we have to rely on existing networks to carry our TCP/IP traffic instead. The most widespread packet radio network which already exists is NET/ROM, so that is why NOS supports it.

Thus when you monitor TCP/IP traffic, you may see AX.25 frames which contain NET/ROM packets which contain IP packets which contain TCP packets — see Fig 4-2. Sounds complicated, but once you’ve read this book you’ll see that it’s really quite straightforward to set up, provided you keep a clear head and understand the functions of the different network layers.


Fig 4-2: A Multi-protocol NOS Packet.


And there’s even more. NOS also supports PBBS forwarding and reverse forwarding, allowing us to communicate with the established PBBS mail network. NOS stores the PBBS mail files in the same directories as TCP/IP mail files, and you can read and send mail in either format.

Thus we have the best of both worlds. We can choose to send our mail either via the AMPR network or via the AX.25 PBBS network, and we can read mail from both of those networks as well.


Fig 4-3: NOS — The Big Picture

The Basic Requirements

To run NOS in a DOS environment, you need the following:

a PC

a tnc capable of KISS operation (most are today)

a copy of the NOS software

NOS documentation (e.g. the NOSview documentation package)

an Internet (IP) Address.


The PC can be almost any model in the 80x86 family, with at least 1MB of memory. Obviously the machine should be the fastest you can afford, at least 8 MHz. With a full set of run-time software and on-line documentation, you will need about 2.5MB of hard disk space (although you can run a bare-bones system on a laptop with just dual 720K diskette drives at a pinch).

NOS software and full reference documentation are available in the NOSview package, already described in the Chapter 2.

Internet addressing is explained below.


The Internet Protocols

Figure 4-3 opposite shows the main building blocks of NOS. The two networking protocols at the heart of NOS are the Transmission Control Protocol (TCP) and the Internet Protocol (IP), at the bottom of the diagram. These protocols were developed under the aegis of the Defense Advanced Research Projects Agency (DARPA) in the United States, and have been in general use in data networks throughout the world for many years.

However, the raw TCP and IP protocols are not of very much interest by themselves, at least not while you’re still learning how to set up NOS. Much more important are the network services that use TCP/IP, which you will use to transfer files, send mail and so on.

The five main classes of network services which you will use are (again see Fig 4-3):


Remote Login

File Transfer


Network Connectivity



The chat service lets you do just that, using the NOS command ttylink (or chat in some versions of NOS). Thus if you want to chat to NS9KEN, you give the command ttylink ns9ken, and once you are connected you can converse in exactly the same way as in vanilla AX.25. NOS saves keystrokes in a buffer as you type, and then transmits the buffer when you hit CR.


Remote Login

There are two different remote login services provided in NOS. The one you are most likely to use is TELNET. When you give a command such as telnet ns9ken, you will normally be connected to his NOS BBS, where you can read and send mail, and use various network gateways if you have permission.

The alternative login service is rlogin. This command lets you perform a login to a remote computer which supports the RLOGIN protocol.


File Transfer

The NOS command for file transfer is ftp. To transfer files between your system and NS9KEN’s system, you give the command ftp ns9ken, and when you are connected you can give the get command to fetch a file from NS9KEN (e.g. get yourfile.txt), or use put to send a file to NS9KEN (e.g. put myfile.txt).

You can transfer ASCII or binary files, simply by giving the ascii or binary command before starting the transfer. You don’t need to worry about lost packets or duplicate packets; FTP takes care of error detection and correction, so when the transfer is done you can be confident that it was successful.



The basic function of a mailer program is to let you compose messages and bulletins ready for forwarding, and to read incoming mail. There are no less than four mailers which you are likely to come across in NOS systems:






The first three of these mailers are not actually part of NOS, but are separate programs which you can call from NOS when you want to access your mailbox. Alternatively you can use them completely independently of NOS, starting them from the DOS command line.

The fourth mailer, the NOS BBS, is built in to NOS, and has several extra features in addition to handling mail.

Why so many mailers? It’s really a matter of history. In early versions of NOS there was no built-in mailer, and BM ("Bdale’s Messy Mailer" from N3EUA) was provided instead. This had very basic functionality and was cumbersome to use, but it served its purpose at the time.

Next in line came ELM, which provides a much nicer full-screen menu environment. With ELM you can compose mail using your favourite text editor, include files in your messages, set up mailing lists and so on. Many people use this mailer today.

PCElm is a more recent mailer which looks and works very much like ELM, but is in fact unrelated. As well as providing all the facilities of ELM, PCElm also has a built-in text editor and lets you set up screen colours, define message file name extensions and delimiters, filter out unwanted message headers and so on.

The built-in NOS BBS contains a simple mailer which works in a very similar way to the familiar AX.25 PBBS. You give commands like L to list mail, SP or SB to send it, R to read it and so forth. However, the NOS BBS also provides a set of gateway commands which let users break out into the NET/ROM network or telnet into another NOS BBS, or even take over control of your station as a remote sysop — but you’ll be glad to hear they can’t do any of these things unless you give them permission!

Use of the NOS BBS is not restricted to TCP/IP users. An ordinary AX.25 user can connect to your NOS BBS, read and send mail just like a TCP/IP user, and can use the gateway commands as well if they have permission. In other words, this gives an ordinary AX.25 user the capability of accessing the NET/ROM network and AMPRnet if they want.

So which of these four mailers do you use? If you are logging into someone else’s system, you have no choice: the built-in NOS BBS on that system is the only mailer you can access. On your own system you can use the NOS BBS if you want, but you’ll probably prefer to use PCElm (or perhaps ELM) as it has a much nicer user interface.


Mail Forwarding

The main function of the mailers just described is to let you read and compose mail. To send and receive this mail, NOS provides three mail forwarding services:

Simple Mail Transfer Protocol (SMTP)

Post Office Protocol (POP)

AX.25 PBBS Forwarding


SMTP handles the sending and receiving of mail via AMPRnet, and is the default method of handling mail. Using SMTP you can transfer mail between any computers which understand it; i.e. virtually any kind of machine in the world.

POP is the reverse forwarding protocol that works with SMTP. With POP you can nominate another machine as your Post Office, and when you run POP, your own machine will automatically login to the Post Office and collect any mail waiting for you.

AX.25 PBBS forwarding and reverse forwarding is fully compatible with the PBBS network, so if you don’t have access to a local NOS system which can forward your mail using SMTP, you can still communicate with the outside world via the PBBS network.

Network Connectivity Services

NOS provides a number of network support services which let you check the availability of other stations on the network. These services include ping and hop.

The ping command is known officially in the trade as the "Packet Internet Groper" (... amazing but true!), and is useful when you’re not sure if a local station is responding to your traffic. Whenever you want to check if a local station is active, you "ping" it; e.g. ping ns9ken. If NS9KEN is running NOS, it will respond to your ping, and you will see on the screen a number representing the round-trip time for your ping packets. If you get no response, or if the round-trip time is unexpectedly long, you know that something is wrong.

The hop commands let you check the availability of routes to a particular station. For example, to find out which gateways your packets pass through to reach NS9LIZ, you would give the command hop check ns9liz. This is very useful to verify that a route exists to the target station — and can sometimes show up some bizarre routings that you never knew existed!


Station IP Addresses

Every NOS station has an IP address, a unique 32-bit number which is usually expressed as four decimal numbers separated by dots (the so-called "dotted-decimal" notation). For example, NS9BOB’s IP address in this book is

The first byte is always 44, which represents the AMPRnet.

The second byte (199) usually represents a country (or a state in the United States).

The third and fourth bytes are an address within that country. Typically the third byte will represent a region or area, and the last byte will be a station number in that region.

Incidentally, you may see some documentation which shows IP addresses enclosed in square brackets; e.g. []. This convention is a relic of early NOS systems, and is not used today.

Each country or state where there is AMPRnet activity has a local IP address coordinator who allocates addresses on request. A list of coordinators is shown in Appendix 5. You should contact your local coordinator listed in the appendix to get an address. If your country does not yet have a coordinator, you should contact the international coordinator in the United States instead (but be prepared — he will probably nominate you as the country coordinator!).

From time to time the coordinators issue a full list of IP addresses in their area, as a set of bulletins on the PBBS network. When you set up your NOS station, you will use this list to create the file domain.txt, which NOS uses whenever you make a network connection. (Strictly speaking, you don’t really need to have a domain.txt file — you could use IP addresses instead of symbolic hostnames; e.g. you could give the command ping instead of ping ns9ken, but obviously it is more meaningful to use names rather than addresses).

Keeping domain.txt up to date is clearly a problem. One way round this is to nominate a local station as a Domain Name System (DNS) Server, which keeps a master copy of the file and makes it available to other users. (This is somewhat similar to a PBBS White Pages server, which keeps a record of AX.25 stations and their local mailboxes). If you then set up NOS to use the DNS server and attempt to make a network connection, NOS will first look in your own domain.txt file for the hostname you have given. If it can’t find the hostname there it then automatically make a request to the DNS server machine for the IP address of the station you are trying to contact.


Address Resolution Protocol

When setting up a network connection, NOS needs to know not only the IP address but also the link address of the station you wish to talk to. If you are using a radio link, the link address is the other station’s callsign (e.g. NS9KEN-5). If you are on Ethernet, the link address is the 48-bit hardware address of the Ethernet adapter card in the other station’s PC (e.g. 00:00:C0:AC:01:26).

To set up the table of link addresses, NOS provides the arp (Address Resolution Protocol) set of commands. Thus, for example, to communicate with NS9KEN, you could give a command such as arp add ns9ken ax25 NS9KEN-5, thus forming an association between the IP hostname (ns9ken) and the link address (NS9KEN-5).



Routing controls how packets get to their destination. NOS supports no less than three completely independent levels of packet routing:

AX.25 routing

NET/ROM routing

IP routing


You’ll already be familiar with AX.25 routing, particularly when it’s referred to by its more usual name: digipeating. NOS has a set of ax25 route commands which let you set up digipeater paths to nominated destinations.

For example, to route packets via digipeater AX9DGC to reach NS9PAM-5, the NOS command to set up the AX.25 routing table entry will be ax25 route add NS9PAM-5 AX9DGC.

Similarly, there is a set of netrom route commands, with which you can set up NET/ROM routes and aliases which ordinary NET/ROM nodes understand.

IP routing is basically an extension of the NET/ROM routing idea, specifically for forwarding IP packets onwards to their final destination. NOS has a set of route commands for setting up and maintaining the IP routing table.

Each of these three levels of routing is quite independent of the other two.


Routing Table Updates

In the amateur packet network, nothing lasts for ever — or even for a lot less time than ever! Routes between nodes are continually changing as stations come and go, as frequencies change and so on. This means that for there to be any realistic chance of communicating with other users on the network, your station has to be kept up-to-date with the current routing situation.

NOS achieves this in two ways. Firstly, it listens to user traffic on the frequency, and when it hears stations it dynamically updates the appropriate routing tables. These updates remain in memory for a finite period (usually measured in minutes or tens of minutes), and if a station is not heard again the routing information for that station eventually disappears.

The second way that NOS keeps up-to-date is by routing broadcasts. NOS regularly sends broadcasts of the NET/ROM routing table in just the same way as a native NET/ROM node, and also sends IP routing table broadcasts at regular intervals.

For IP routing broadcasts, NOS supports two protocols: RIP (Routing Internet Protocol) and RSPF (Radio Shortest Path First) protocol. RIP is the protocol to use if your station is part of a well-established and stable network such as Ethernet, whereas RSPF works better in a dynamic radio environment.


Wormhole Routing

Another method of packet routing supported by NOS is the wormhole, which provides AX.25 connectivity over a TCP/IP link. This is useful where you are linking two AX.25 stations via an Ethernet or telephone connection. In effect, the NOS wormhole acts just like a (rather complicated) digipeater — see Fig 4-1 opposite.


Interface Support

NOS is noted for its very wide range of supported interfaces (although not every version of NOS will support all of them). These include:

The serial ports (COM1 - COM4), for tncs or modems

Modem control

Ethernet adapters

Clarkson drivers

Baycom AX.25 driver

DRSI PCPA 8530 card

HAPN 8273 adapter

High speed DRSI/HAPN driver

Eagle 8530 card

NET/ROM control

Single- and multi-port KISS TNCs

PACcom PC100

Fig 4-4: The AXIP wormhole lets AX.25 users communicate over AMPRnet.

In other words, NOS will talk to virtually any tnc or modem, or any of the well-known network adapters. The Clarkson drivers are freely available as public domain software, and support all of the generally available Ethernet and Token Ring LAN adapters.

NOS talks a number of low-level protocols via these interfaces:

KISS for tnc control

SLIP and PPP for serial point-to-point telephone links

NRS for NET/ROM control

Ethernet and ARCnet for Ethernet adapters


The NOS Session Manager

Because NOS is a multi-tasking system, you can run many sessions in parallel. Hence it’s possible, for example, to telnet to NS9KEN, do file transfers with NS9LIZ, access your own mailbox, ping NS9BOB and have a chat with AX.25 station AX9AAA, all at the same time. In principle you can run many more sessions as well, but you’ll really need a Jekyll and Hyde personality to handle it all!

The NOS Session Manager maintains a virtual screen and keyboard for each session, and you can hot-key from session to session at will. You can find out the status of any session on demand, and you can trace all the traffic flowing through your station, right down to the hexadecimal byte level if you want to. You can also record any session on disk for later use. Furthermore, you can allow other stations to drive your Session Manager remotely if, for example, your station is on a remote hilltop site.


That’s NOS

By now it will be clear that NOS is a very complex package, with many advanced features which make it usable in a wide variety of environments. To the beginner, some of the features in NOS may appear to be daunting, but fortunately it isn’t necessary to understand everything before you can use it.

Just like when using a tnc for the first time, you can get away with using default setup parameters; performance may not be optimum, but it will at least work. Then as you gain experience you can dig deeper into the software and start to experiment with different configurations.

Driving NOS is a bit like driving a car. Think of the network protocols (TCP, IP, SMTP and so on) as the engine, and think of the network services (like TELNET and FTP) as the brakes and steering. To drive NOS (the car), you have to know about TELNET and FTP (the brakes and steering), but learning about TCP and IP (the engine) can wait until later.

With NOS, all you really need to know at first is how to set up the tnc, how to configure the address and routing tables, and how to use the basic network services to transfer files and handle mail. Fine tuning of the network protocol parameters can wait until much later.


Back to Contents Page

Back to NOSintro Main Page.

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