AX.25 on Linux: Difference between revisions

From 44Net Wiki
mw push
 
mw push
 
(16 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.}}
 
For years, Linux has included an in-kernel implementation of AX.25, Net/ROM, and ROSE. This provided network interfaces for connected-mode packet, and user-space applications could rely on those interfaces for their AX.25 needs.


As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This page explains the current situation and outlines practical options going forward.
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.
Line 16: Line 18:
=== Probably affected ===
=== Probably affected ===


* Operators running older Linux packet-radio setups that depend on kernel AX.25 interfaces
This change might affect you if:
* Users of older applications that assume AX.25 support is available through the Linux kernel network stack
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* Maintainers of software that has never needed to implement its own AX.25 handling because Linux already provided it
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>


=== Probably less affected ===
=== Probably less affected ===


* Operators already using user-space TNCs or modem software like Dire Wolf
You are probably less affected if:
* Applications for things like APRS that already handle AX.25 internally and do not depend on Linux kernel interfaces
* <code>ifconfig</code> or <code>ip link</code> does not show any <code>ax</code> interfaces on your system
* People experimenting with newer software that does not depend on the old kernel path
* 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


== Not the end of AX.25 ==
== Kernel vs. user space ==


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


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


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


Today, a lot of practical packet-radio software already uses or is compatible with user-space implementations.
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.
 
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.


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


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


== Next-step paths ==
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.


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’re more established ==


=== “Freeze” ===
If you are already running packet radio on Linux, the first question is what you want continued operation of your station to look like.


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


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


This path makes sense mainly if:
The long absence of maintainers for the code that was just removed might be an indication of the challenges of this path.


* you have a real use case that still requires the old kernel semantics
== Migration options ==
* you are willing to do development and maintenance work
* you are trying to preserve something beyond one private station


== Compatibility snapshot ==
The main question is simpler than the table might make it look:


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.
* If your application can already speak KISS or AGWPE, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint that provides the same host-side interface.
* If your application requires Linux AX.25 sockets, <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 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.


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.
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 sortable"
{| class="wikitable"
! Software
! Software
! Current interface
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
! Common migration target
|-
! colspan="3" | All-in-one environments
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ / BPQ32]
| Implements full stack and applications; provides KISS, AXIP/UDP, AGWPE interfaces
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Implements full stack and applications; provides KISS and AGWPE interfaces
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
|-
! colspan="3" | Software TNCs and soundmodems
|-
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| KISS over TCP/serial; AGWPE over TCP
| Yes
| Point your applications at its KISS or AGWPE endpoint
| Bridge or Replace
|-
| Dire Wolf as the anchor itself, or paired with Pat / Xastir / aprx
| [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]
| 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
|-
|-
| [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
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| AGWPE
| 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]
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| KISS or AGWPE
| Reconfigure
| Dire Wolf or another KISS/AGWPE-capable software TNC
|-
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Serial KISS or kernel AX.25 interface
| Depends
| KISS
| Reconfigure
| Dire Wolf or a hardware KISS TNC
|-
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| User-space APRS client using external TNCs / serial interfaces
| Yes
| KISS
| Reconfigure
| Existing external TNC, or Dire Wolf acting as one
|-
|-
| [https://github.com/Xastir/SoundModem SoundModem]
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| User-space modem/TNC; can expose KISS and other interfaces
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| KISS
| 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]
! colspan="3" | Legacy patterns and kernel-bound tools
| 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]
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| KISS
| 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]
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| 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
| 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]
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
| 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]
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| No direct equivalent; consider refactoring your stack
| Revive
| Replace the whole pattern with a native user-space KISS or AGWPE source
|}
|}


Some notes about reading the table:
== Developing new user-space AX.25 tools ==


