The AX.25 protocol offers both connected and connectionless modes of
operation, and is used either by itself for point-point links, or to carry
other protocols such as TCP/IP and NET/ROM.
It is similar to X.25 level 2 in structure, with some extensions to make it
more useful in the amateur radio environment.
The NET/ROM protocol is an attempt at a full network protocol and uses AX.25 at
its lowest layer as a datalink protocol. It provides a network layer that is
an adapted form of AX.25. The NET/ROM protocol features dynamic routing and
node aliases.
The ROSE protocol was conceived and first implemented by Tom Moulton W2VY and
is an implementation of the X.25 packet layer protocol and is designed to
operate with AX.25 as its datalink layer protocol. It too provides a network
layer. ROSE addresses take the form of 10 digit numbers. The first four digits
are called the Data Network Identification Code (DNIC) and are taken from
Appendix B of the CCITT X.121 recommendation. More information on the ROSE
protocol may be obtained from the
RATS Web server.
Alan Cox developed some early kernel based AX.25 software support for
Linux. Jonathon
Naylor has taken up ongoing development of the code, has added
NET/ROM and ROSE support and is now the developer of the AX.25 related
kernel code. DAMA support was developed by
Joerg, DL1BKE. Baycom and
Soundmodem support were added by
Thomas Sailer.
The AX.25 software is now maintained by a small team of developers
on SourceForge.
The Linux code supports KISS and 6PACK based TNC's (Terminal Node
Controllers), the Ottawa PI card, the Gracilis PacketTwin card and
other Z8530 SCC based cards with the generic SCC driver, several
parallel and serial port Baycom modems, and serial port YAM
modems. Thomas Sailer's kernel soundmodem driver supports SoundBlaster
and sound cards based on the Crystal chip set, and his newer user-mode
soundmodem uses the standard kernel sound drivers, so it should work
with any sound card supported under Linux.
The user programs contain a simple PMS (Personal Message System), a
beacon facility, a line mode connect program,
listen (an example of how to capture all AX.25
frames at raw interface level), and programs to configure the NET/ROM
protocol. Also included are an AX.25 server style program to handle
and dispatch incoming AX.25 connections and a NET/ROM daemon which
does most of the hard work for NET/ROM support.
There are utility programs to support APRS, including digipeating and
gatewaying to the Internet.
The Linux AX.25 implementation is a brand new implementation. While in many
ways it may looks similar to NOS, or BPQ or other AX.25 implementations, it
is none of these and is not identical to any of them. The Linux AX.25
implementation is capable of being configured to behave almost identically
to other implementations, but the configuration process is very different.
To assist you in understanding how you need to think when configuring this
section describes some of the structural features of the AX.25 implementation
and how it fits into the context of the overall Linux structure.
Simplified Protocol Layering Diagram
_____________________________________________
| | | | |
| AF_AX25 | AF_NETROM | AF_INET | AF_ROSE |
|=========|===========|=============|=========|
| | | | |
| | | TCP/IP | |
| | |________ | |
| | NET/ROM | | ROSE |
| |____________________|____|_________|
| AX.25 |
|_____________________________________________| |
This diagram simply illustrates that NET/ROM, ROSE and TCP/IP all run directly
on top of AX.25, but that each of these protocols is treated as a separate
protocol at the programming interface. The `_' names are
simply the names given to the `Address Family' of each of these
protocols when writing programs to use them. The important thing to note here
is the implicit dependence on the configuration of your AX.25 devices before
you can configure your NET/ROM, ROSE or TCP/IP devices.
Software Module Diagram of Linux Network Implementation
___________________________________________________________________________
| | | || | |
| User | Programs | call node || Daemons | ax25d mheardd |
| | | pms mheard || | inetd netromd |
|_________|___________|_______________________||__________|_________________|
| | Sockets |open(), close(), listen(), read(), write(), connect()|
| | |_____________________________________________________|
| | | AF_AX25 | AF_NETROM | AF_ROSE | AF_INET |
| |___________|_____________|_____________|_____________|___________|
|Kernel | Protocols | AX.25 | NetRom | ROSE | IP/TCP/UDP|
| |___________|_____________|_____________|_____________|___________|
| | Devices | ax0,ax1 | nr0,nr1 | rose0,rose1 | eth0,ppp0 |
| |___________|_____________|_____________|_____________|___________|
| | Drivers | Kiss PI2 PacketTwin SCC BPQ | slip ppp |
| | | Soundmodem Baycom | ethernet |
|_________|___________|_________________________________________|___________|
|Hardware | PI2 Card, PacketTwin Card, SCC card, Serial port, Ethernet Card |
|_________|_________________________________________________________________| |
This diagram is a little more general than the first. This diagram attempts to
show the relationship between user applications, the kernel and the hardware.
It also shows the relationship between the Socket application programming
interface, the actual protocol modules, the kernel networking devices and the
device drivers. Anything in this diagram is dependent on anything underneath
it, and in general you must configure from the bottom of the diagram upwards.
So for example, if you want to run the call program you must also
configure the hardware, then ensure that the kernel has the appropriate device
driver, that you create the appropriate network device, that the kernel
includes the desired protocol that presents a programming interface that the
call program can use. I have attempted to lay out this document in
roughly that order.
Take our 
