Kernel vs. user space

Note: This page is a work in progress. It is not yet complete, and it may contain inaccuracies or outdated information.

Main article: AX.25 on Linux

This section provides background on how AX.25 has been implemented on Linux and why the kernel change affects some systems but not others.

Kernel vs. user space

An understanding of the difference between in-kernel and user-space implementations of AX.25 is helpful when considering the impact of the kernel code removal and the options for moving forward.

In-kernel AX.25

The in-kernel code worked like a device driver. The /etc/axports file named and described AX.25 ports for the Linux AX.25 tools, while utilities like kissattach connected a KISS TNC or pseudo-tty to the kernel stack and created an ax network interface. You could assign that interface an IP address, network applications could interact with it like any other network interface, and code in the kernel would handle AX.25 framing and interacting with the TNC using the KISS protocol.

User-space AX.25

A user-space implementation, on the other hand, implements AX.25 in an executable binary that you run separately, not as part of the kernel. It might interface with an external hardware TNC over a serial port, it might work with a software soundmodem, or it might be an all-in-one soundmodem and software TNC combined. You configure it to talk to your radio by various means, and it in turn provides a KISS, AGWPE, TCP, or other interface for other applications to use. This is less like a device driver and more like a server daemon that client applications can connect to.

Much of the current packet-radio software ecosystem already works this way. APRS clients, software TNCs, and all-in-one environments often keep AX.25 framing and packet-radio behavior in user space, then expose KISS, AGWPE, TCP, serial, or application-specific interfaces to the rest of the shack.

In practice, a user-space implementation can cover many common packet-radio uses. It can also be more flexible, easier to maintain, and more portable, since it does not depend on specific kernel versions or interfaces and can be developed independently of the kernel release cycle.

All this being the case, removing AX.25 from the kernel is significant mainly for people preserving older working systems or using software that was introduced years ago and only supports the old kernel interfaces.

If you are just getting started

If you are new to packet radio on Linux, you may already be using user-space AX.25 in the form of APRS clients or software TNCs like Dire Wolf.

If you are learning, you face the challenge that much of the documentation currently available still refers to the old kernel-based model. This means a lot of the first search results you will see are outdated or inapplicable. That documentation might still be useful for understanding the basics of AX.25, but it is unlikely to be a good guide for how to set up a new station today. Rather than looking into AX.25 per se, it may be more helpful to investigate specific applications and see how they use AX.25 for things like APRS and messaging.

If you are more established

If you have an existing station, the first step is to determine whether it depends on the kernel AX.25 stack. If it does, you will need to consider how to freeze, reconfigure, or replace part of your station to keep it working on newer kernels. If it does not, you may be able to keep using your station as it is without worrying about the kernel change. See Am I affected? for tips on how to tell.