AX.25 on Linux

From 44Net Wiki
Revision as of 18:53, 30 April 2026 by KI5QKX (talk | contribs) (mw push)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


For years, Linux has included an in-kernel implementation of AX.25, Net/ROM, and ROSE. The kernel 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

  • Operators running older Linux packet-radio setups that depend on kernel AX.25 interfaces
  • Users of older applications that assume AX.25 support is available through the Linux kernel network stack
  • Maintainers of software that has never needed to implement its own AX.25 handling because Linux already provided it

Probably less affected

  • Operators already using user-space TNCs or modem software like Dire Wolf
  • Applications for things like APRS that already handle AX.25 internally and do not depend on Linux kernel interfaces
  • People experimenting with newer software that does not depend on the old kernel path

Not the end of AX.25

AX.25 still remains useful and is in use. The change is that Linux will no longer provide a built-in kernel implementation of it. Instead, applications that need AX.25 will need to implement it in user space or rely on external software that does.

The difference between in-kernel and user-space implementations is that in-kernel code, working like a device driver, can present AX.25 interfaces as native network interfaces. Applications can then use familiar socket APIs to build networking functionality without having to worry about the details of AX.25 (in theory).

User-space implementations, on the other hand, sit between a radio and an application without needing to be part of the kernel. On the radio side, they may work with audio devices or external TNCs over serial ports. On the application side, they present a data stream or API that the application can use. Instead of talking to what looks like a network device, an application talks to another application that knows how to handle AX.25. This means applications need to be able to talk to such user-space tools. Many applications already do, through KISS, AGWPE, TCP/IP, or other interfaces.

Today, a lot of practical packet-radio software already uses or is compatible with user-space implementations.

Taken together, this means that removing AX.25 from the kernel is significant mainly for people preserving older working systems and people still using software built around the legacy kernel interfaces. For new deployments, and for many existing ones, it is more practical to build on user-space tools.

If you are just getting started

If you are new to packet radio on Linux, user-space tools are the way forward. You may already be using them in the form of APRS clients or software TNCs.

You face the challenge that much of the documentation currently available still refers to the old kernel-based model. 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.

Next-step paths

There are a few general ways to handle the transition away from kernel AX.25 support. The best choice depends on your specific use case, how much you want to preserve existing software, and how much you are willing to change.

“Freeze”

Keep an older kernel in service.

Use this when:

  • the station is working now
  • the software depends on kernel AX.25 interfaces
  • you need continuity more than modernization this week

This is often the least disruptive short-term option, but it carries security debt. Older kernels do not receive fixes for newly discovered vulnerabilities forever, 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 limiting the system’s role, network exposure, and upgrade churn.

Reconfigure

Keep the same application, but change how it reaches the radio side.

Typical examples:

  • switch from a kernel AX.25 port to KISS
  • switch from a kernel AX.25 port to AGWPE
  • attach the application to a software TNC instead of a kernel network interface

This is often the best path when the application itself is still useful, but its old default Linux integration is not.

Bridge

Insert a user-space modem or TNC layer in front of the application.

Typical examples:

  • Dire Wolf presenting KISS over TCP or serial
  • Dire Wolf presenting AGWPE over TCP
  • another software TNC or packet engine exposing a stable host-side protocol

This path is especially useful when the application can already speak KISS or AGWPE but was previously wired into a kernel-based setup.

Replace

Move to different software that already lives comfortably in the user-space model.

This is often the cleanest long-term answer for:

  • new deployments
  • APRS-focused stations
  • stations whose existing software is effectively unmaintained

Revive

Carry the out-of-tree kernel code, help maintain it, or port missing behavior into a new user-space implementation.

This path makes sense mainly if:

  • you have a real use case that still requires the old kernel semantics
  • you are willing to do development and maintenance work
  • you are trying to preserve something beyond one private station

Compatibility snapshot

The table below is not exhaustive, but it covers many of the tools readers are most likely to encounter when working with AX.25 or adjacent Linux packet-radio workflows.

These are not endorsements. The “Common migration target” column is meant as a practical example of what kind of thing a reader might try next, not as a universal recommendation.

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 Bridge or Replace Dire Wolf as the anchor itself, or paired with Pat / Xastir / aprx
Pat AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP Yes Reconfigure or Bridge Dire Wolf over AGWPE/TCP
LinBPQ / BPQ32 Own packet stack and node/BBS environment; KISS, AXIP/UDP, AGW-style interfaces Yes Reconfigure or Replace LinBPQ itself, or Dire Wolf feeding LinBPQ via KISS
Xastir Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports Depends Reconfigure Dire Wolf or another KISS/AGWPE-capable software TNC
aprx Serial KISS or kernel AX.25 interface Depends Reconfigure Dire Wolf or a hardware KISS TNC
YAAC User-space APRS client using external TNCs / serial interfaces Yes Reconfigure Existing external TNC, or Dire Wolf acting as one
SoundModem User-space modem/TNC; can expose KISS and other interfaces Yes Bridge or Replace Dire Wolf or SoundModem itself, depending on platform and feature needs
QtSoundModem User-space modem/TNC; KISS and AGWPE-style host-side interfaces Yes Bridge or Replace QtSoundModem or Dire Wolf as the software-TNC layer
KISS-oriented legacy applications generally Usually external TNC, pseudo-tty KISS, or TCP KISS Depends Reconfigure or Replace Dire Wolf, QtSoundModem, or a hardware KISS TNC
JNOS 2 Own networking environment; typically external TNC / KISS oriented rather than Linux kernel AX.25 sockets Yes Reconfigure or Replace JNOS itself with a KISS-capable modem/TNC
aprsdigi APRS digipeater software; commonly used with KISS TNCs Yes Reconfigure Dire Wolf or a hardware KISS TNC
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 Mostly no Freeze or Revive Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
ax25d AX.25 connection dispatcher / daemon built around the Linux AX.25 stack No Freeze or Revive Usually not a direct one-for-one migration; often LinBPQ, JNOS, or an application-specific redesign
net2kiss Converts a kernel AX.25 network interface into a pseudo-tty KISS stream No Revive Replace the whole pattern with a native user-space KISS or AGWPE source

