AX.25 on Linux

From 44Net Wiki
Revision as of 19:48, 2 May 2026 by KI5QKX (talk | contribs) (mw push)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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.

In this guide

Summary

  • 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 future 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.

So you 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 a good sign.

What should I do?

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.

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 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 moving to 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.

Further reading

ARDC groups.io discussions

Kernel discussions

Independent coverage

Repositories and source trees

Older HOWTOs

Protocol references

Related pages

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