AX.25 on Linux

For years, Linux has included an in-kernel implementation of AX.25, Net/ROM, and ROSE. This provided network interfaces for connected-mode packet, and user-space applications could rely on those interfaces for their AX.25 needs.

As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This page explains the current situation and outlines practical options going forward.

What is changing

• Upcoming mainline kernel releases will no longer include the traditional AX.25 stack
• Existing documentation related to these protocols will no longer apply to systems running newer kernels
• Software that depends specifically on kernel AX.25 interfaces will be unable to run on newer kernels
• 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

Who is likely to be affected

Probably affected

This change might affect you if:

• ifconfig or ip link shows ax interfaces on your system
• You use kissattach
• You use ax25d

Probably less affected

You are probably less affected if:

• ifconfig or ip link does not show any ax interfaces on your system
• You already use a user-space TNC like Dire Wolf (without kissattach)
• The app you use has its own AX.25 built in (common with APRS software)
• You're using applications that can talk to KISS or AGWPE directly, to either a software or hardware TNC

Kernel vs. user space

The in-kernel code worked like a device driver. The /etc/axports file defined a radio port, which was at the time usually a serial port connected to a hardware TNC. The kissattach tool took that port and created an ax network interface. You could assign that interface an IP address, route through it, and throw data at it, and the kernel would frame it as AX.25 and send it out to the radio for transmission.

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, and then you point your applications at it through KISS, AGWPE, TCP, etc.; the kernel never needs to know that AX.25 is involved at all.

In practice, a user-space implementation can be just as capable as a kernel implementation, and moreover, it can be more flexible and easier to maintain. It can also be more portable, since it does not depend on specific kernel versions or interfaces, and it can be developed and updated 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 see may be outdated or not directly applicable to your situation. 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.

If you're more established

If you are already running packet radio on Linux, the first question is what you want continued operation of your station to look like.

Broadly speaking, there are at least a few paths: keep it running as is, reconfigure the pieces around the radio, or replace part of the stack. The best choice depends on your specific use case, how much you want to preserve existing software, 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 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 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 mght also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.

Ressurect

If you have the technical interest and motivation, there's nothing to stop you reviving the kernel code in the out-of-tree repository.

The long absence of maintainers for the code that was just removed might be an indication of the challenges of this path.

Migration options

The main question is simpler than the table might make it look:

• If your application can already speak KISS or AGWPE, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint that provides the same host-side interface.
• If your application requires Linux AX.25 sockets, ax interfaces, kissattach, ax25d, or the related kernel tools, there may 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.

The “Common migration target” column is therefore mostly about host-side interfaces, not about naming one preferred tool. A KISS or AGWPE endpoint might come from Dire Wolf, QtSoundModem, SoundModem, a hardware TNC, or another program that exposes the same kind of interface.

Software	Current interface	Works in the new world?	Next step to consider	Common migration target
Dire Wolf	User-space AX.25; KISS over TCP/serial; AGWPE over TCP	Yes	Reconfigure	Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
Pat	AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP	Yes	Reconfigure	KISS or AGWPE endpoint
LinBPQ / BPQ32	Own packet stack and node/BBS environment; KISS, AXIP/UDP, AGW-style interfaces	Yes	Reconfigure	Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
Xastir	Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports	Depends	Reconfigure	KISS or AGWPE endpoint
aprx	Serial KISS or kernel AX.25 interface	Depends	Reconfigure	KISS endpoint
YAAC	User-space APRS client using external TNCs / serial interfaces	Yes	Reconfigure	KISS endpoint
SoundModem	User-space modem/TNC; can expose KISS and other endpoints	Yes	Reconfigure	Point your applications at its KISS or AGWPE endpoint
QtSoundModem	User-space modem/TNC; KISS and AGWPE-style host-side interfaces	Yes	Reconfigure	Point your applications at its KISS endpoint
KISS-oriented legacy applications generally	Usually external TNC, pseudo-tty KISS, or TCP KISS	Depends	Reconfigure or Replace	KISS endpoint
JNOS 2	Is its own networking environment; typically external TNC or KISS oriented	Yes	Reconfigure or Replace	Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
aprsdigi	APRS digipeater software; commonly used with KISS TNCs	Yes	Reconfigure	KISS endpoint
ax25-tools	Tools for configuring Linux AX.25 / NET/ROM / ROSE ports	No	Freeze (or Revive)	None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
ax25-apps	User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including ax25d	Mostly no	Freeze (or Revive)	Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
net2kiss	Converts a kernel AX.25 network interface into a pseudo-tty KISS stream	No	Replace	No direct equivalent; consider refactoring your stack

