NOSintro – TCP/IP over Packet Radio

An Introduction to the KA9Q Network Operating System

by Ian Wade, G3NRW



Most amateur packet radio systems use a terminal node controller (tnc) to interface the computer to the radio (Fig 6-1). The tnc is basically a Packet Assembler/Disassembler (PAD), with a built-in modem to convert outgoing digital bit streams into audio tones suitable for modulating the radio transmitter, and to convert incoming audio from the radio receiver into digital data for the PC.


Fig 6-1: The Terminal Node Controller contains a packet assembler/disassembler (PAD) and modem.


[As an alternative, some people are now using the Baycom modem for packet radio. In this case, the PAD functionality is implemented in a special software driver which you load into memory before starting NOS].

This chapter examines briefly what is inside a tnc, and the various modes it can operate in.


TNC Modes

The tnc can operate in three different modes:

Native mode

Host mode

KISS mode


Native Mode

Native mode is the mode for which the tnc was originally designed. As its name implies, the tnc controls a terminal node on the packet network, and when operating in native mode you don’t even need a computer; a dumb terminal is enough.

When the tnc starts up it displays the familiar cmd: prompt on the terminal, and you can then give around 80 commands to start and stop connections, monitor network traffic, send and receive mail, and so on.

All of these operations are controlled by firmware within the tnc (Fig 6-2). The firmware has five main components:

Command interpreter

TNC control

Packet Assembly/Disassembly

Radio Control

Personal Messaging System


Command Interpreter:   The command interpreter directs user commands to the other firmware components.

TNC Control:   This component understands dozens of commands to set up the tnc; e.g. uart control, terminal link flow control, clock initialisation, callsign setup, etc, etc.

Packet Assembly/Disassembly:   This is the major component of the tnc firmware, handling the connection and disconnection of AX.25 virtual circuits, AX.25 timers, digipeater routing, beacons, network monitoring, packet sequencing/flow control and HDLC frame assembly/disassembly.


Fig 6-2: The tnc in native mode. All packet handling takes place inside the tnc.


Radio Control:   This component supports the radio-dependent aspects of the tnc, such as TXDELAY and other timers, persistence count and so on.

Personal Messaging System:   The PMS is a simple messaging system that stores personal messages which people have sent to you.

These tnc functions are only briefly listed here, simply to allow us to compare native mode operation with host mode and KISS mode. If you want to find out more about native mode, the book Your Gateway to Packet Radio by Stan Horzepa is highly recommended (details in Appendix 6).


Shortcomings of Native Mode

When the first tncs were designed in the early 1980s, the goal was to give users the opportunity to get into packet radio with the minimum of equipment. Together with just a dumb terminal and a radio, you had everything you needed to make AX.25 network connections, chat interactively with your neighbours, and send and receive short personal messages.

But that was all. If you wanted to do more adventurous things like file transfers, or set up a store-and-forward bulletin board, or set up a network switch, you had to replace the dumb terminal with a PC.

To do these things properly, the PC has to be in control of the packet station, not the tnc. But with the firmware which existed in the early tncs, it was the tnc that was in charge of proceedings. The tnc decided when to send a message to the PC, and what format the message was in. Incoming status messages got mixed up with user data, and the file transfer was a hit-and-miss affair.

The basic difficulty was that the tnc’s user interface had been designed for people, not computers. Human users were not greatly troubled if status messages arrived at random times in different formats, and were mixed up with data, but programming a PC to cope with all these possibilities was a nightmare.

To overcome these shortcomings, host mode was introduced.


Host Mode

In host mode (Fig 6-3), the tnc is like a well-behaved child — it only speaks when spoken to! The PC is now in charge of proceedings, and commands and responses across the serial link are in simple, consistent formats which are easy to program. The PC only asks the tnc for information when it is ready to receive it.

This makes it much easier to display session status, switch between multiple data streams, and so on. Programming network services such as file transfer and bulletin boards is now straightforward, and more flexible — it’s much easier to change software in the PC than to change firmware in the tnc.


Fig 6-3: When the tnc operates in host mode, the PC is in control. The PC handles the higher level functions such as the Personal Messaging System, multiple streams and split-screen operation. The tnc still handles low-level packet assembly/
disassembly, however, and is still restricted to AX.25.


However, in host mode, most of the low-level packet handling still takes place within the tnc. This is fine for AX.25 virtual circuits, but not suitable for other protocols such as TCP/IP. What’s really needed is the capability of the PC to control the content of frames at the lowest level. This is what you get when the tnc operates in KISS mode.


