AX.25 on Linux: Difference between revisions

From 44Net Wiki
← Older editNewer edit →
mw push
Updates for clarity and accuracy
Line 3: Line 3:
{{Note|This page is a work in progress. It is not yet complete, and it may contain inaccuracies or outdated information.}}
{{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 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.


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.
The short version is:
 
* 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 such as <code>ax0</code>, <code>kissattach</code>, <code>/etc/axports</code>, or <code>ax25d</code>, it will not keep working unchanged on newer kernels.
* Nothing breaks immediately just because the upstream kernel changed. Existing systems keep working until you update them, replace them, or rebuild them around newer kernels.
 
For years, Linux 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. 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 ==
== What is changing ==


* Upcoming mainline kernel releases will no longer include the traditional AX.25 stack
* Upcoming mainline kernel releases will no longer include the traditional Linux AX.25, Net/ROM, and ROSE stack.
* Existing documentation related to these protocols will no longer apply to systems running newer kernels
* 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.
* Software that depends specifically on kernel AX.25 interfaces will be unable to run on newer kernels
* Software that depends specifically on kernel AX.25 interfaces will be unable to run unchanged on newer kernels.
* 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
* 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.
 
== Am I affected? ==


== Who is likely to be affected ==
A good first check is whether your station uses the old Linux kernel AX.25 model or a user-space TNC/application model.


=== Probably affected ===
You are probably using the kernel AX.25 stack if:


This change might affect you if:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces such as <code>ax0</code>
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</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 are probably using a user-space approach if:


=== Probably less affected ===
* <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


You are probably less affected if:
If you are not sure, look at how your application is configured. KISS or AGWPE options are usually a good sign. A configuration that refers only to a Linux AX.25 port, <code>ax</code> interface, <code>/etc/axports</code>, or <code>ax25d</code> is a sign that you may need to freeze, reconfigure, or replace part of the station.
* <code>ifconfig</code> or <code>ip link</code> does not show any <code>ax</code> interfaces on your system
* You already use a user-space TNC like Dire Wolf (without <code>kissattach</code>)
* 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 ==
== If you already have a working station ==


The in-kernel code worked like a device driver. The <code>/etc/axports</code> file defined a radio port, which was at the time usually a serial port connected to a hardware TNC. The <code>kissattach</code> tool took that port and created an <code>ax</code> 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.
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. The best choice depends on your specific use case, how much existing software you need to preserve, and how much you are willing or able to change.


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.
=== Freeze (keep it running as is) ===


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


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.
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 are just getting started ==
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.


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


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.  
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 anything from replacing one piece to 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 might also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.


== If you’re more established ==
=== Revive ===


If you are already running packet radio on Linux, the first question is what you want continued operation of your station to look like.
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.  


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.
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 to 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 [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].


=== Freeze (keep it running as is) ===
== Kernel vs. user space ==


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.
An understanding of the difference between in-kernel and user-space implementations of AX.25 is helpful when considering the impact of the kernel code removal and the options for moving forward.


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.
The in-kernel code worked like a device driver. The <code>/etc/axports</code> file defined a radio port, typically a serial port connected to a hardware TNC and thus a radio. Applications could use that port like a device. The <code>kissattach</code> tool, for example, took that port and created an <code>ax</code> network interface. You could assign that interface an IP address, network applications could interact with it like any other network interface, and code in the kernel would handle AX.25 framing and interacting with the TNC using [https://www.ka9q.net/papers/kiss.html the KISS protocol].


=== Reconfigure ===
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 by various means, and it in turn provides a KISS, AGWPE, TCP, or other interface for other applications to use. This is less like a device driver and more like a server daemon that client applications can connect to.


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.
Much of the current packet-radio software ecosystem already works this way. APRS clients, software TNCs, and all-in-one environments often keep AX.25 framing and packet-radio behavior in user space, then expose KISS, AGWPE, TCP, serial, or application-specific interfaces to the rest of the shack.


=== Replace ===
In practice, a user-space implementation can be just as capable as a kernel implementation. It can also be more flexible, easier to maintain, and more portable, since it does not depend on specific kernel versions or interfaces and can be developed independently of the kernel release cycle.


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


=== Revive ===
== If you are just getting started ==


If you have the technical interest and motivation, there’s nothing to stop you reviving the kernel code in the out-of-tree repository.  
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.  


The long absence of maintainers for the code that was just removed might be an indication of the challenges of this path.
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 will see are outdated or inapplicable. 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. Rather than looking into AX.25 per se, it may be more helpful to investigate specific applications and see how they use AX.25 for things like APRS and messaging.


== Migration options ==
== Migration options ==


The main question is simpler than the table might make it look:
The table below shows what common software expects and what you can do going forward. It is meant to be illustrative rather than exhaustive. For any software, the general pattern is:


* 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 can already speak KISS or AGWPE over serial or network interfaces, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint using a supported protocol.
* If your application requires Linux AX.25 sockets, <code>ax</code> interfaces, <code>kissattach</code>, <code>ax25d</code>, or the related kernel tools, there may not be a direct drop-in migration path on newer kernels.
* If your application requires Linux AX.25 sockets, <code>ax</code> interfaces, <code>kissattach</code>, <code>ax25d</code>, or the related kernel tools, there will 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 <code>ax</code> interface, that is not as good a sign.
* 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 <code>ax</code> 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.


{| class="wikitable"
{| class="wikitable"
! Software
! Software
! Current interface
! Current interface
! Common migration target
! Migration approach
|-
|-
! colspan="3" | All-in-one environments
! colspan="3" | All-in-one environments
|-
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ / BPQ32]
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ]
| Implements full stack and applications; provides KISS, AXIP/UDP, AGWPE interfaces
| Implements full stack and applications; can work with KISS and AGW type interfaces
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
| Use its built-in applications, or integrate it through the interfaces it supports
|-
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Implements full stack and applications; provides KISS and AGWPE interfaces
| Implements full stack and applications; KISS-oriented, with AXIP and AXUDP support
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
| Use its built-in applications, or integrate it through KISS-oriented links
|-
|-
! colspan="3" | Software TNCs and soundmodems
! colspan="3" | Software TNCs and soundmodems
|-
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| [https://github.com/wb2osz/direwolf Dire Wolf]
| KISS over TCP/serial; AGWPE over TCP
| rowspan="3" | User-space modem/TNC; KISS and AGWPE host-side interfaces
| Point your applications at its KISS or AGWPE endpoint
| rowspan="3" | Point your applications at its KISS or AGWPE endpoint
|-
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Point your applications at its KISS endpoint
|-
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Point your applications at its KISS or AGWPE endpoint
|-
|-
! colspan="3" | Endpoint applications and clients
! colspan="3" | Endpoint applications and clients
|-
|-
| [https://github.com/la5nta/pat Pat]
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Pluggable AX.25 engine; AGWPE support
| AGWPE
| AGWPE
|-
|-
| [https://github.com/Xastir/Xastir Xastir]
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| KISS, AGWPE, or Linux kernel AX.25 interfaces
| KISS or AGWPE
| KISS or AGWPE
|-
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| KISS or Linux kernel AX.25 interface
| KISS
| KISS
|-
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| External TNC or serial interface
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| KISS
| KISS
|-
|-
Line 138: Line 140:
|-
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Usually pseudo-tty KISS, TCP KISS, or external TNC
| KISS
| Native KISS-capable software
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| Linux AX.25 APRS digipeater
| APRS-specific replacement such as aprx or other APRS software
|-
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| Linux AX.25, NET/ROM, and ROSE kernel configuration tools
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
| No direct equivalent; keep only in legacy environments or replace with user-space TNC tooling
|-
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Linux AX.25, NET/ROM, and ROSE kernel user applications, including <code>ax25d</code>
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
| Application-specific replacement such as LinBPQ, JNOS, Pat, or APRS software
|-
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| Converts Linux kernel AX.25 interfaces into pseudo-tty KISS
| No direct equivalent; consider refactoring your stack
| No direct equivalent; replace the kernel-binding pattern with a native KISS or AGWPE source
|}
|}


== Developing new user-space AX.25 tools ==
== Developing new user-space AX.25 tools ==


Many of the building blocks 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:
AX.25 may be considered active enough to justify new user-space implementations. Many of the building blocks already exist in open source. Before starting a brand-new user-space AX.25 project, it might be worth looking first at software that already does some or all of the following:


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


{| class="wikitable sortable"
{| class="wikitable sortable"
! Project
! Project
! Project page / repo
! Project page or repo
! What it already covers
! Technical scope
! Why it is worth inspecting
! Why inspect it
|-
| LinBPQ, BPQ32
| [https://www.cantab.net/users/john.wiseman/Documents/LinBPQBuild.html project page]
| Full packet stack, node/BBS functions, multiple radio and network interfaces
| Reference for a broad all-in-one user-space packet-radio environment
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Full packet-radio environment, applications, and packet stack
| Reference for structuring a nearly complete packet-radio stack in user space
|-
|-
| Dire Wolf
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| Software TNC, AX.25 framing, KISS, AGWPE, APRS-oriented tooling
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
| Clear reference for a maintained user-space TNC and host-side interface layer
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the goal is mainly messaging
|-
| 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
| Xastir SoundModem
| [https://github.com/Xastir/SoundModem GitHub]
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Software modem/TNC functions for host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
| Reference for modem/TNC implementation separate from the client application
|-
|-
| QtSoundModem
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Software modem/TNC, KISS, AGWPE
| Another active example of the “software TNC in user space” approach
| Another example of a user-space software-TNC design exposing standard host interfaces
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client, AX.25 support, AGWPE integration
| Useful example of integrating AX.25 support into a modern end-user application
|-
|-
| aprx
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| APRS iGate and digipeater functions
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
| Reference for a focused application that avoids general-purpose kernel AX.25 dependencies
|-
|-
| YAAC
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
| Example of an application-layer design that works through external TNC interfaces
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Implements almost everything needed for a classic packet-radio setup in user space, and can be used as a reference for how to structure a complete user-space stack
|}
|}


== What of IP over AX.25 ==
== IP over AX.25 ==


If your goal is specifically IP over AX.25, the range of options has narrowed.
If your goal is specifically IP over AX.25, the range of options has narrowed.
Line 223: Line 229:
* Narrower, more maintainable components rather than a large in-kernel subsystem
* 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.
For now, end users may need to stay on an older kernel until a user-space solution emerges. Interested developers might look into this as an area for contributions to new or existing projects.


== External resources ==
== Further reading ==
 
=== Kernel discussions ===


* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [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/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]
=== Independent coverage ===
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [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]
 
=== Repositories and source trees ===
 
* [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/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
=== Older HOWTOs ===
* [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
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now


Revision as of 15:07, 1 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.

The short version is:

  • 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 such as ax0, kissattach, /etc/axports, or ax25d, it will not keep working unchanged on newer kernels.
  • Nothing breaks immediately just because the upstream kernel changed. Existing systems keep working until you update them, replace them, or rebuild them around newer kernels.

For years, Linux 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. 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

  • Upcoming mainline kernel releases will no longer include 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.

Am I affected?

A good first check is whether your station uses the old Linux kernel AX.25 model or a user-space TNC/application model.

You are probably using the kernel AX.25 stack if:

  • ifconfig or ip link shows ax interfaces such as 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 usually a good sign. A configuration that refers only to a Linux AX.25 port, ax interface, /etc/axports, or ax25d is a sign that you may need to freeze, reconfigure, or replace part of the station.

If you already have a working station

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. The best choice depends on your specific use case, how much existing software you need to preserve, 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 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 KISS, AGWPE, serial, TCP, or 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 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 to 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.

Kernel vs. user space

An understanding of the difference between in-kernel and user-space implementations of AX.25 is helpful when considering the impact of the kernel code removal and the options for moving forward.

The in-kernel code worked like a device driver. The /etc/axports file defined a radio port, typically a serial port connected to a hardware TNC and thus a radio. Applications could use that port like a device. The kissattach tool, for example, took that port and created an ax network interface. You could assign that interface an IP address, network applications could interact with it like any other network interface, and code in the kernel would handle AX.25 framing and interacting with the TNC using the KISS protocol.

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 by various means, and it in turn provides a KISS, AGWPE, TCP, or other interface for other applications to use. This is less like a device driver and more like a server daemon that client applications can connect to.

Much of the current packet-radio software ecosystem already works this way. APRS clients, software TNCs, and all-in-one environments often keep AX.25 framing and packet-radio behavior in user space, then expose KISS, AGWPE, TCP, serial, or application-specific interfaces to the rest of the shack.

In practice, a user-space implementation can be just as capable as a kernel implementation. It can also be more flexible, easier to maintain, and more portable, since it does not depend on specific kernel versions or interfaces and can be developed 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 will see are outdated or inapplicable. 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. Rather than looking into AX.25 per se, it may be more helpful to investigate specific applications and see how they use AX.25 for things like APRS and messaging.

Migration options

The table below shows what common software expects and what you can do going forward. It is meant to be illustrative rather than exhaustive. For any software, the general pattern is:

  • If your application can already speak KISS or AGWPE over serial or network interfaces, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint using a supported protocol.
  • If your application requires Linux AX.25 sockets, ax interfaces, kissattach, ax25d, or the related kernel tools, there will 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.
Software Current interface Migration approach
All-in-one environments
LinBPQ Implements full stack and applications; can work with KISS and AGW type interfaces Use its built-in applications, or integrate it through the interfaces it supports
JNOS 2 Implements full stack and applications; KISS-oriented, with AXIP and AXUDP support Use its built-in applications, or integrate it through KISS-oriented links
Software TNCs and soundmodems
Dire Wolf User-space modem/TNC; KISS and AGWPE host-side interfaces Point your applications at its KISS or AGWPE endpoint
QtSoundModem
SoundModem
Endpoint applications and clients
Pat Pluggable AX.25 engine; AGWPE support AGWPE
Xastir KISS, AGWPE, or Linux kernel AX.25 interfaces KISS or AGWPE
aprx KISS or Linux kernel AX.25 interface KISS
YAAC External TNC or serial interface KISS
Legacy patterns and kernel-bound tools
KISS-oriented legacy applications generally Usually pseudo-tty KISS, TCP KISS, or external TNC Native KISS-capable software
aprsdigi Linux AX.25 APRS digipeater APRS-specific replacement such as aprx or other APRS software
ax25-tools Linux AX.25, NET/ROM, and ROSE kernel configuration tools No direct equivalent; keep only in legacy environments or replace with user-space TNC tooling
ax25-apps Linux AX.25, NET/ROM, and ROSE kernel user applications, including ax25d Application-specific replacement such as LinBPQ, JNOS, Pat, or APRS software
net2kiss Converts Linux kernel AX.25 interfaces into pseudo-tty KISS No direct equivalent; replace the kernel-binding pattern with a native KISS or AGWPE source

Developing new user-space AX.25 tools

AX.25 may be considered active enough to justify new user-space implementations. Many of the building blocks already exist in open source. Before starting a brand-new user-space AX.25 project, it might be worth looking first at software that already does some or all of the following:

  • Modem/TNC functions
  • AX.25 framing
  • KISS or AGWPE host-side interfaces
  • APRS, BBS, node, or messaging applications
  • Integration with modern Linux networking through user-space boundaries like TUN/TAP
Project Project page or repo Technical scope Why inspect it
LinBPQ, BPQ32 project page Full packet stack, node/BBS functions, multiple radio and network interfaces Reference for a broad all-in-one user-space packet-radio environment
JNOS 2 project page Full packet-radio environment, applications, and packet stack Reference for structuring a nearly complete packet-radio stack in user space
Dire Wolf GitHub Software TNC, AX.25 framing, KISS, AGWPE, APRS-oriented tooling Clear reference for a maintained user-space TNC and host-side interface layer
Xastir SoundModem GitHub Software modem/TNC functions for host applications Reference for modem/TNC implementation separate from the client application
QtSoundModem project page Software modem/TNC, KISS, AGWPE Another example of a user-space software-TNC design exposing standard host interfaces
Pat GitHub Messaging client, AX.25 support, AGWPE integration Useful example of integrating AX.25 support into a modern end-user application
aprx project page APRS iGate and digipeater functions Reference for a focused application that avoids general-purpose kernel AX.25 dependencies
YAAC project page APRS client and related tooling Example of an application-layer design that works through external TNC interfaces

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, end users may need to stay on an older kernel until a user-space solution emerges. Interested developers might look into this as an area for contributions to new or existing projects.

Further reading

Kernel discussions

Independent coverage

Repositories and source trees

Older HOWTOs

Related pages

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