AX.25 on Linux

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

As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This affects systems and applications that depend on Linux kernel AX.25 interfaces, but it does not mean AX.25 packet radio on Linux is going away.

The short version is:

If your setup uses KISS or AGWPE to talk to a software TNC, hardware TNC, or packet-radio application, you are probably not affected by the kernel removal.
If your setup uses Linux AX.25 interfaces like ax0, kissattach, /etc/axports, or ax25d, it will not keep working unchanged on newer kernels.
Nothing breaks immediately just because the upstream kernel changed. Existing systems keep working until you update them to a kernel released after the change.

This page explains what changed, how to tell whether your station depends on that older model, and what practical options exist now.

What is changing

Mainline Linux no longer includes the traditional Linux AX.25, Net/ROM, and ROSE stack.
Existing documentation that assumes kissattach, /etc/axports, ax interfaces, or ax25d will no longer apply to systems running newer kernels.
Software that depends specifically on kernel AX.25 interfaces will be unable to run unchanged on newer kernels.
Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
The out-of-tree repository linux-netdev/mod-orphan will host the removed code for those who want to inspect it or maintain it separately.

Timeline

This change happened in “upstream Linux” first, referring to the mainline Linux kernel project. Distributions like Debian, Ubuntu, and Fedora decide for themselves when to ship newer kernels, and long-term-support distributions may stay on older kernel lines for quite a while.

That means this probably is not hitting most existing stations tomorrow. In many cases, you will keep working until your distribution moves you to a kernel that no longer includes the in-tree AX.25 code, whether that happens in a major distribution upgrade or in a later kernel update.

The practical takeaway is: you likely have some time to plan, but you may want to pay attention to updates that include newer kernels.

Am I affected?

Yes, if your setup uses the Linux kernel AX.25 model. Probably not, if you use software that talks to devices directly.

You are probably using the kernel AX.25 stack if:

ifconfig or ip link shows ax interfaces like ax0
You use kissattach
You configure /etc/axports
You use ax25d
Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

ifconfig or ip link does not show any ax interfaces
You already use a user-space TNC like Dire Wolf without kissattach
Your application has its own AX.25 support built in, as many APRS tools do
Your applications talk to KISS or AGWPE directly, whether to a software TNC, hardware TNC, or another packet-radio program

If you are not sure, look at how your application is configured. KISS or AGWPE options are usually a good sign. A configuration that refers only to a Linux AX.25 port, ax interface, /etc/axports, or ax25d is a sign that you may need to freeze, reconfigure, or replace part of the station.

If you already have a working station

Broadly speaking, there are a few paths: keep the system running as it is, reconfigure applications around a different host-side interface, or replace part of the stack. The best choice depends on your specific use case, how much existing software you need to preserve, and how much you are willing or able to change.

Freeze (keep it running as is)

If you’re using software that depends on kernel AX.25, future kernel updates will break it. If you want to keep that software working, the simplest path may be to stay on the version of Linux you have now.

You can keep using that system for as long as you like, but you will find ample advice to consider the security implications. Older kernels do not receive fixes for newly discovered vulnerabilities, and the longer a system stays pinned to an old kernel, the more exposed it can become. If you choose this path, it is worth taking extra precautions to secure the system.

Reconfigure

If you’re using software released relatively recently, you may be able to reconfigure it. For example, an APRS application that can use AGWPE or KISS over TCP or serial may only need to be pointed at Dire Wolf or a hardware TNC via a different protocol.

Replace

This is the likely path when the old application depends on the kernel AX.25 stack and cannot be reconfigured to use KISS, AGWPE, serial, TCP, or anything else. You may be looking at anything from replacing one piece to rebuilding your stack from top to bottom. Depending on your goals, you might consider something that has AX.25 and common packet tools built in, like LinBPQ or JNOS. You might also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.

Revive

There is always the option of resurrecting or re-implementing the old kernel code; the kernel maintainers have not ruled out merging up-to-date code back in. If you have the technical interest and motivation, there’s nothing to stop you.

The state of maintenance for the code that was just removed and the state of development in other tools might be considerations when evaluating this path. ARDC did fund an effort related to AX.25 in the kernel that encountered unexpected challenges and was not able to proceed. New coding tools may make this a more approachable project than it might have been in the past, with some caveats noted in the Linux kernel development documentation, particularly around the use of large language models.

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.

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.

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.

Migration options

The table below shows what common software expects and what you can do going forward. It is meant to be illustrative rather than exhaustive. For any software, the general pattern is:

