AX.25 on Linux: Difference between revisions

From 44Net Wiki
← Older edit
Updates for clarity and accuracy
mw push
 
(8 intermediate revisions by the same user not shown)
Line 5: Line 5:
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 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:
== In this guide ==
 
* [[AX.25 on Linux/Kernel vs user space]]: How the old kernel model differs from the user space model
* [[AX.25 on Linux/Migration options]]: Common software and migration approaches
* [[AX.25 on Linux/IP over AX.25]]: Possible directions for IP networking over AX.25
* [[AX.25 on Linux/Developing user-space tools]]: Design considerations for new work
 
== 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 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 newer kernels.
* 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, replace them, or rebuild them around newer 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.


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.
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 ==
Line 23: Line 30:
== Timeline ==
== Timeline ==


This change happened in “upstream Linux” first, referring to the mainline Linux kernel project. Distributions like Debian, Ubuntu, Fedora, and others decide for themselves when to ship newer kernels, and long-term-support distributions may stay on older kernel lines for quite a while.
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.
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.


The practical takeaway is simple: you likely have some time to plan, but you may want to pay attention to updates that include newer kernels.
So you have some time to plan, but you may want to pay attention to updates that include newer kernels.


== Am I affected? ==
== 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.
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:
You are probably using the kernel AX.25 stack if:
Line 48: Line 55:
* Your applications talk to KISS or AGWPE directly, whether to a software TNC, hardware TNC, or another packet-radio program
* 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, <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.
If you are not sure, look at how your application is configured. KISS or AGWPE options are a good sign.


== If you already have a working station ==
== 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. 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.
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) ===
=== Freeze (keep it running as is) ===
Line 66: Line 73:
=== Replace ===
=== 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.
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 ===
=== Revive ===
Line 72: Line 79:
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.  
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 [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. 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].
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.  


== Kernel vs. user space ==
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].


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.
== Further reading ==
 
The in-kernel code worked like a device driver. The <code>/etc/axports</code> file named and described AX.25 ports for the Linux AX.25 tools, while utilities like <code>kissattach</code> connected a KISS TNC or pseudo-tty to the kernel stack 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].
 
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 cover many common packet-radio uses. 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.
=== ARDC groups.io discussions ===


== Migration options ==
* [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]
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, <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.
 
{| class="wikitable"
! Software
! Current interface
! Migration approach
|-
! colspan="3" | All-in-one environments
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ]
| Implements full stack and applications; can work with KISS and AGW-compatible software
| Use its built-in applications, or integrate it through the interfaces it supports
|-
| [https://www.langelaar.net/projects/jnos2/ 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
|-
! colspan="3" | Software TNCs and soundmodems
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| rowspan="3" | User-space modem/TNC; KISS and AGWPE host-side interfaces
| rowspan="3" | Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
|-
| [http://uz7.ho.ua/packetradio.htm UZ7HO SoundModem]
|-
! colspan="3" | Endpoint applications and clients
|-
| [https://github.com/la5nta/pat Pat]
| Pluggable AX.25 engine; AGWPE support
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| KISS, AGWPE, or Linux kernel AX.25 interfaces
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| KISS or Linux kernel AX.25 interface
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| External TNC or serial interface
| KISS
|-
! colspan="3" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually pseudo-tty KISS, TCP KISS, or external TNC
| Native KISS-capable software
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| Linux AX.25 APRS digipeater
| APRS-specific replacement like aprx or other APRS software
|-
| [https://packages.debian.org/sid/ax25-tools 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
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| Linux AX.25, NET/ROM, and ROSE kernel user applications, including <code>ax25d</code>
| Application-specific replacement like LinBPQ, JNOS, Pat, or APRS software
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ 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
 
{| class="wikitable sortable"
! Project
! Project page or repo
! Technical scope
! Why inspect it
|-
| LinBPQ, BPQ32
| [https://www.cantab.net/users/john.wiseman/Documents/LinBPQBuild.html project page]
| AX.25 stack, node/BBS and APRS applications, KISS, multi-interface and IP integration
| Reference for a broad all-in-one user-space packet-radio environment
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| AX.25 stack, node/BBS, APRS, and messaging applications, KISS, AXIP, AXUDP
| Reference for structuring a nearly complete packet-radio stack in user space
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Modem/TNC functions, AX.25 framing, KISS, AGWPE, APRS tooling
| Clear reference for a maintained user-space TNC and host-side interface layer
|-
| Xastir SoundModem
| [https://github.com/Xastir/SoundModem GitHub]
| Modem/TNC functions; serial KISS or Linux AX.25 integration
| Reference for an older Linux soundmodem design that can operate either through serial KISS or kernel AX.25
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| Modem/TNC functions, KISS, AGWPE
| Another example of a user-space software-TNC design exposing standard host interfaces
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging application, AX.25 support, AGWPE
| Useful example of integrating AX.25 support into a modern end-user application
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS application, iGate and digipeater functions
| Reference for a focused application that avoids general-purpose kernel AX.25 dependencies
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS application 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 [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ 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 ===
=== 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 21, 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/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread], with more discussion
* [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]
* [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 ===
=== 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://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


=== Repositories and source trees ===
=== Repositories and source trees ===
Line 257: Line 108:
=== Older HOWTOs ===
=== Older HOWTOs ===


* [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 VE3ICH’s 2001 Linux AX.25 HOWTO], useful mainly as historical background now
 
=== Protocol references ===
 
* [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]
* [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]


== 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"