View source for The Packet Radio Protocols and Linux

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 [[ITU-T]] [[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.

== How it all fits together ==

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

<pre>
 _____________________________________________
|         |           |             |         |
| AF_AX25 | AF_NETROM |  AF_INET    | AF_ROSE |
|=========|===========|=============|=========|
|         |           |             |         |
|         |           |    TCP/IP   |         |
|         |           |________     |         |
|         |   NET/ROM          |    | ROSE    |
|         |____________________|____|_________|
|            AX.25                            |
|_____________________________________________|
</pre>

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

<pre>
 ___________________________________________________________________________
|         |           |                       ||          |                 |
| 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 |
|_________|_________________________________________________________________|
</pre>

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.