If your application can already speak KISS or AGWPE over serial or network interfaces, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint using a supported protocol.
If your application requires Linux AX.25 sockets, ax interfaces, kissattach, ax25d, or the related kernel tools, there will not be a direct drop-in migration path on newer kernels.
If you are not sure, look at how you configure the application. If you see KISS or AGWPE options, that is a good sign. If you only have the option to point at an ax interface, that is not as good a sign.

Software	Current interface	Migration approach
All-in-one environments
LinBPQ	Implements full stack and applications; can work with KISS and AGW-compatible software	Use its built-in applications, or integrate it through the interfaces it supports
JNOS 2	Implements full stack and applications; KISS-oriented, with AXIP and AXUDP support	Use its built-in applications, or integrate it through KISS-oriented links
Software TNCs and soundmodems
Dire Wolf	User-space modem/TNC; KISS and AGWPE host-side interfaces	Point your applications at its KISS or AGWPE endpoint
QtSoundModem
UZ7HO SoundModem
Endpoint applications and clients
Pat	Pluggable AX.25 engine; AGWPE support	AGWPE
Xastir	KISS, AGWPE, or Linux kernel AX.25 interfaces	KISS or AGWPE
aprx	KISS or Linux kernel AX.25 interface	KISS
YAAC	External TNC or serial interface	KISS
Legacy patterns and kernel-bound tools
KISS-oriented legacy applications generally	Usually pseudo-tty KISS, TCP KISS, or external TNC	Native KISS-capable software
aprsdigi	Linux AX.25 APRS digipeater	APRS-specific replacement like aprx or other APRS software
ax25-tools	Linux AX.25, NET/ROM, and ROSE kernel configuration tools	No direct equivalent; keep only in legacy environments or replace with user-space TNC tooling
ax25-apps	Linux AX.25, NET/ROM, and ROSE kernel user applications, including `ax25d`	Application-specific replacement like LinBPQ, JNOS, Pat, or APRS software
net2kiss	Converts Linux kernel AX.25 interfaces into pseudo-tty KISS	No direct equivalent; replace the kernel-binding pattern with a native KISS or AGWPE source

Developing new user-space AX.25 tools

AX.25 may be considered active enough to justify new user-space implementations. Many of the building blocks already exist in open source. Before starting a brand-new user-space AX.25 project, it might be worth looking first at software that already does some or all of the following:

Modem/TNC functions
AX.25 framing
KISS or AGWPE host-side interfaces
APRS, BBS, node, or messaging applications
Integration with modern Linux networking through user-space boundaries like TUN/TAP

Project	Project page or repo	Technical scope	Why inspect it
LinBPQ, BPQ32	project page	AX.25 stack, node/BBS and APRS applications, KISS, multi-interface and IP integration	Reference for a broad all-in-one user-space packet-radio environment
JNOS 2	project page	AX.25 stack, node/BBS, APRS, and messaging applications, KISS, AXIP, AXUDP	Reference for structuring a nearly complete packet-radio stack in user space
Dire Wolf	GitHub	Modem/TNC functions, AX.25 framing, KISS, AGWPE, APRS tooling	Clear reference for a maintained user-space TNC and host-side interface layer
Xastir SoundModem	GitHub	Modem/TNC functions; serial KISS or Linux AX.25 integration	Reference for an older Linux soundmodem design that can operate either through serial KISS or kernel AX.25
QtSoundModem	project page	Modem/TNC functions, KISS, AGWPE	Another example of a user-space software-TNC design exposing standard host interfaces
tncattach	GitHub	KISS-based Linux network-device integration for IP and Ethernet-style networking	Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
Pat	GitHub	Messaging application, AX.25 support, AGWPE	Useful example of integrating AX.25 support into a modern end-user application
aprx	project page	APRS application, iGate and digipeater functions	Reference for a focused application that avoids general-purpose kernel AX.25 dependencies
YAAC	project page	APRS application and related tooling	Example of an application-layer design that works through external TNC interfaces

IP over AX.25

If your goal is specifically IP over AX.25, the range of options has narrowed.

The upstream discussion explicitly points out that IP over AX.25 can, in principle, be handled from user space, as via TUN/TAP integration, rather than by requiring the historic kernel implementation.

That does not mean there is one complete drop-in replacement ready for every old Linux AX.25 workflow today. It does suggest a long-term architectural direction:

AX.25 framing and control in user space
Integration with IP through TUN/TAP or similar interfaces
Narrower, more maintainable components rather than a large in-kernel subsystem

For now, end users may need to stay on an older kernel until a user-space solution emerges. Interested developers might look into this as an area for contributions to new or existing projects.

One current project that might be relevant for IP over amateur radio projects is tncattach, a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of kissattach was simply to turn a KISS TNC into a Linux network device for IP networking, then tncattach may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

Related pages