* '''Yes''' means the software already has a credible path that does not require the removed in-tree kernel stack.
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:
* '''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 ==
* Modem/TNC functions
 
One strong theme in this transition is that many of the building blocks people need already exist in open source. Before starting a brand-new user-space AX.25 implementation, it is worth looking first at projects that already do some or all of the following:
 
* modem/TNC functions
* AX.25 framing
* 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 application layers
* integration with modern Linux networking through user-space boundaries
* Integration with modern Linux networking through user-space boundaries


{| class="wikitable sortable"
{| class="wikitable sortable"
Line 238: Line 178:
| [https://github.com/la5nta/pat GitHub]
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Messaging client with AX.25 support and AGWPE integration
| Useful when the real goal is messaging workflow rather than rebuilding low-level plumbing
| Useful when the goal is mainly messaging
|-
|-
| LinBPQ / BPQ32
| LinBPQ / BPQ32
Line 252: Line 192:
| 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-style interfaces
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
| Another active example of the “software TNC in user space” approach
|-
|-
Line 263: Line 203:
| [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 does not depend on the Linux AX.25 kernel stack
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
|-
| JNOS 2
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Packet-radio networking environment and applications
| Worth inspecting for people whose real interest is preserving classic packet workflows rather than Linux kernel semantics
| 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
|}
|}


== If you already have an older setup ==
== What of IP over AX.25 ==
 
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.
 
=== Case 1: It works, and you do not need a new kernel right now ===
 
The least disruptive option may be to leave it alone for the moment:
 
* 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:
If your goal is specifically IP over AX.25, the range of options has narrowed.


* which kernel version it depends on
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.
* 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:
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
* AX.25 framing and control in user space
* integration to IP through TUN/TAP or similar interfaces
* Integration with IP through TUN/TAP or similar interfaces
* narrower, more maintainable components rather than a large in-kernel subsystem
* 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?
For now, you may need to stay on an older kernel until a user-space solution emerges.
* 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 ==
== 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://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://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://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://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.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [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://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/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio

Latest revision as of 02:01, 1 May 2026


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

For years, Linux has included an in-kernel implementation of AX.25, Net/ROM, and ROSE. This provided network interfaces for connected-mode packet, and user-space applications could rely on those interfaces for their AX.25 needs.

As of April 2026, the in-tree kernel AX.25 stack has been removed from upstream Linux. This page explains the current situation and outlines practical options going forward.

What is changing

  • Upcoming mainline kernel releases will no longer include the traditional AX.25 stack
  • Existing documentation related to these protocols will no longer apply to systems running newer kernels
  • Software that depends specifically on kernel AX.25 interfaces will be unable to run on newer kernels
  • The out-of-tree repository linux-netdev/mod-orphan will host the removed code for those who want to inspect it or maintain it separately

Who is likely to be affected

Probably affected

This change might affect you if:

  • ifconfig or ip link shows ax interfaces on your system
  • You use kissattach
  • You configure /etc/axports
  • You use ax25d

Probably less affected

You are probably less affected if:

  • ifconfig or ip link does not show any ax interfaces on your system
  • You already use a user-space TNC like Dire Wolf (without kissattach)
  • The app you use has its own AX.25 built in (common with APRS software)
  • You’re using applications that can talk to KISS or AGWPE directly, to either a software or hardware TNC

Kernel vs. user space

The in-kernel code worked like a device driver. The /etc/axports file defined a radio port, which was at the time usually a serial port connected to a hardware TNC. The kissattach tool took that port and created an ax network interface. You could assign that interface an IP address, route through it, and throw data at it, and the kernel would frame it as AX.25 and send it out to the radio for transmission.

A user-space implementation, on the other hand, implements AX.25 in an executable binary that you run separately, not as part of the kernel. It might interface with an external hardware TNC over a serial port, it might work with a software soundmodem, or it might be an all-in-one soundmodem and software TNC combined. You configure it to talk to your radio, and then you point your applications at it through KISS, AGWPE, TCP, etc.; the kernel never needs to know that AX.25 is involved at all.

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

All this being the case, removing AX.25 from the kernel is significant mainly for people preserving older working systems or using software that was introduced years ago and only supports the old kernel interfaces.

If you are just getting started

If you are new to packet radio on Linux, you may already be using user-space AX.25 in the form of APRS clients or software TNCs like Dire Wolf.

If you are learning, you face the challenge that much of the documentation currently available still refers to the old kernel-based model. This means a lot of the first search results you see may be outdated or not directly applicable to your situation. That documentation might still be useful for understanding the basics of AX.25, but it is unlikely to be a good guide for how to set up a new station today.

If you’re more established

If you are already running packet radio on Linux, the first question is what you want continued operation of your station to look like.

Broadly speaking, there are at least a few paths: keep it running as is, reconfigure the pieces around the radio, or replace part of the stack. The best choice depends on your specific use case, how much you want to preserve existing software, and how much you are willing or able to change.

Freeze (keep it running as is)

If you’re using software that depends on kernel AX.25, future kernel updates will break it. If you want to keep that software working, the simplest path may be to stay on the version of Linux you have now.

You can keep using that system for as long as you like, but you will find ample advice to consider the security implications. Older kernels do not receive fixes for newly discovered vulnerabilities, and the longer a system stays pinned to an old kernel, the more exposed it can become. If you choose this path, it is worth taking extra precautions to secure the system.

Reconfigure

If you’re using software released relatively recently, you may be able to reconfigure it. For example, an APRS application that can use AGWPE or KISS over TCP 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 rebuilding your stack from top to bottom. Depending on your goals, you might consider something that has AX.25 and common packet tools built in, like LinBPQ or JNOS. You mght also consider a more modular approach, with a software TNC like Dire Wolf and separate applications for messaging, BBS, or APRS.

Revive

If you have the technical interest and motivation, there’s nothing to stop you reviving the kernel code in the out-of-tree repository.

The long absence of maintainers for the code that was just removed might be an indication of the challenges of this path.

Migration options

The main question is simpler than the table might make it look:

  • If your application can already speak KISS or AGWPE, you probably do not need Linux kernel AX.25. Point the application at a software TNC, hardware TNC, or other endpoint that provides the same host-side interface.
  • If your application requires Linux AX.25 sockets, ax interfaces, kissattach, ax25d, or the related kernel tools, there may not be a direct drop-in migration path on newer kernels.
  • If you are not sure, look at how you configure the application. If you see KISS or AGWPE options, that is a good sign. If you only have the option to point at an ax interface, that is not as good a sign.

The “Common migration target” column is therefore mostly about host-side interfaces, not about naming one preferred tool. A KISS or AGWPE endpoint might come from Dire Wolf, QtSoundModem, SoundModem, a hardware TNC, or another program that exposes the same kind of interface.

Software Current interface Common migration target
All-in-one environments
LinBPQ / BPQ32 Implements full stack and applications; provides KISS, AXIP/UDP, AGWPE interfaces Point applications at its KISS or AGWPE endpoint, or use its built-in applications
JNOS 2 Implements full stack and applications; provides KISS and AGWPE interfaces Point applications at its KISS or AGWPE endpoint, or use its built-in applications
Software TNCs and soundmodems
Dire Wolf KISS over TCP/serial; AGWPE over TCP Point your applications at its KISS or AGWPE endpoint
QtSoundModem User-space modem/TNC; KISS and AGWPE host-side interfaces Point your applications at its KISS endpoint
SoundModem User-space modem/TNC; KISS and AGWPE host-side interfaces Point your applications at its KISS or AGWPE endpoint
Endpoint applications and clients
Pat AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP AGWPE
Xastir Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports KISS or AGWPE
aprx Serial KISS or kernel AX.25 interface KISS
YAAC User-space APRS client using external TNCs / serial interfaces KISS
aprsdigi APRS digipeater software; commonly used with KISS TNCs KISS
Legacy patterns and kernel-bound tools
KISS-oriented legacy applications generally Usually external TNC, pseudo-tty KISS, or TCP KISS KISS
ax25-tools Tools for configuring Linux AX.25 / NET/ROM / ROSE ports None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
ax25-apps User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including ax25d Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
net2kiss Converts a kernel AX.25 network interface into a pseudo-tty KISS stream No direct equivalent; consider refactoring your stack

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:

  • Modem/TNC functions
  • AX.25 framing
  • KISS or AGWPE host-side interfaces
  • APRS, BBS, node, or messaging application layers
  • Integration with modern Linux networking through user-space boundaries
Project Project page / repo What it already covers Why it is worth inspecting
Dire Wolf GitHub Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
Pat GitHub Messaging client with AX.25 support and AGWPE integration Useful when the goal is mainly messaging
LinBPQ / BPQ32 project page Node, BBS, switch, packet stack, multiple radio/network interfaces Covers a broad slice of packet-radio infrastructure and may already solve the “legacy node/BBS” use case
Xastir SoundModem GitHub User-space modem/TNC functions for packet-radio host applications Worth studying as an existing open-source modem implementation rather than inventing one from scratch
QtSoundModem project page User-space modem/TNC with KISS and AGWPE interfaces Another active example of the “software TNC in user space” approach
aprx project page APRS iGate and digipeater software Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
YAAC project page APRS client and related tooling Useful as an example of an application-layer approach that can use user-space TNCs
JNOS 2 project page Packet-radio networking environment and applications 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

If your goal is specifically IP over AX.25, the range of options has narrowed.

The upstream discussion explicitly points out that IP over AX.25 can, in principle, be handled from user space via TUN/TAP integration rather than by requiring the historic kernel implementation.

That does not mean there is one complete drop-in replacement ready for every old Linux AX.25 workflow today. It does suggest a long-term architectural direction:

  • AX.25 framing and control in user space
  • Integration with IP through TUN/TAP or similar interfaces
  • Narrower, more maintainable components rather than a large in-kernel subsystem

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

External resources

Related pages

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