Some notes about reading the table:

• Yes means the software already works without depending on the removed code.
• Depends means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
• No or Mostly no means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

Existing user-space projects worth studying first

One strong theme in this transition is that many of the building blocks people need already exist in open source. Before starting a brand-new user-space AX.25 implementation, it is worth looking first at projects that already do some or all of the following:

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

Project	Project page / repo	What it already covers	Why it is worth inspecting
Dire Wolf	GitHub	Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE	One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
Pat	GitHub	Messaging client with AX.25 support and AGWPE integration	Useful when the goal is mainly messaging
LinBPQ / BPQ32	project page	Node, BBS, switch, packet stack, multiple radio/network interfaces	Covers a broad slice of packet-radio infrastructure and may already solve the “legacy node/BBS” use case
Xastir SoundModem	GitHub	User-space modem/TNC functions for packet-radio host applications	Worth studying as an existing open-source modem implementation rather than inventing one from scratch
QtSoundModem	project page	User-space modem/TNC with KISS and AGWPE-style interfaces	Another active example of the “software TNC in user space” approach
aprx	project page	APRS iGate and digipeater software	Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
YAAC	project page	APRS client and related tooling	Useful as an example of an application-layer approach that can use user-space TNCs
JNOS 2	project page	Packet-radio networking environment and applications	Worth inspecting for people whose main interest is preserving classic packet workflows

What of 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 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

If you are stuck with old software

Some people will be in the awkward middle: the software still matters, it expects the kernel interfaces, and there is no obvious one-command migration.

If that is you, the best immediate response is usually not “rewrite everything,” but:

1. identify the exact interface your application expects
2. determine whether that interface is kernel AX.25 specifically, or simply KISS / AGWPE / serial control
3. if kissattach is part of the path, ask whether it is only being used to create an ax interface for software that could talk to KISS or AGWPE directly
4. check whether a user-space adapter, software TNC, or out-of-tree module can preserve the workflow
5. decide whether the system should be frozen, migrated, or rebuilt

For some stations, a preserved older Linux environment may be the right answer for a while. For others, the better answer will be to retire the old application and move to a user-space stack.

If you want to help advance AX.25 on Linux

If this change motivates you to improve the state of AX.25 rather than simply work around it, there are several useful starting points.

1. Clarify the real use cases

The first question might not be “How do we save everything?” but rather “What do people still need?”

Those may be very different things, and without clarity, it might be easy to spend effort rebuilding interfaces nobody still uses while diverting effort away from projects that people do still use.

3. Preserve working knowledge before it disappears

A lot of Linux AX.25 knowledge lives in old HOWTOs, mailing-list posts, working systems on shelves, and people's heads. Current documentation is never unwelcome. Now could be a good time to capture that knowledge.

4. Start from existing active projects

Starting from a maintained or recently active user-space project is likely to be more productive than preserving historical artifacts. That might mean extending an existing implementation, building missing protocol pieces, or writing compatibility layers like a TUN/TAP adapter for IP over AX.25.

External resources

• Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem
• Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream
• LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort
• Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25
• linux-netdev/mod-orphan, the out-of-tree repository where the removed code is being staged
• Dire Wolf, a widely used user-space software TNC for AX.25 packet radio
• Pat, a current Winlink client with AX.25 support and AGWPE support
• BPQ32 / LinBPQ documentation
• aprx, APRS iGate and digipeater software for POSIX systems
• YAAC, Yet Another APRS Client
• Jeff Tranter’s Linux AX.25 HOWTO, useful mainly as historical background now

Related pages

• Getting started with Linux and packet radio
• Setting up a gateway on Linux
• Gateway
• Routing
• MTU and MSS