AX.25 on Linux: Difference between revisions

From 44Net Wiki
mw push
 
mw push
 
(27 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{DISPLAYTITLE:AX.25 on Linux}}
{{DISPLAYTITLE:AX.25 on Linux}}


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.
{{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 page explains the current situation and outlines practical options going forward.
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.


== What is changing ==
== In this guide ==


* Upcoming mainline kernel releases will no longer include the traditional AX.25 stack
* [[AX.25 on Linux/Kernel vs user space]]: How the old kernel model differs from the user space model
* Existing documentation related to these protocols will no longer apply to systems running newer kernels
* [[AX.25 on Linux/Migration options]]: Common software and migration approaches
* Software that depends specifically on kernel AX.25 interfaces will be unable to run on newer kernels
* [[AX.25 on Linux/IP over AX.25]]: Possible directions for IP networking over AX.25
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately
* [[AX.25 on Linux/Developing user-space tools]]: Design considerations for new work


== Who is likely to be affected ==
== Summary ==


=== Probably affected ===
* 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 <code>ax0</code>, <code>kissattach</code>, <code>/etc/axports</code>, or <code>ax25d</code>, 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.


* Operators running older Linux packet-radio setups that depend on kernel AX.25 interfaces
This page explains what changed, how to tell whether your station depends on that older model, and what practical options exist now.
* 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 ===
== What is changing ==


* Operators already using user-space TNCs or modem software like Dire Wolf
* Mainline Linux no longer includes the traditional Linux AX.25, Net/ROM, and ROSE stack.
* Applications for things like APRS that already handle AX.25 internally and do not depend on Linux kernel interfaces
* Existing documentation that assumes <code>kissattach</code>, <code>/etc/axports</code>, <code>ax</code> interfaces, or <code>ax25d</code> will no longer apply to systems running newer kernels.
* People experimenting with newer software that does not depend on the old kernel path
* 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 <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.


== Not the end of AX.25 ==
== Timeline ==


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


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).  
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.


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.
So you have some time to plan, but you may want to pay attention to updates that include newer kernels.


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


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.
Yes, if your setup uses the Linux kernel AX.25 model. Probably not, if you use software that talks to devices directly.


== If you are just getting started ==
You are probably using the kernel AX.25 stack if:


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.
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* 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 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.
You are probably using a user-space approach if:


== Next-step paths ==
* <code>ifconfig</code> or <code>ip link</code> does not show any <code>ax</code> interfaces
* You already use a user-space TNC like Dire Wolf without <code>kissattach</code>
* 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


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.
If you are not sure, look at how your application is configured. KISS or AGWPE options are a good sign.


=== “Freeze” ===
== What should I do? ==


Keep an older kernel in service.
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.  


Use this when:
=== Freeze (keep it running as is) ===


* the station is working now
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.
* 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.
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 ===
=== Reconfigure ===


Keep the same application, but change how it reaches the radio side.
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.
 
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 ===
=== Replace ===


Move to different software that already lives comfortably in the user-space model.
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.
 
This is often the cleanest long-term answer for:
 
* new deployments
* APRS-focused stations
* stations whose existing software is effectively unmaintained


=== Revive ===
=== Revive ===


Carry the out-of-tree kernel code, help maintain it, or port missing behavior into a new user-space implementation.
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.  


This path makes sense mainly if:
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 [https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/ an effort related to AX.25 in the kernel] that encountered unexpected challenges and was not able to proceed.


* you have a real use case that still requires the old kernel semantics
New coding tools may make this a more approachable project than it might have been in the past, with some caveats noted in the [https://docs.kernel.org/process/index.html#an-introduction-to-how-kernel-development-works Linux kernel development documentation], particularly around [https://docs.kernel.org/process/coding-assistants.html the use of large language models].
* you are willing to do development and maintenance work
* you are trying to preserve something beyond one private station


== Compatibility snapshot ==
== Further reading ==


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.
=== ARDC groups.io discussions ===


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.
* [https://ardc.groups.io/g/community/topic/119004386 Boudewijn VE3TOK’s thread and discussion about paths forward]
* [https://ardc.groups.io/g/community/topic/119004386 Bernard F6BVP’s retrospective and thoughts on the change]


{| class="wikitable sortable"
=== Kernel discussions ===
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf 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
|-
| [https://github.com/la5nta/pat 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
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html 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
|-
| [https://www.xastir.org/index.php/XASTIR_Manual Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| Dire Wolf or another KISS/AGWPE-capable software TNC
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| Dire Wolf or a hardware KISS TNC
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| Existing external TNC, or Dire Wolf acting as one
|-
| [https://github.com/Xastir/SoundModem 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
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html 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
|-
| [https://www.ka9q.net/papers/kiss.html 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
|-
| [https://www.langelaar.net/projects/jnos2/ 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
|-
| [https://tracker.debian.org/pkg/aprsdigi aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| Dire Wolf or a hardware KISS TNC
|-
| [https://packages.debian.org/sid/ax25-tools 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
|-
| [https://packages.debian.org/sid/ax25-apps 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
|-
| [https://manpages.debian.org/unstable/ax25-apps/ax25d.8.en.html 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
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ 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:
* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch], proposing removal of the in-tree amateur-radio networking subsystem
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread], with more discussion
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch], noting that AX.25, ROSE, and NET/ROM have been removed upstream
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction], including TUN/TAP for IP over AX.25


* '''Yes''' means the software already has a credible path that does not require the removed in-tree kernel stack.
=== Independent coverage ===
* '''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 ==
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026], summarizing the broader kernel code-removal effort
* [https://www.phoronix.com/news/Linux-7.1-PR-Remove-Old-Net Phoronix coverage from April 24, 2026], on the pull request removing legacy networking code, including AX.25


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:
=== Repositories and source trees ===


* modem/TNC functions
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* 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


{| class="wikitable sortable"
=== Older HOWTOs ===
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf 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
| [https://github.com/la5nta/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
| [https://www.cantab.net/users/john.wiseman/Documents/LinBPQBuild.html 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
| [https://github.com/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
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ 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
| [https://www.langelaar.net/projects/jnos2/ 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 ==
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter VE3ICH’s 2001 Linux AX.25 HOWTO], useful mainly as historical background now


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.
=== Protocol references ===


=== Case 1: It works, and you do not need a new kernel right now ===
* [https://files.tapr.org/tech_docs/AX25/AX25.2.2.1997.pdf AX.25 Link Access Protocol for Amateur Packet Radio, Version 2.2]
 
* [https://ax25.net/ AX.25 Layer 2]
The least disruptive option may be to leave it alone for the moment:
* [https://www.on7lds.net/42/sites/default/files/AGWPEAPI.HTM AGWPE TCP/IP API reference]
 
* [https://github.com/wb2osz/direwolf/blob/master/doc/AX25_plus_FEC_equals_FX25.pdf Dire Wolf’s AX.25 framing and FEC documentation]
* 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 <code>linux-netdev/mod-orphan</code> 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:
 
# identify the exact interface your application expects
# determine whether that interface is kernel AX.25 specifically, or simply KISS / AGWPE / serial control
# check whether a user-space adapter, software TNC, or out-of-tree module can preserve the workflow
# 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 ==
 
* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now


== Related pages ==
== Related pages ==

Latest revision as of 19:48, 2 May 2026


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"