KISS (Keep it Simple, Stupid!) Mode

When the tnc operates in KISS mode, almost all of the station’s functionality takes place within the PC (Fig 6-4). The PC provides the high-level network services for file transfer, bulletin boards and so on, together with lower level protocol software which has access to every HDLC frame that enters and leaves the tnc.


Fig 6-4: In KISS mode, the tnc handles all frame types. NOS in the PC contains a complete set of AX.25 software (replacing the tnc AX.25 firmware), together with support for all the AMPRnet protocols and NET/ROM.

This means that it’s now possible to control exactly what goes into each individual HDLC frame, making it straightforward to multiplex several different protocols over the same radio link. The downside, of course, is that these protocols have to be implemented within the PC — this makes it necessary for NOS to contain a complete set of AX.25 software which completely replaces the AX.25 firmware in the tnc.


The KISS Protocol

To communicate between the PC and the tnc, the KISS protocol is used. This is a very simple asynchronous packet protocol, whose main purpose is to provide an envelope for HDLC frames (Fig 6-5). Each frame starts and finishes with a Frame End (FEND) character. There is no checksum or CRC.


Fig 6-5: KISS Frame format. When a frame reaches the tnc, the FEND and KISS type bytes are removed, leaving the original packet for transmission.

Immediately following the leading FEND character is a KISS type byte. The low-order 4 bits of this byte contain a control code.

If the code is 0, this is a data frame, and the high-order 4 bits specify the tnc port number (0-15) for which the frame is applicable.

If the control code is non-zero, the frame contains a tnc setup command.

The KISS link is set to 8-bit data, one stop bit and no parity. If a frame happens to contain a data byte which looks like a Frame End character, the byte is replaced with a 2-byte Frame Escape/Transposed Frame End (FESC/TFEND) sequence. If a frame contains a FESC, this is replaced with a 2-byte Frame Escape/Transposed Frame Escape (FESC/TFESC) pair.


0 Data Frame

1 TX Delay (x 10mS)
2 Persistence (0-255)
3 Slottime delay (x 10mS)
4 TX Tail (x 10mS)
5 0=half duplex, 1=full duplex
6 Hardware dependent
7 TX mute
8 0=DTR low, 1=DTR high
9 0=RTS low, 1=RTS high
10 Baudrate
11 End delay
12 Group
13 Idle
14 Min
15 Max key
16 Wait
17 Parity: 0=none, 1=even, 2=odd
129 Down
130 Up
254 Prepare to switch tnc from KISS to native mode
255 Switch tnc from KISS to native mode

Table 6-1: KISS Control Codes (expressed in decimal). Most of these codes are tnc-specific. Only codes 0–3, 5 and 255 are understood by all tncs.

When a KISS frame arrives at the tnc, the FEND characters and KISS type byte are stripped off, and any escaped characters are replaced with their original values. Then, if the frame is a data frame, it is passed to the HDLC controller chip for transmission.

If the frame is a tnc control frame, the tnc executes the command specified in the KISS type byte. Some of the commands require additional parameters, which are included in the rest of the frame. The actual command codes and their functions are tnc-dependent.

A more-or-less complete list of known codes is shown in Table 6-1 opposite. All tncs understand codes 0-3, 5 and 255, whereas the remaining codes are mostly for experimental use.

For a more detailed description of KISS mode, see the paper by Mike Chepponis and Phil Karn (details in Appendix 6).



Switching the TNC to KISS mode

When you power up a tnc, it will normally start in native mode. To make the tnc ready for NOS, you first need to initialise it with your AX.25 callsign, and you also need to set up the CW ID interval for Morse code station identification, if local licence regulations require it.

For example:

cmd: MID 84

Then, to switch to KISS mode, the command:

cmd: KISS ON

is probably all that’s necessary — see Fig 6-6 on the next page.

Once the tnc is in KISS mode, it won’t understand any more native mode commands. From now on, all communication with the tnc uses the KISS protocol.


Fig 6-6: Switching the tnc between native mode and KISS mode.


However, some older tncs may require a sequence of commands to switch from native to KISS mode; e.g.

cmd: AWLEN 8
STOP $00
XON $00
XOFF $00

Switching Back to Native Mode

If you want to switch your tnc out of KISS mode back to native mode, you need to send a KISS command frame with command code 255. This is achieved in NOS with the param command:

net> param tnc0 255

where tnc0 is the name of the interface to the tnc. Some tncs may also require the param tnc0 254 command as well:

net> param tnc0 254
param tnc0 255

Back to Contents Page

Back to NOSintro Main Page.

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