Some notes about reading the table:

  • Yes means the software already has a credible path that does not require the removed in-tree kernel stack.
  • Depends means the software can still work, but only through a non-kernel interface or a different configuration mode.
  • Mostly no means the software category is tightly coupled enough to the old Linux stack that it is not a good default choice on new upstream kernels without extra work.

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 real goal is messaging workflow rather than rebuilding low-level plumbing
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 does not depend on the Linux AX.25 kernel stack
JNOS 2 project page Packet-radio networking environment and applications Worth inspecting for people whose real interest is preserving classic packet workflows rather than Linux kernel semantics

If you already have an older setup

If you built something years ago and it still works, do not panic. The right next step depends on what kind of old setup you actually have.

Case 1: It works, and you do not need a new kernel right now

The least disruptive option may be to leave it alone for the moment:

  • staying on a currently working kernel for that system
  • treating the system as a stable appliance rather than a frequently upgraded workstation
  • documenting what you have before changing anything

Before you touch the system, write down:

  • which kernel version it depends on
  • which applications depend on kernel AX.25
  • how the radio or TNC is connected
  • whether the system is doing connected-mode AX.25, IP over AX.25, APRS, forwarding, or something else

That inventory makes every later decision easier.

Case 2: You need to keep old software working

If you depend on software that expects the old kernel interfaces, you may need an interim compatibility strategy rather than an immediate redesign.

Potential short- to medium-term options include:

  • staying on an older kernel for that machine
  • evaluating the out-of-tree kernel code now hosted in the linux-netdev/mod-orphan repository
  • isolating the legacy workflow in a dedicated machine or virtual machine rather than tying it to your general-purpose Linux environment

This is not elegant, but it may be the most practical option if a working station depends on legacy interfaces and there is no ready user-space replacement for your exact use case.

If you choose this route, treat it as a containment strategy rather than a permanent default. A deliberately isolated older kernel can buy time, but it also accumulates security debt as new vulnerabilities are found and fixed only in newer supported lines.

Case 3: You are willing to modernize

If you are already making changes, it may be better to migrate toward a user-space model than to rebuild the same dependency on a shrinking kernel path.

That usually means asking:

  • Do I actually need Linux to implement AX.25 in the kernel?
  • Can my application talk to a user-space TNC or modem over KISS or AGWPE instead?
  • Am I really using AX.25 networking, or just one narrow application that happens to sit on top of it?

In many cases, the cleanest long-term answer is to preserve the radio-side protocol in user space while simplifying everything around it.

Architectural direction

For many people, the most practical direction is now a user-space one: software TNCs, external host-side interfaces such as KISS or AGWPE, and applications that do not assume Linux kernel AX.25 sockets are always present.

That does not solve every legacy use case automatically. But it does reduce dependence on upstream kernel decisions and makes it easier to compose working systems from smaller pieces.

IP over AX.25

If your goal is specifically IP over AX.25, the choices become narrower.

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 to 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. check whether a user-space adapter, software TNC, or out-of-tree module can preserve the workflow
  4. 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 is not “How do we save everything?” but “What do people still need?”

Those may be very different things:

  • APRS and monitoring
  • connected-mode packet
  • mailbox / BBS workflows
  • IP over AX.25
  • compatibility with specific TNCs or handheld radios
  • Linux support for existing packet-radio applications

Without that clarity, it is easy to spend effort rebuilding interfaces nobody still uses while missing the ones that still matter.

2. Prefer small boundaries

If you want to revive or modernize AX.25 support, it is worth favoring:

  • small, testable user-space components
  • clean interfaces between radio handling and host networking
  • compatibility layers only where they are actually needed

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
  • people’s heads

Now is a good time to capture:

  • what still works
  • what specific applications still matter
  • which workflows require kernel compatibility
  • which ones can already move to user space

4. Start from existing active projects

Starting from a maintained or recently active user-space project is likely to be more productive than starting from nostalgia alone.

That may mean extending an existing implementation, building missing protocol pieces, or writing compatibility shims where they create the most leverage.

Suggested attitude

This topic attracts strong opinions:

  • nostalgia for the old Linux support
  • frustration from people whose working systems are affected
  • arguments about whether kernel support was ever the right design
  • arguments that packet radio is too niche to matter

Those reactions are understandable, but they do not help much by themselves.

The more useful questions are:

  • What still needs to work?
  • What can move to user space today?
  • What legacy interfaces are still worth preserving?
  • What should be documented now so the next person does not have to rediscover everything from scratch?

External resources

Related pages

Retrieved from "https://wiki.ampr.org/w/index.php?title=AX.25_on_Linux&oldid=2575"