AX.25 on Linux

From 44Net Wiki
Revision as of 22:26, 30 April 2026 by KI5QKX (talk | contribs) (mw push)


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

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 configure /etc/axports
  • 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.

Revive

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 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
QtSoundModem User-space modem/TNC; KISS and AGWPE-style host-side interfaces Yes Reconfigure Point your applications at its KISS endpoint
SoundModem User-space modem/TNC; KISS and AGWPE-style host-side interfaces Yes Reconfigure Point your applications at its KISS or AGWPE 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 Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.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

For now, you may need to stay on an older kernel until a user-space solution emerges.

External resources

Related pages

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