44Net Wiki - User contributions [en]

Tunnel

2026-05-28T21:47:14Z

KI5QKX: KI5QKX moved page Tunnel to Term:Tunnel: Moving standalone term page into term namespace

#REDIRECT [[Term:Tunnel]]

Term:Tunnel

2026-05-28T21:47:14Z

KI5QKX: KI5QKX moved page Tunnel to Term:Tunnel: Moving standalone term page into term namespace

From: [https://en.wikipedia.org/wiki/IP_tunnel]:

An IP tunnel is an Internet Protocol (IP) network communications channel between two networks. It is used to transport another network protocol by encapsulation of its packets.

IP tunnels are often used for connecting two disjoint IP networks that don't have a native routing path to each other, via an underlying routable protocol across an intermediate transport network.

[[Category:Reference]]
[[Category:Participation Methods]]

RFC 790

2026-05-05T19:28:18Z

KI5QKX: mw push

{{DISPLAYTITLE: RFC 790 - Assigned Numbers}}

[http://www.rfc-editor.org/rfc/rfc790.txt RFC 790] is a [https://en.wikipedia.org/wiki/Request_for_Comments “Request For Comments” (RFC)] document that lists protocol numbers, port numbers, and IP addresses assigned in the early days of what would become the Internet. It is the document that first established the assignment of network 44 for amateur radio purposes.

== History ==

Before the modern Internet, what was then known as ARPANET was administered somewhat manually. Whenever there was a new development concerning the network, like a new protocol, application, or network assignment, an RFC document proposing the change would be typewritten and circulated among the network operators. If there was general agreement, the change was adopted.

[https://en.wikipedia.org/wiki/Jon_Postel Jon Postel] at the University of Southern California's [https://en.wikipedia.org/wiki/USC_Information_Sciences_Institute Information Sciences Institute (USC-ISI)] served as editor of the RFC series from its inception in 1969 until his death in 1998. During that time, if someone needed a new network assigned, he would generally be the one to assign it.

In 1981, seeing an opportunity to support the amateur packet radio networks emerging along the west coast, [https://en.wikipedia.org/wiki/Hank_Magnuski Hank Magnuski] (now KA6M) contacted Postel to ask about setting a network aside for amateur radio use. Jon agreed. The next available number for a network was 44.

Postel included the assignment of network 44 for amateur radio use in RFC 790, published in September 1981, and network 44 was born.

== Errors ==

The document makes two small mistakes related to network 44. It misspells “amateur” as “amature,” and it shows networks 44 through 126 as “unassigned,” even though network 44 was assigned on the immediately preceding line.

RFCs are archival and not retroactively corrected in place. When ARDC publishes images or copies of RFC 790 in relation to the creation of network 44, it preserves these errors as part of the historical record.

[[Category: Explanation]]
[[Category: History]]
[[Category: Reference]]

RFC 790

2026-05-05T19:27:11Z

KI5QKX: mw push

{{DISPLAYTITLE: RFC 790 - Assigned Numbers}}

[http://www.rfc-editor.org/rfc/rfc790.txt RFC 790] is a [https://en.wikipedia.org/wiki/Request_for_Comments “Request For Comments” (RFC)] document that lists protocol numbers, port numbers, and IP addresses assigned in the early days of what would become the Internet. It is the document that first established the assignment of network 44 for amateur radio purposes.

== History ==

Before the Internet came to exist as we know it today, what was then known as ARPANET was administered somewhat manually. Whenever there was a new development concerning the network, like a new protocol, application, or network assignment, an RFC document proposing the change would be typewritten and circulated among the network operators. If there was general agreement, the change was adopted.

[https://en.wikipedia.org/wiki/Jon_Postel Jon Postel] at the University of Southern California's [https://en.wikipedia.org/wiki/USC_Information_Sciences_Institute Information Sciences Institute (USC-ISI)] served as editor of the RFC series from its inception in 1969 until his death in 1998. During that time, if someone needed a new network assigned, he would generally be the one to assign it.

In 1981, seeing an opportunity to support the amateur packet radio networks emerging along the west coast, [https://en.wikipedia.org/wiki/Hank_Magnuski Hank Magnuski] (now KA6M) contacted Postel to ask about setting a network aside for amateur radio use. Jon agreed. The next available number for a network was 44.

Postel included the assignment of network 44 for amateur radio use in RFC 790, published in September 1981, and network 44 was born.

== Errors ==

The document makes two small mistakes related to network 44. It misspells “amateur” as “amature,” and it shows networks 44 through 126 as “unassigned,” even though network 44 was assigned on the immediately preceding line.

RFCs are archival and not retroactively corrected in place. When ARDC publishes images or copies of RFC 790 in relation to the creation of network 44, it preserves these errors as part of the historical record.

[[Category: Explanation]]
[[Category: History]]
[[Category: Reference]]

AX.25 on Linux/Developing user-space tools

2026-05-02T19:55:16Z

KI5QKX: mw push

{{DISPLAYTITLE:Developing user-space tools}}

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

''Main article: [[AX.25 on Linux]]''

Following the removal of AX.25 from the Linux kernel, there is an opportunity for new user-space tools to fill the gap for various AX.25 use cases. 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

Here are some open-source projects that might be worth looking at. This is not an exhaustive list.

{| class="wikitable sortable"
! Project
! Project page or repo
! Technical scope
! Why it might be worth looking at
|-
| 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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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
|}

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/Developing user-space tools

2026-05-02T19:54:29Z

KI5QKX: mw push

{{DISPLAYTITLE:Developing user-space tools}}

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

''Main article: [[AX.25 on Linux]]''

Following the removal of AX.25 from the Linux kernel, there is an opportunity for new user-space tools to fill the gap for various AX.25 use cases. 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

Here are some open-source projects that might be worth inspecting. This is not an exhaustive list.

{| 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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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
|}

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/IP over AX.25

2026-05-02T19:52:18Z

KI5QKX: mw push

{{DISPLAYTITLE:IP over AX.25}}

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

''Main article: [[AX.25 on Linux]]''

If your goal with AX.25 on Linux is specifically IP over AX.25, the removal of AX.25 from the Linux kernel has narrowed the range of options.

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

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/IP over AX.25

2026-05-02T19:51:56Z

KI5QKX: mw push

{{DISPLAYTITLE:IP over AX.25}}

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

''Main article: [[AX.25 on Linux]]''

If your goal with AX.25 on Linux 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/Migration options

2026-05-02T19:50:32Z

KI5QKX: mw push

{{DISPLAYTITLE:Migration options}}

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

''Main article: [[AX.25 on Linux]]''

If you are affected by the removal of AX.25 from the Linux kernel and need to migrate, there are several approaches you can take.

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

[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-02T19:48:01Z

KI5QKX: mw push

AX.25 on Linux/Migration options

2026-05-02T19:48:01Z

KI5QKX: mw push

{{DISPLAYTITLE:Migration options}}

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

''Main article: [[AX.25 on Linux]]''

If you are affected and need to migrate, there are several approaches you can take.

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

[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux/Kernel vs user space

2026-05-02T19:48:01Z

KI5QKX: mw push

{{DISPLAYTITLE:Kernel vs. user space}}

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

''Main article: [[AX.25 on Linux]]''

This section provides background on how AX.25 has been implemented on Linux and why the kernel change affects some systems but not others.

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

=== In-kernel AX.25 ===

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

=== User-space AX.25 ===

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.

== If you are more established ==

If you have an existing station, the first step is to determine whether it depends on the kernel AX.25 stack. If it does, you will need to consider how to freeze, reconfigure, or replace part of your station to keep it working on newer kernels. If it does not, you may be able to keep using your station as it is without worrying about the kernel change. See [[AX.25 on Linux#Am I affected?|Am I affected?]] for tips on how to tell.

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/Developing user-space tools

2026-05-02T19:48:00Z

KI5QKX: mw push

{{DISPLAYTITLE:Developing user-space tools}}

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

''Main article: [[AX.25 on Linux]]''

This section is primarily relevant to developers or those evaluating new work in the packet-radio ecosystem.

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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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
|}

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux/IP over AX.25

2026-05-02T19:48:00Z

KI5QKX: mw push

{{DISPLAYTITLE:IP over AX.25}}

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

''Main article: [[AX.25 on Linux]]''

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

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

[[Category:Explanation]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T18:02:46Z

KI5QKX: fix links

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

=== ARDC groups.io discussions ===

* [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]

=== Kernel discussions ===

* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch], proposing removal of the in-tree amateur-radio networking subsystem
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread], with more discussion
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch], noting that AX.25, ROSE, and NET/ROM have been removed upstream
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction], including TUN/TAP for IP over AX.25

=== Independent coverage ===

* [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 ===

* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged

=== Older HOWTOs ===

* [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 ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T18:00:35Z

KI5QKX: fix heading typo

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

=== ARDC groups.io discussions ===

* [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]

=== Kernel discussions ===

* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread with more discussion]
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]

=== Independent coverage ===

* [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 ===

* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s 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 ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T18:00:00Z

KI5QKX: add some 44net mailing list links

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

=== ARDC groups.io discussions ==

* [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]

=== Kernel discussions ===

* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread with more discussion]
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]

=== Independent coverage ===

* [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 ===

* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s 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 ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T17:40:00Z

KI5QKX: add links to other coverage and mailing list thread

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

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

=== Kernel discussions ===

* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/ Jakub Kicinski’s April 21, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://lore.kernel.org/lkml/20260423235422.1541768-1-kuba@kernel.org/ Jakub Kicinski’s April 23, 2026 pull-request thread with more discussion]
* [https://lore.kernel.org/netdev/20260424232427.792249-1-stephen@networkplumber.org/ Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lore.kernel.org/netdev/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6dHTT9krFiTkotjTuTA@mail.gmail.com/ Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]

=== Independent coverage ===

* [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 ===

* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T17:34:56Z

KI5QKX: Add ax.25/fx.25 paper

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

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

=== 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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T17:30:05Z

KI5QKX: add some further reading

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== Further reading ==

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

=== 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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T17:15:50Z

KI5QKX: Add tncattach discussion

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

The practical takeaway is: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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, as 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.

One current project that might be relevant for IP over amateur radio projects is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack.

It is not a user-space replacement for the old Linux AX.25 stack, and it should not be understood as preserving the historic Linux AX.25 interface model. It is aimed instead at IP or Ethernet-style networking over a TNC. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, then <code>tncattach</code> may be worth a look.

It may also be a useful reference point for future development. Even if it does not solve every AX.25-specific use case by itself, it shows one way to bridge a KISS-compatible TNC to a Linux network device without the old kernel stack, and that approach could potentially be extended further or incorporated into other projects.

== 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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T16:59:29Z

KI5QKX: Add tncattach discussion

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 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 <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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

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: you likely 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:

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

== 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 <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]. If your main use of <code>kissattach</code> was simply to turn a KISS TNC into a Linux network device for IP networking, a separate user-space project called [https://github.com/markqvist/tncattach tncattach] may also be worth a look.

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.

== 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, <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
|-
| tncattach
| [https://github.com/markqvist/tncattach GitHub]
| KISS-based Linux network-device integration for IP and Ethernet-style networking
| Reference for bridging a KISS TNC to a Linux network device without the old AX.25 kernel stack
|-
| 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.

One current project worth investigating is [https://github.com/markqvist/tncattach tncattach], a separate user-space tool that creates a Linux network interface from a KISS-compatible TNC without relying on the old kernel AX.25 stack. It is aimed at IP or Ethernet-style networking over a TNC rather than at preserving the historic Linux AX.25 interface model, so it should be understood as a different approach rather than a drop-in replacement for <code>kissattach</code>.

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

* [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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T15:58:46Z

KI5QKX: Updates for clarity and accuracy

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 like <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 ==

* Mainline Linux no longer includes the traditional Linux AX.25, Net/ROM, and ROSE stack.
* 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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

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.

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

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces like <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

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

* [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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T15:07:13Z

KI5QKX: Updates for clarity and accuracy

{{DISPLAYTITLE:AX.25 on Linux}}

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

* Upcoming mainline kernel releases will no longer include the traditional Linux AX.25, Net/ROM, and ROSE stack.
* 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 unchanged on newer kernels.
* Software that talks directly to KISS, AGWPE, serial TNCs, TCP TNCs, or its own built-in AX.25 implementation may continue to work without the kernel AX.25 stack.
* The out-of-tree repository <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately.

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

* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces such as <code>ax0</code>
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>
* Your application is configured to use a Linux AX.25 port or interface rather than KISS, AGWPE, serial, TCP, or a built-in packet engine

You are probably using a user-space approach if:

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

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

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

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, <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 type interfaces
| 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 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 such as 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 such as 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]
| 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
| [https://github.com/wb2osz/direwolf 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
| [https://github.com/Xastir/SoundModem GitHub]
| Software modem/TNC functions for host applications
| Reference for modem/TNC implementation separate from the client application
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| Software modem/TNC, KISS, AGWPE
| 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
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS 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 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 [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 ===

* [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/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]

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

=== Older HOWTOs ===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T02:01:22Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! 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]
| KISS over TCP/serial; AGWPE over TCP
| Point your applications at its KISS or AGWPE endpoint
|-
| [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]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| KISS
|-
! colspan="3" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| KISS
|-
| [https://packages.debian.org/sid/ax25-tools 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
|-
| [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>
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ 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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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, you may need to stay on an older kernel until a user-space solution emerges.

== External resources ==

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-05-01T02:01:01Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! 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]
| KISS over TCP/serial; AGWPE over TCP
| Point your applications at its KISS or AGWPE endpoint
|-
| [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]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| KISS
|-
! colspan="3" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| KISS
|-
| [https://packages.debian.org/sid/ax25-tools 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
|-
| [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>
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ 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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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, you may need to stay on an older kernel until a user-space solution emerges.

== External resources ==

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T23:09:35Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! 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]
| KISS over TCP/serial; AGWPE over TCP
| Point your applications at its KISS or AGWPE endpoint
|-
| [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]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| KISS
|-
! colspan="3" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| KISS
|-
| [https://packages.debian.org/sid/ax25-tools 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
|-
| [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>
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ 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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T23:07:38Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Common migration target
|-
! colspan="4" | 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
| Yes
| 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
| Yes
| Point applications at its KISS or AGWPE endpoint, or use its built-in applications
|-
! colspan="4" | Software TNCs and soundmodems
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| KISS over TCP/serial; AGWPE over TCP
| Yes
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Point your applications at its KISS or AGWPE endpoint
|-
! colspan="4" | Endpoint applications and clients
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| AGWPE
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| KISS or AGWPE
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| KISS
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| KISS
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| KISS
|-
! colspan="4" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| KISS
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Switch to something like LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T23:02:31Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
! colspan="5" | All-in-one environments
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ / BPQ32]
| It’s its own packet stack and node/BBS environment; provides KISS, AXIP/UDP, AGWPE interfaces
| Yes
| Reconfigure
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| It is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE. Or just use it for everything if it already covers your use case.
|-
! colspan="5" | Software TNCs and soundmodems
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
! colspan="5" | Endpoint applications and clients
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
! colspan="5" | Legacy patterns and kernel-bound tools
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:56:18Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:50:43Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [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://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]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:49:09Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/#r 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://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/#t Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:35:00Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

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

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| 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 ==

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:32:05Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf’s KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:26:54Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You configure <code>/etc/axports</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:24:42Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure
| Configure its KISS endpoint and point your applications at it. Or point it at another TNC over AGWPE.Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:12:21Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [http://uz7.ho.ua/packetradio.htm SoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure or Replace
| Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T22:08:52Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

=== Ressurect ===

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/Xastir/Xastir Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure or Replace
| Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T21:58:24Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

{{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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

=== Ressurect ===

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| KISS or AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://www.xastir.org/index.php/XASTIR_Manual Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://github.com/Xastir/SoundModem SoundModem]
| User-space modem/TNC; can expose KISS and other endpoints
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure or Replace
| Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://github.com/n2ygk/aprsdigi/ aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T21:33:45Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

=== Ressurect ===

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| KISS or AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://www.xastir.org/index.php/XASTIR_Manual Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://github.com/Xastir/SoundModem SoundModem]
| User-space modem/TNC; can expose KISS and other endpoints
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure or Replace
| Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://tracker.debian.org/pkg/aprsdigi aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

AX.25 on Linux

2026-04-30T21:25:13Z

KI5QKX: mw push

{{DISPLAYTITLE:AX.25 on Linux}}

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 <code>linux-netdev/mod-orphan</code> 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:
* <code>ifconfig</code> or <code>ip link</code> shows <code>ax</code> interfaces on your system
* You use <code>kissattach</code>
* You use <code>ax25d</code>

=== Probably less affected ===

You are probably less affected if:
* <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 ==

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.

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

=== Ressurect ===

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

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"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Reconfigure
| Set up Dire Wolf's KISS or AGWPE interface and point your applications at it
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure
| KISS or AGWPE endpoint
|-
| [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
| Configure its KISS endpoint or AXIP/UDP interface and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://www.xastir.org/index.php/XASTIR_Manual Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| KISS or AGWPE endpoint
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| KISS endpoint
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://github.com/Xastir/SoundModem SoundModem]
| User-space modem/TNC; can expose KISS and other endpoints
| Yes
| Reconfigure
| Point your applications at its KISS or AGWPE endpoint
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Reconfigure
| Point your applications at its KISS endpoint
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| KISS endpoint
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Is its own networking environment; typically external TNC or KISS oriented
| Yes
| Reconfigure or Replace
| Configure its KISS endpoint and point your applications at it. Or just use it for everything if it already covers your use case.
|-
| [https://tracker.debian.org/pkg/aprsdigi aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| KISS endpoint
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze (or Revive)
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack, including <code>ax25d</code>
| Mostly no
| Freeze (or Revive)
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Replace
| No direct equivalent; consider refactoring your stack
|}

Some notes about reading the table:

* '''Yes''' means the software already works without depending on the removed code.
* '''Depends''' means “check the configured interface.” The software may work fine through KISS, AGWPE, serial, or TCP.
* '''No''' or '''Mostly no''' means the software category is tightly coupled to the old Linux stack and will not work with future kernels.

== Existing user-space projects worth studying first ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* Integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the 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
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that can use user-space TNCs
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose main interest is preserving classic packet workflows
|}

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

== 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
# if <code>kissattach</code> is part of the path, ask whether it is only being used to create an <code>ax</code> interface for software that could talk to KISS or AGWPE directly
# 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 might not be “How do we save everything?” but rather “What do people still need?”

Those may be very different things, and without clarity, it might be easy to spend effort rebuilding interfaces nobody still uses while diverting effort away from projects that people do still use.

=== 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, and people's heads. Current documentation is never unwelcome. Now could be a good time to capture that knowledge.

=== 4. Start from existing active projects ===

Starting from a maintained or recently active user-space project is likely to be more productive than preserving historical artifacts. That might mean extending an existing implementation, building missing protocol pieces, or writing compatibility layers like a TUN/TAP adapter for IP over AX.25.

== External resources ==

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

Category:Explanation

2026-04-30T18:53:02Z

KI5QKX: mw push

Pages whose primary goal is to help the reader understand a topic: background, concepts, tradeoffs, governance, or orientation.

[[Category:Documentation]]

AX.25 on Linux

2026-04-30T18:53:02Z

KI5QKX: mw push

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

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 <code>linux-netdev/mod-orphan</code> will host the removed code for those who want to inspect it or maintain it separately

== Who is likely to be affected ==

=== Probably affected ===

* Operators running older Linux packet-radio setups that depend on kernel AX.25 interfaces
* Users of older applications that assume AX.25 support is available through the Linux kernel network stack
* Maintainers of software that has never needed to implement its own AX.25 handling because Linux already provided it

=== Probably less affected ===

* Operators already using user-space TNCs or modem software like Dire Wolf
* Applications for things like APRS that already handle AX.25 internally and do not depend on Linux kernel interfaces
* People experimenting with newer software that does not depend on the old kernel path

== Not the end of AX.25 ==

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

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.

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

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

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

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.

=== “Freeze” ===

Keep an older kernel in service.

Use this when:

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

=== Reconfigure ===

Keep the same application, but change how it reaches the radio side.

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

Move to different software that already lives comfortably in the user-space model.

This is often the cleanest long-term answer for:

* new deployments
* APRS-focused stations
* stations whose existing software is effectively unmaintained

=== Revive ===

Carry the out-of-tree kernel code, help maintain it, or port missing behavior into a new user-space implementation.

This path makes sense mainly if:

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

== Compatibility snapshot ==

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.

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.

{| class="wikitable sortable"
! Software
! Current interface
! Works in the new world?
! Next step to consider
! Common migration target
|-
| [https://github.com/wb2osz/direwolf Dire Wolf]
| User-space AX.25; KISS over TCP/serial; AGWPE over TCP
| Yes
| Bridge or Replace
| Dire Wolf as the anchor itself, or paired with Pat / Xastir / aprx
|-
| [https://github.com/la5nta/pat Pat]
| AX.25 support with pluggable engines; AGWPE support; can use Dire Wolf directly over TCP
| Yes
| Reconfigure or Bridge
| Dire Wolf over AGWPE/TCP
|-
| [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html LinBPQ / BPQ32]
| Own packet stack and node/BBS environment; KISS, AXIP/UDP, AGW-style interfaces
| Yes
| Reconfigure or Replace
| LinBPQ itself, or Dire Wolf feeding LinBPQ via KISS
|-
| [https://www.xastir.org/index.php/XASTIR_Manual Xastir]
| Serial KISS, AGWPE, and optional Linux kernel AX.25 network ports
| Depends
| Reconfigure
| Dire Wolf or another KISS/AGWPE-capable software TNC
|-
| [https://thelifeofkenneth.com/aprx/ aprx]
| Serial KISS or kernel AX.25 interface
| Depends
| Reconfigure
| Dire Wolf or a hardware KISS TNC
|-
| [https://sourceforge.net/projects/yetanotheraprsc/ YAAC]
| User-space APRS client using external TNCs / serial interfaces
| Yes
| Reconfigure
| Existing external TNC, or Dire Wolf acting as one
|-
| [https://github.com/Xastir/SoundModem SoundModem]
| User-space modem/TNC; can expose KISS and other interfaces
| Yes
| Bridge or Replace
| Dire Wolf or SoundModem itself, depending on platform and feature needs
|-
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html QtSoundModem]
| User-space modem/TNC; KISS and AGWPE-style host-side interfaces
| Yes
| Bridge or Replace
| QtSoundModem or Dire Wolf as the software-TNC layer
|-
| [https://www.ka9q.net/papers/kiss.html KISS-oriented legacy applications generally]
| Usually external TNC, pseudo-tty KISS, or TCP KISS
| Depends
| Reconfigure or Replace
| Dire Wolf, QtSoundModem, or a hardware KISS TNC
|-
| [https://www.langelaar.net/projects/jnos2/ JNOS 2]
| Own networking environment; typically external TNC / KISS oriented rather than Linux kernel AX.25 sockets
| Yes
| Reconfigure or Replace
| JNOS itself with a KISS-capable modem/TNC
|-
| [https://tracker.debian.org/pkg/aprsdigi aprsdigi]
| APRS digipeater software; commonly used with KISS TNCs
| Yes
| Reconfigure
| Dire Wolf or a hardware KISS TNC
|-
| [https://packages.debian.org/sid/ax25-tools ax25-tools]
| Tools for configuring Linux AX.25 / NET/ROM / ROSE ports
| No
| Freeze or Revive
| None directly; replace the workflow with user-space TNC tooling or keep only in a legacy environment
|-
| [https://packages.debian.org/sid/ax25-apps ax25-apps]
| User applications for AX.25 / NET/ROM / ROSE over the Linux stack
| Mostly no
| Freeze or Revive
| Depends on the specific app; often LinBPQ, JNOS, Pat, or an APRS-specific tool
|-
| [https://manpages.debian.org/unstable/ax25-apps/ax25d.8.en.html ax25d]
| AX.25 connection dispatcher / daemon built around the Linux AX.25 stack
| No
| Freeze or Revive
| Usually not a direct one-for-one migration; often LinBPQ, JNOS, or an application-specific redesign
|-
| [https://www.systutorials.com/docs/linux/man/8-net2kiss/ net2kiss]
| Converts a kernel AX.25 network interface into a pseudo-tty KISS stream
| No
| Revive
| Replace the whole pattern with a native user-space KISS or AGWPE source
|}

Some notes about reading the table:

* '''Yes''' means the software already has a credible path that does not require the removed in-tree kernel stack.
* '''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 ==

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
* KISS or AGWPE host-side interfaces
* APRS, BBS, node, or messaging application layers
* integration with modern Linux networking through user-space boundaries

{| class="wikitable sortable"
! Project
! Project page / repo
! What it already covers
! Why it is worth inspecting
|-
| Dire Wolf
| [https://github.com/wb2osz/direwolf GitHub]
| Software TNC, AX.25, APRS-oriented tooling, KISS, AGWPE
| One of the clearest examples of a maintained user-space foundation that many other tools can sit on top of
|-
| Pat
| [https://github.com/la5nta/pat GitHub]
| Messaging client with AX.25 support and AGWPE integration
| Useful when the real goal is messaging workflow rather than rebuilding low-level plumbing
|-
| LinBPQ / BPQ32
| [https://www.cantab.net/users/john.wiseman/Documents/LinBPQBuild.html project page]
| Node, BBS, switch, packet stack, multiple radio/network interfaces
| Covers a broad slice of packet-radio infrastructure and may already solve the “legacy node/BBS” use case
|-
| Xastir SoundModem
| [https://github.com/Xastir/SoundModem GitHub]
| User-space modem/TNC functions for packet-radio host applications
| Worth studying as an existing open-source modem implementation rather than inventing one from scratch
|-
| QtSoundModem
| [https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html project page]
| User-space modem/TNC with KISS and AGWPE-style interfaces
| Another active example of the “software TNC in user space” approach
|-
| aprx
| [https://thelifeofkenneth.com/aprx/ project page]
| APRS iGate and digipeater software
| Useful for APRS-focused stations that do not need general-purpose kernel AX.25 networking
|-
| YAAC
| [https://sourceforge.net/projects/yetanotheraprsc/ project page]
| APRS client and related tooling
| Useful as an example of an application-layer approach that does not depend on the Linux AX.25 kernel stack
|-
| JNOS 2
| [https://www.langelaar.net/projects/jnos2/ project page]
| Packet-radio networking environment and applications
| Worth inspecting for people whose real interest is preserving classic packet workflows rather than Linux kernel semantics
|}

== If you already have an older setup ==

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:

* which kernel version it depends on
* which applications depend on kernel AX.25
* how the radio or TNC is connected
* whether the system is doing connected-mode AX.25, IP over AX.25, APRS, forwarding, or something else

That inventory makes every later decision easier.

=== Case 2: You need to keep old software working ===

If you depend on software that expects the old kernel interfaces, you may need an interim compatibility strategy rather than an immediate redesign.

Potential short- to medium-term options include:

* staying on an older kernel for that machine
* evaluating the out-of-tree kernel code now hosted in the <code>linux-netdev/mod-orphan</code> repository
* isolating the legacy workflow in a dedicated machine or virtual machine rather than tying it to your general-purpose Linux environment

This is not elegant, but it may be the most practical option if a working station depends on legacy interfaces and there is no ready user-space replacement for your exact use case.

If you choose this route, treat it as a containment strategy rather than a permanent default. A deliberately isolated older kernel can buy time, but it also accumulates security debt as new vulnerabilities are found and fixed only in newer supported lines.

=== Case 3: You are willing to modernize ===

If you are already making changes, it may be better to migrate toward a user-space model than to rebuild the same dependency on a shrinking kernel path.

That usually means asking:

* Do I actually need Linux to implement AX.25 in the kernel?
* Can my application talk to a user-space TNC or modem over KISS or AGWPE instead?
* Am I really using AX.25 networking, or just one narrow application that happens to sit on top of it?

In many cases, the cleanest long-term answer is to preserve the radio-side protocol in user space while simplifying everything around it.

== Architectural direction ==

For many people, the most practical direction is now a user-space one: software TNCs, external host-side interfaces such as KISS or AGWPE, and applications that do not assume Linux kernel AX.25 sockets are always present.

That does not solve every legacy use case automatically. But it does reduce dependence on upstream kernel decisions and makes it easier to compose working systems from smaller pieces.

== IP over AX.25 ==

If your goal is specifically IP over AX.25, the choices become narrower.

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

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

* AX.25 framing and control in user space
* integration to IP through TUN/TAP or similar interfaces
* narrower, more maintainable components rather than a large in-kernel subsystem

== If you are stuck with old software ==

Some people will be in the awkward middle: the software still matters, it expects the kernel interfaces, and there is no obvious one-command migration.

If that is you, the best immediate response is usually not “rewrite everything,” but:

# identify the exact interface your application expects
# determine whether that interface is kernel AX.25 specifically, or simply KISS / AGWPE / serial control
# check whether a user-space adapter, software TNC, or out-of-tree module can preserve the workflow
# decide whether the system should be frozen, migrated, or rebuilt

For some stations, a preserved older Linux environment may be the right answer for a while. For others, the better answer will be to retire the old application and move to a user-space stack.

== If you want to help advance AX.25 on Linux ==

If this change motivates you to improve the state of AX.25 rather than simply work around it, there are several useful starting points.

=== 1. Clarify the real use cases ===

The first question is not “How do we save everything?” but “What do people still need?”

Those may be very different things:

* APRS and monitoring
* connected-mode packet
* mailbox / BBS workflows
* IP over AX.25
* compatibility with specific TNCs or handheld radios
* Linux support for existing packet-radio applications

Without that clarity, it is easy to spend effort rebuilding interfaces nobody still uses while missing the ones that still matter.

=== 2. Prefer small boundaries ===

If you want to revive or modernize AX.25 support, it is worth favoring:

* small, testable user-space components
* clean interfaces between radio handling and host networking
* compatibility layers only where they are actually needed

=== 3. Preserve working knowledge before it disappears ===

A lot of Linux AX.25 knowledge lives in:

* old HOWTOs
* mailing-list posts
* working systems on shelves
* people’s heads

Now is a good time to capture:

* what still works
* what specific applications still matter
* which workflows require kernel compatibility
* which ones can already move to user space

=== 4. Start from existing active projects ===

Starting from a maintained or recently active user-space project is likely to be more productive than starting from nostalgia alone.

That may mean extending an existing implementation, building missing protocol pieces, or writing compatibility shims where they create the most leverage.

== Suggested attitude ==

This topic attracts strong opinions:

* nostalgia for the old Linux support
* frustration from people whose working systems are affected
* arguments about whether kernel support was ever the right design
* arguments that packet radio is too niche to matter

Those reactions are understandable, but they do not help much by themselves.

The more useful questions are:

* What still needs to work?
* What can move to user space today?
* What legacy interfaces are still worth preserving?
* What should be documented now so the next person does not have to rediscover everything from scratch?

== External resources ==

* [https://www.spinics.net/lists/netdev/msg1179014.html Jakub Kicinski’s April 20, 2026 patch proposing removal of the in-tree amateur-radio networking subsystem]
* [https://www.spinics.net/lists/netdev/msg1180117.html Stephen Hemminger’s April 24, 2026 iproute2 cleanup patch noting that AX.25, ROSE, and NET/ROM have been removed upstream]
* [https://lwn.net/Articles/1068928/ LWN coverage from April 22, 2026 summarizing the broader kernel code-removal effort]
* [https://www.spinics.net/lists/netdev/msg1179252.html Dan Cross on the likely user-space direction, including TUN/TAP for IP over AX.25]
* [https://github.com/linux-netdev/mod-orphan linux-netdev/mod-orphan], the out-of-tree repository where the removed code is being staged
* [https://github.com/wb2osz/direwolf Dire Wolf], a widely used user-space software TNC for AX.25 packet radio
* [https://github.com/la5nta/pat Pat], a current Winlink client with AX.25 support and AGWPE support
* [https://www.cantab.net/users/john.wiseman/Documents/BPQ32.html BPQ32 / LinBPQ documentation]
* [https://thelifeofkenneth.com/aprx/ aprx], APRS iGate and digipeater software for POSIX systems
* [https://sourceforge.net/projects/yetanotheraprsc/ YAAC], Yet Another APRS Client
* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Jeff Tranter’s Linux AX.25 HOWTO], useful mainly as historical background now

== Related pages ==

* [[Getting started with Linux and packet radio]]
* [[Setting up a gateway on Linux]]
* [[Gateway]]
* [[Routing]]
* [[MTU and MSS]]

[[Category:Explanation]]
[[Category:Reference]]
[[Category:Infrastructure]]

44Net Connect/Ways to Connect

2026-04-30T18:53:02Z

KI5QKX: mw push

= Ways to deploy 44Net Connect =

44Net Connect can be set up in a few different ways, depending on your use case. You will likely end up trying a mix of approaches as you experiment and learn what works best for your needs.

In the simplest case, each device you operate has its own tunnel and is assigned a single 44Net address. One device, one tunnel, one IP.

In another approach, one system terminates a single tunnel, but then distributes a block of addresses to devices on a local network behind it.

Each has tradeoffs: how you manage routing, how many systems you can support, how much configuration lives in one place. They also shape how traffic flows, and what kinds of problems you are likely to run into later.

== Model 1: One tunnel for each host ==

In this model, each host runs its own WireGuard client, establishes its own tunnel to a 44Net Connect endpoint, and is assigned a single IPv4 address (a /32).

From the host’s point of view, this is straightforward. The 44Net address is just another interface address, and services on that host are directly accessible from the Internet.

This works well when you have a small number of systems and each system can run WireGuard directly.

Common use cases include:
* a single server exposed to the Internet
* a laptop or workstation that needs a stable public address
* small, independent services running on just a few separate machines

The main tradeoff is that it can become cumbersome to manage as you add more hosts. Each one needs its own tunnel configuration, and you have to keep track of which address belongs to which host. There is also no central point of control for routing or filtering, so each host is responsible for its own security and traffic management. Eventually, you will reach the limit of how many tunnels you can create and manage.

== Model 2: Gateway for a local network, subnet behind a tunnel ==

In this model, a single system terminates the WireGuard tunnel and acts as a gateway for a group of hosts on a local network. A block of 44Net addresses is assigned to you in the Connect dashboard and routed to your gateway. The gateway then routes traffic between the tunnel and the local network, allowing multiple hosts to share the same tunnel connection.

The advantage here is that the gateway handles all the complexity. Other hosts need not run WireGuard themselves, and they can be assigned addresses from the 44Net block without needing to manage individual tunnels. The gateway can also handle routing and firewalling.

From the perspective of those hosts, the gateway behaves like a router that provides access to the 44Net address space.

This model is useful when:
* you want to serve multiple hosts without configuring each one individually
* some devices cannot run WireGuard directly
* you want a single point of control for routing and filtering

Common use cases include:
* a home lab with several servers
* embedded devices or radios that cannot run a tunnel client
* a small network where services are distributed across multiple hosts

The main tradeoff is some additional complexity in setting up and managing the gateway. Some people find this model somewhat unintuitive. You will need to configure real routing and firewall rules. Troubleshooting can be more complex. The gateway becomes a single point of failure; if the gateway goes down, all hosts lose connectivity. You also need to ensure that the gateway is well secured, to protect the hosts behind it. So the advantages do not come wthout some challenges.

== Model comparison ==

{| class="wikitable"
! !! Model 1: Per-host tunnels !! Model 2: Gateway and subnet
|-
| '''Configuration''' || Distributed across hosts || Centralized on gateway
|-
| '''Number of tunnels''' || One per host || One per network
|-
| '''Scaling''' || Limited by per-host setup || Scales to many hosts
|-
| '''Failure radius''' || Affects one host || Affects entire network
|-
| '''Security domain''' || Per-host || Centralized
|}

== Traffic behavior ==

Traffic patterns differ in subtle but important ways.

In the per-host model:
* each host decides how its traffic is routed
* split-tunnel configurations are common, where only 44Net-sourced traffic uses the tunnel

In the gateway model:
* routing decisions are made at the gateway
* hosts behind the gateway typically rely on it for both outbound and inbound 44Net traffic

In some applications, it is important that all traffic associated with a service appear to come from the same public address. In those cases, a full-tunnel configuration or a gateway model may be more appropriate than per-host split tunneling.

== Choosing a model ==

As a starting point:

* Use per-host tunnels if you are working with one or a few systems and want the simplest setup.
* Use a gateway if you need to support multiple hosts or devices that cannot run WireGuard themselves.

You can also mix the two. Some systems can run their own tunnels, while others use a gateway. The choice depends on how you want to manage configuration, routing, and exposure.

If you are unsure, start with a per-host tunnel. It is easier to reason about, and you can move to a gateway model later as your setup grows.

== Further reading ==

* [https://ardc.groups.io/g/44Net-connect/topic/118968724#msg645 Phil Karn KA9Q and others discussing 44Net Connect deployment models on the ARDC groups.io list]
* [https://www.wireguard.com/quickstart/ WireGuard Quick Start] for the underlying tunnel model used by 44Net Connect
* [https://www.wireguard.com/#conceptual-overview WireGuard conceptual overview] for a concise explanation of peers, routing, and interface behavior

[[Category:Explanation]]
[[Category:Participation Methods]]
[[Category:44Net Connect]]

Setting up a gateway in a ROS7 Mikrotik router container on arm32, arm64 and x86-64

2026-04-30T18:53:02Z

KI5QKX: mw push

#REDIRECT [[Setting up a gateway in a ROS7 Mikrotik router container on arm32 arm64 and x86-64]]
[[Category:How-To]]
[[Category:Infrastructure]]
[[Category:Gateways]]

Setting up a gateway in a ROS7 Mikrotik router container on arm32 arm64 and x86-64

2026-04-30T18:53:01Z

KI5QKX: mw push

Setting up a gateway in a ROS7 Mikrotik router running in a container on arm and arm64 models and x86-64 CHR

'''This is an experimental software build for the 'enthusiasts' out there.'''

Source code is available in git.ampr.org: https://git.ampr.org/yo2loj/ampr-ros7-container/-/tree/main

<h1>Info</h1>

These are the steps for setting up a fully functional AMPR gateway on an arm/arm64 MikroTik router
Tested and found working on CRS2116 and RB3011 for now.

MikroTik ARM64 devices:
Routers: CCR2004, CCR2116, CCR2216, RB5009
Switches: CRS520
Wireless and 5G: Netmetal ax, LHG-LTE6, ATL-LTE18
SOHO: hAP-ax2, cAP-ax, hAP-ax3, Chateau-ax
Others: AMPERE

MikroTik ARM32 devices:
Routers: L009, RB3011, RB4011, RB1100AHx4,
Switches: CRS305, CRS309, CRS310, CRS317, CRS320, CRS326, CRS328
Wireless and 5G: SXTsq-5ac, NetBox-5ax, LHGXL-5ac
SOHO: hAP-ax lite, hap-ac2, cAP-ac, wAP-ac, cAPXL-ac, hAP-ac3, Chateau
Routerboard: L11UG, L23UGSR, RB450Gx4

MikroTik x86-64 devices:
Others: Cloud Hosted Router

Containers are not available on MIPSBE, MMIPS, SMIPS, TILE or PPC architectures.

== General concept ==
Mikrotik routers running ROS 7 (7.15.3 being current at the time of writing) based on arm and arm64 processor, as well as CHR setups are able to run software containers (similar to docker).
This opens the possibility to host a virtualized gateway in such a container, allowing a simple and efficient setup on modern systems.

The gateway will be hosted in a VRF on the router, providing gateway services using policy routing.

As a concept, the container has a single VETH interface which will decapsulate all incoming IPIP traffic from the tunnels, and encapsulate all outgoing traffic towards them.
The container itself is isolated behind a bridge and offers some basic filtering function (e.g. restrict access from internet hosts).
It will receive the RIPv2 broadcasts from the AMPR gateway and provide the obtained routes as RIP broadcasts to the router itself inside the mentioned VRF.

The container does not save anything to disk (which would be a bad idea on the router's flash memory), so the AMPR routes are lost on container or router restart, and you need to wait the now classical 5 minutes. But this should be no problem on a 24/7 on router.

== Limitations ==

The router does not forward multicast frames at all, nor does it send out broadcasts.
Incoming broadcasts are accepted and forwarded to the local VRF.

The container itself needs to sit behind a bridge due to a kernel bug in the version used by Mikrotik which sends out "Port unreachable" ICMP messages on incoming IPIP traffic if it is handled in user space (The same thing causing the need of a kernel filter in amprd. This is fixed in newer kernel releases but it will take a while for it to make its way into ROS). Bridge filtering is used to mask those messages.

<h1>New router 5 minutes set up</h1>

As a prerequisite, get your internet connection working based on the default mikrotik configuration.
Basically set up your ISP uplink either via DHCP or by setting up a PPPoE or similar connection.
Leave the default firewall rule as they are.
Alternatively, you can start with a completely empty router, with only a active internet connection.

First you need to enable container support according to the info provided by Mikrotik.
In a console type in:
/system/device-mode/update container=yes
The system will want you to do a hard reset at this point to confirm the request. This means you need physical access to the device.

Next, you need to install the container package for your firmware version. Download the "extra" firmware package from MikroTik for your FW version and extract the "container-7.x.y-<arch>.npk" file. Upload it to your router and restart. This will install the package onto the router. After restart, you will have a new option available: /containers

== Installation script ==
Next we need to install the container according to your hardware.
Please chose the correct setup script variant:

ARM32 - ampr_arm32.rsc
ARM64 - ampr_arm64.rsc
CHRx86 - ampr_x86_64.rsc

Unfortunately, containers are not available on Mips, Tile or PowerPC devices.

The example assumes you use an arm32 device. Please use the proper one...

Open a route console window.

1. Check is the remote server is available:
[admin@MikroTik] > ping yo2loj.ro
SEQ HOST SIZE TTL TIME STATUS
0 89.33.44.100 56 58 10ms574us
1 89.33.44.100 56 58 9ms141us
2 89.33.44.100 56 58 9ms5us
sent=3 received=3 packet-loss=0% min-rtt=9ms5us avg-rtt=9ms573us max-rtt=10ms574us

2. Download the configuration script
[admin@MikroTik] > /tool fetch url="http://yo2loj.ro/containers/ampr_arm32.rsc"
status: finished
downloaded: 5KiB
total: 5KiB
duration: 1s

3. Run the configuration script
[admin@MikroTik] > import ampr_arm32.rsc
AMPR: Creating bridge and VRF
AMPR: Setting up RIP
AMPR: Creating container envs
AMPR: Setting up firewall rules
AMPR: Creating container update script
AMPR: Creating routing rules
AMPR: Installing container
No container is installed
status: finished
downloaded: 366KiB
total: 366KiB
duration: 1s
AMPR: Script finished successful
AMPR: Now update your container envs and start the container

Your container is now installed.
You need to configure its environment variables according to the description given below.

After configuration is complete, go to "containers" and star it up.
It should show "running" and you should see it's messages in the log window.

After at most 5 minutes, you should get the tunnel routes in your vrf, and your gateway should be fully up and running.

If logging/debugging is not needed anymore, please disable it by clicking on the container and unchecking te logging box.

== Container configuration parameters ==
You need to adapt the pre-existing container environment variables to your particular gateway before starting it again.
The following ENV parameters are preset in Container-> Envs:
AMPR_SUBNETS - holds your local subnets as defined in the Portal, as comma separated list of <SUBNET>/<MASK> tupples, e.g. "44.128.0.0/24,44.128.1.0/24"
ALL_VIA_AMPRGW - enables forwarding of all AMPR destinations via AMPRGW, values are "0" or "1"
FORWARD_INTERNET - enables forward of traffic from/to internet hosts, values are "0" or "1"
IGNORED_SUBNETS - allows you to ignore specific subnets provided by RIP, by <SUBNET>/<MASK> or gateway address e.g. "44.128.0.0/16"
CALL_HOME - the classic string, <CALLSIGN>@<LOCATOR> to show up on the map. You will get a yellow dot. e.g. "YO2LOJ@KN05OR". Leaving the field empty disables call home.

Please note that the provided default will allow you to play around, but will not provide a working set up.

Next, you need to set up a local AMPR LAN on your router router, or, if you have only a single IP address assigned, add it to one of your router's interfaces with a /32 netmask
Anyway, you need to add a src-nat rule to the router's IP address to get your traffic flowing (let's assume its 44.128.0.1).
The address shall be set on an interface OUTSIDE OF THE VRF.

For a single address:
/ip address add address=44.128.0.1 interface=bridge
or even on the loopback interface:
For a single address:
/ip address add address=44.128.0.1 interface=lo

For a subnet:
/ip address add address=44.128.0.1/24 interface=<interface name>

And your src-nat NAT rules:
/ip firewall nat add action=src-nat chain=srcnat out-interface=bridge-ampr-gw to-addresses=44.128.0.1
/ip firewall nat add action=src-nat chain=srcnat out-interface=vrf-ampr to-addresses=44.128.0.1

Of course you need to set up additional firewall rules and stuff, but if you do not enable internet forwarding, you should be pretty safe being exposed only to AMPR partners.

Please note that for your firewall rules the incoming interface from the tunnels is "vrf_ampr" and the outgoing interface is "bridge-ampr-gw" for forwarded and "vrf-ampr" for local outgoing data.

== Additional optional configuration ==

You may notice that on an external traceroute your router's IP address will show up as 172.17.0.1.
To fix this small glitch, you need to modify your existing "rip-ampr-in" RIP input filter rule to provide the correct preferred source address.

Modify the existing rule from
accept;

to set your router's local AMPR IP as its preferred source
set pref-src 44.128.0.1;
accept;

Also, if you want to access the AMPR network from a LAN not using AMPR addresses, you need to set up a forwarding rule and a SRC-NAT one:

/ip firewall filter
add action=accept chain=forward comment="from LAN" in-interface=<YourLANInterface> dst-address-list=ampr_addr
and
/ip firewall nat
add action=src-nat chain=srcnat comment="NAT to AMPR" dst-address-list=Ampr out-interface=bridge-ampr-gw \
src-address-list=!ampr_addr to-addresses=44.128.0.1

<h1>Configuration on an existing working router - 6 steps</h1>

1 - Bridge, VETH, VRF and interface setup
2 - RIP setup
3 - Firewall rules, Filter, NAT and Mangle
4 - Container environment setup
5 - Container installation (architecture dependent)
6 - Container configuration and final touches

== Preliminary: prepare the router to accept containers ==
First, you need to install container support on your router.
In a console issue:
/system/device-mode/update container=yes
The system will want you to do a hard reset at this point to confirm the request.
This means you need physical access to the device.

Next, you need to install the container package for your firmware version.
Download the "extra" firmware package from MikroTik for your FW version and extract the "container-7.x.y-<arch>.npk" file.
Upload it to your router and restart. This will install the package onto the router.
After restart, you will have a new option available: /containers

== Step 1: Bridge, VETH, VRF and interface setup ==

First create a bridge which will be used for your containr. Let's call it 'bridge-ampr-gw':
/interface bridge add comment="AMPR container" name=bridge-ampr-gw
Assign a network to it. The typical docker IP will be ok:
/ip address add address=172.17.0.1/24 interface=bridge-ampr-gw
Create a virtual ethernet interface for the container itself (call it veth-ampr):
/interface veth add name=veth-ampr address=172.17.0.2/24 comment="AMPR container interface" \
gateway=172.17.0.1
Add the VETH port to the bridge we created above:
/interface bridge port add bridge=bridge-ampr-gw interface=veth-ampr
Because of a kernel anomaly preventing proper userspace IPIP handling, we need to filter icmp messages on the bridge from the container itself:
/interface bridge filter add action=drop chain=input in-interface=veth-ampr ip-protocol=icmp \
mac-protocol=ip src-address=172.17.0.2/32
Now we create a vrf called "vrf-ampr" and add the bridge to it:
/ip vrf add interfaces=bridge-ampr-gw name=vrf-ampr

All the above steps are available here as a rsc file: http://yo2loj.ro/containers/1_ampr_bridge_vrf.rsc

== Step 2: RIP setup ==

First, create a simple accept routing filter to be used by RIP:
/routing filter rule add chain=rip-ampr-in disabled=no rule="accept;"
Next, create a RIP instance for your VRF using the above filter and the defined VRF:
/routing rip instance add afi=ipv4 in-filter-chain=rip-ampr-in name=rip-ampr vrf=vrf-ampr
And now add a passive (receive only) interface to our instance:
/routing rip interface-template add instance=rip-ampr interfaces=bridge-ampr-gw mode=passive

All the above steps are available here as a rsc file: http://yo2loj.ro/containers/2_rip.rsc

== Step 3: Firewall rules, filter, NAT and mangle ==

Now we need to forward out IPIP tunnels to the container, and extract our data from the VRF.
For our convenience we will set up an address list to handle AMPR space as one entity
(if you already have such a list on the router, you can use it)
/ip firewall address-list
add address=44.0.0.0/9 list=ampr_addr
add address=44.128.0.0/10 list=ampr_addr
Also, we can use an interface list called WAN for the internet access interfaces (like the one in the default config).
If you prefer individual interfaces, you can of course use them in your rules.

Filters are needed to allow data input and forward to/from the router.
Accept RIP from the VRF:
/ip firewall filter
add action=accept chain=input comment="RIP via VRF" dst-port=520 in-interface=vrf-ampr protocol=udp
Accept input from the AMPR address space to the router (important for ping and traceroute):
/ip firewall filter
add action=accept chain=input comment="AMPR via Tunnels" dst-address-list=ampr_addr in-interface=vrf-ampr \
src-address-list=ampr_addr
And we need to accept some forwarding for the IPIP tunnels, from VRF to our AMPR space and between AMPR hosts:
/ip firewall filter
add action=accept chain=forward comment="IPIP Tunnels from ISP" in-interface-list=Internet protocol=ipencap
add action=accept chain=forward comment="IPIP Tunnels from VRF" in-interface=vrf-ampr protocol=ipencap
add action=accept chain=forward comment="VRF to AMPR" dst-address-list=ampr_addr in-interface=vrf-ampr
add action=accept chain=forward comment="AMPR to AMPR" dst-address-list=ampr_addr src-address-list=ampr_addr

Next, we need to forward incoming IPIP traffic to our container (note that WAN interface list, use your interface if you like):
/ip firewall nat
add action=dst-nat chain=dstnat comment="NAT ENCAP" in-interface-list=WAN protocol=ipencap \
to-addresses=172.17.0.2

Now to be able to traverse int and from the VRF, we need some mangle rules.

Incoming IPIP traffic will be marked with the vrf routing mark:
/ip firewall mangle
add action=mark-routing chain=prerouting comment="AMPR IPIP incoming to VRF" in-interface-list=Internet \
new-routing-mark=vrf-ampr passthrough=no protocol=ipencap
Outgoing IPIP traffic will be marked for the main routing table (or the one you need to reach your ISP)
/ip firewall mangle
add action=mark-routing chain=prerouting comment="AMPR IPIP outgoing via ISP" in-interface=vrf-ampr \
new-routing-mark=main passthrough=no protocol=ipencap
Traffic to our local router IPs will be directed via our bridge
/ip firewall mangle
add action=route chain=prerouting comment="AMPR VRF route local" dst-address-type=local in-interface=vrf-ampr \
passthrough=no route-dst=172.17.0.1
And finally, the incoming AMPR traffic will go to the main routing table
/ip firewall mangle
add action=mark-routing chain=prerouting comment="AMPR VRF forward" in-interface=vrf-ampr new-routing-mark=main\
passthrough=no

All the above steps are available here as a rsc file: http://yo2loj.ro/containers/3_firewall.rsc

== Step 4 - Container environment setup ==
This step prepares the environment variables for the container.

/container envs
add comment="My subnets, as defined in the Portal" key=AMPR_SUBNETS name=ampr-cfg value=\
44.128.0.0/24,44.128.1.0/24
add comment="Default gateway is AMPRGW instead of Internet" key=ALL_VIA_AMPRGW name=ampr-cfg value=0
add comment="Forward internet traffic" key=FORWARD_INTERNET name=ampr-cfg value=0
add comment="Call home callsign and locator" key=CALL_HOME name=ampr-cfg value=test@AA00aa
add comment="Ignored subnets in RIP" key=IGNORED_SUBNETS name=ampr-cfg value=44.128.0.0/16

Just paste them into the console or import the rsc script as it is. You will edit those later.

The rsc file is here: http://yo2loj.ro/containers/4_container_env.rsc

== Step 5 - Container installation ==
Now you need to download the container which fits your architecture.
The following rsc files will install a script which, when run will import and install the container.
The same scripts will update and replace the container if run again.

ARM32 - http://yo2loj.ro/containers/5_container_arm32.rsc
ARM64 - http://yo2loj.ro/containers/5_container_arm64.rsc
CHRx86 - http://yo2loj.ro/containers/5_container_x86_64.rsc

Of course, instead of the script, you can download the appropriate tar container files yourself:
ARM32 - http://yo2loj.ro/containers/ampr-arm32.tar
ARM64 - http://yo2loj.ro/containers/ampr-arm64.tar
CHRx86 - http://yo2loj.ro/containers/ampr-x86-64.tar
and install them manually. Please set them to use the env variables "ampr-cfg".

Or, you can compile and pack the container yourself from source. At the time of writing, the current version is 1.2.0:
http://yo2loj.ro/containers/ampr-container-1.2.0-release.tgz

== Step 6 - Container configuration and final touches ==

You need to edit your env variables according to the description given in the new router setup.

Start your container and wait 5 min. You should see AMPR routes showing up in the VRF's routing table
(Some 840 of them if ALL_VIA_AMPRGW is not enabled, otherwise you will get only 2 routes, 44.0.0.0/9 and 44.128.0.0/10).

You may notice that on an external traceroute your router's IP address will show up as 172.17.0.1.
To fix this small glitch, you need to modify your existing "rip-ampr-in" RIP input filter rule to provide the correct preferred source address.

Modify the existing rule from
accept;

to set your router's local AMPR IP as its preferred source
set pref-src 44.128.0.1;
accept;

Now, activate the use of the whole system.
Set up a routing rule set to force all outgoing AMPR traffic to do a lookup in the VRF routing table:
/routing rule
add action=lookup disabled=yes dst-address=44.0.0.0/9 table=vrf-ampr
add action=lookup disabled=yes dst-address=44.128.0.0/10 table=vrf-ampr
If no route is found in that table, the lookup will continue via the main table towards your default route.

Your local AMPR network and additional routing will go into the main table and the lookup will be done AFTER passing through the VRF's routing table.
This means that a matching route in the VRF, including a default 0.0.0.0/0 will take precedence over any route defined in the main table.

Also, if you want to access the AMPR network from a LAN not using AMPR addresses, you need to set up a forwarding rule and a SRC-NAT one:

/ip firewall filter
add action=accept chain=forward comment="from LAN" in-interface=LAN dst-address-list=ampr_addr
and
/ip firewall nat
add action=src-nat chain=srcnat comment="NAT to AMPR" dst-address-list=Ampr out-interface=bridge-ampr-gw \
src-address-list=!ampr_addr to-addresses=<your router's AMPR ip>

== Additional info ==
All available files are here: http://yo2loj.ro/containers/

Rip Rip Hurray! de YO2LOJ

[[Category:How-To]]
[[Category:How-To Guides]]
[[Category:Infrastructure]]
[[Category:Gateways]]

Services/Historic

2026-04-30T18:53:01Z

KI5QKX: mw push

Below is a list of historic services that were previously offered by ampr users but are not currently available.

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| N1URO ||Network Tools|| http://n1uro.ampr.org/do.shtml || HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| DNS entry no longer exists
|-
| Various Operators ||Network Time Protocol Server || ns.ardc.net (Stratum 2, UK) server.yo2loj.ampr.org (Stratum 2) f4gve.ampr.org (Stratum 3) ntp1.on3rvh.ampr.org || NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| No NTP server configured on host
|-
| OH7LZB ||[[AMPRNet_VPN]] || http://wiki.ampr.org/wiki/AMPRNet_VPN || VPN|| [http://en.wikipedia.org/wiki/OpenVPN OpenVPN]-based || '''Unavailable as of May 2024''' You must have a X.509 certificate issued by [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]. ARRL membership is not required.
|-}

[[Category:Reference]]
[[Category:Infrastructure]]
[[Category:Core Services]]

DNS

2026-04-30T18:53:01Z

KI5QKX: mw push

{{DISPLAYTITLE:44Net DNS}}
The 44Net DNS service provides name resolution and delegation for 44Net users. Most participants use it to publish hostnames for their systems, starting with a callsign-based subdomain and adding records as needed.

A typical DNS path on 44Net:
# Claim a callsign-based subdomain under ampr.org.
# Create DNS records that map hostnames to IP addresses.

This is sufficient for publishing things like web servers, gateways, remote stations, and repeaters.

* [[DNS/Portal/Subdomains|Claiming a Subdomain]]
* [[DNS/Portal/Records|Managing Records]]

== Running your own DNS ==

Some participants run their own DNS servers rather than relying only on the Portal.

In this approach, control of a domain is delegated to local systems, while remaining part of the ampr.org domain.

This supports automation, custom workflows, and closer integration with locally managed services.

* [[DNS/Portal/Delegations|Delegating DNS to an Independent Name Server]]
* [[DNS/Setup/OpenBSD_Resolver|Setting up a Recursive Resolver on OpenBSD]]

== Understanding DNS ==

For background on how DNS works (with 44Net use in mind):

* [[DNS/Overview|DNS Overview and Concepts]]

== Older docs and notes ==
Earlier pages that may still be useful:
* [[Verification]]
* See [[Archive]] for more.
[[Category:Explanation]]
[[Category:DNS]]

Setting up a gateway on Linux

2026-04-30T18:53:00Z

KI5QKX: mw push

There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.

Before configuring the Linux gateway you'll need to:
# Using the [[Portal]], request an IP address (or addresses) by clicking on "Request address space" then selecting "IPIP Tunnel Mesh" as the Use Case.
# You will need to have a public static IP address for your gateway.
# Using the [[Portal]], create an entry for your gateway.
# Get some of your AMPRNet IP addresses registered in the [[ampr.org]] DNS.

= Flavours of Linux gateways =

== Native Linux kernel AX.25 and IPIP tunneling ==

Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.

Setting up a native Linux gateway consists of two main steps:

=== Step 1: Setting up tunnel routing to the rest of the AMPRnet===
Configuring your Linux system to learn about other AMPRNet [[gateway| gateways]] can be done two ways:

# Automatically learn about other gateways via modified RIPv2 advertisements. Two popular programs to do this are:
## Using [[ampr-ripd]], a C based routing daemon
## Using [[rip44d]], a PERL based routing daemon
# Downloading an [[encap.txt]] file and setting up routes using a [[munge script]] is the traditional method

==== Example gateway configuration instructions ====
* [[Ubuntu Linux Gateway Example]]
* [http://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html Two Interface Debian Linux Amprnet Gateway Example]
* [https://k7ilo.blogspot.com/p/server-setup.html K7ILO'S Two Interface Debian 11 AmprNet Gateway Build in layman's terms]

=== Step 2: Setting up radio interfaces in Linux===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Linux AX.25 set-up]
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links.

== Running JNOS (or other NOS) on top of Linux ==

If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.

The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.

The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.

=See also=

* [[Ubuntu Linux Gateway Example]]
* [[startampr]]

[[Category:How-To]]
[[Category:How-To Guides]]
[[Category:Infrastructure]]
[[Category:Gateways]]

Portal intro

2026-04-30T18:53:00Z

KI5QKX: mw push

= ARDC Portal 2.0 Technical Documentation =

By Rebecca Key KO4KVG

Version: 4 (October 22, 2024)

== Accessing the Portal ==

Go to [https://portal.ampr.org/home https://portal.ampr.org], where you should see the following UI:

[[File:Portal-homepage-login-v4.png|750px]]

== Registration ==

# Click on the 'Register' button at the top right of the UI (see 'Accessing the Portal', step 1) or on the 'Register' button in the 'LOGIN' dialog box. This will take you to the following screen: [[File:Registration-step-1-of-3-v4.png|750px]]
# Complete the field for 'What should we call you?:' and click 'Continue'.
# In the dialog box titled 'Registration (Step 2/3)', you will be introduced to help icons ('?') that will provide you useful information throughout the Portal. Click 'Close' to exit the dialog box. [[File:Registration-step-2-of-3-popup-box-v4.png|740px]] From there, you enter your Given name, Family name, email address, a username (used to login) and a password, then click 'Continue'. [[File:Registration-step-2-of-3-v4.png|750px]]
# You should then arrive at a dialog box titled 'Registration (Step 3/3)' that displays the End User License Agreement (EULA). Read through the EULA, and if you agree to the terms and conditions, tick both 'I AM 18 YEARS OF AGE OR OLDER', and 'I accept and agree to the terms of this End User License Agreement', and then click 'I Accept'. Note that if you are under the age of 18, and/or if you do not agree with the Terms of Use, then you will not be able to use the Portal. [[File:Registration-step-3-of-3-v4.png|750px]]
## Note: When you log back in on a later date, you might get a notice about the addition and/or updates to the EULA. For example, if you see a dialog box titled 'The EULA has been updated', verify that you are 18 or older, and if you would like to continue using the Portal, accept the updated EULA.
# Upon accepting the Terms of Use, you should get a message (see below) informing you that the system is sending you an email verification with further instructions. Follow the instructions in this email. [[File:Verify-email-v4.png|750px]]
# Once you complete the instructions in the email, you should get a page that looks like the one below, which will have an alert entitled 'You successfully verified your email'. Fill in the information in the 'LOGIN' dialog box and click 'Login'. [[File:email-verified-v3.png|750px]]
# From there, you will be prompted to click 'Continue Registration'. [[File:Continue-registration-v4.png|750px]]
# Once you click 'Continue Registration', you will be brought to a page where you will be asked to complete registration. [[File:Complete-registration-form-v4.png|750px]]
# Confirm that the required information is correct; add any optional information you prefer to share; read and agree to the 'Terms and Conditions', and click the 'Continue' button. You should then see a page that shows 'Registration Complete', which includes a note to verify your call sign as the next step. [[File:Registration-complete-v4.png|750px]]
# To add and verify your call sign, go to the 'Account' dropdown menu and select 'Call signs'. You should see the 'Your call signs' dialog box. [[File:Your-call-signs-v4.png|750px]] Click 'Add a call sign', where you will see a form to add your call sign. Enter your call sign in the input field and click 'Add'. [[File:Add-a-call-sign-v4.png|750px]] You should then see a message stating 'The new call sign was successfully added'. [[File:Call-sign-successfully-added-v4.png|750px]] Clicking the 'Make Primary' button will make a desired call sign the primary call sign on the account, and you can delete a call sign from your account by simply clicking the 'Delete' button.
## If you did not add your maidenhead to your profile, you will get a message at the top of the page stating: [[File:Add-maidenhead-error-prompt-v4.png]] above the 'Update your profile' form. [[File:Update-your-profile-maidenhead-v4.png|750px]] Add your maidenhead, confirm your password, and click 'Save'.
## You will then see the following message above the 'Update your profile' form: [[File:profile-updated-ok-message-v4.png|500px]]
## Go back to Step 10, where you'll be prompted to add your call sign. 
# On the 'Your call signs' UI, click 'Verify'. This will take you to a screen that details the process of verification. [[File:Verify-call-sign-prompt-2-v4.png|750px]]
# Click on the green 'Verify' button: you should see an alert saying 'Your request to verify your callsign [$call sign] has been submitted', which will create a ticket for the Portal admins to verify your call sign. [[File:Callsign-is-verified-v4.png|750px]] You can check the ticket by going to the 'Tickets' dropdown menu, selecting 'View my tickets', where you see it listed. To see the details of the ticket, click 'View'. [[File:View-ticket-request-details-v4.png|500px]]
## Note that once your call sign has been verified, you will no longer see the ticket in the list. Alternatively, you can confirm that your call sign has been verified by going to 'Account' > 'Call signs', and the status of your call sign verification will be displayed in the 'Your call signs' dialog box. Once your call sign has been verified, you will be able to request address space. [[File:Verified-call-sign-v4.png|750px]]

== Requesting address space (beginner friendly steps) ==

This series of steps is aimed at users who are either new to requesting 44Net address space, need a refresher, or would like to streamline the process. Otherwise, you can also request address space via the Network list in the 'Requesting Address Space (via Network List)' and 'Requesting Address Space for BGP Use (via Network List)' sections below.

# Under the 'Networks' menu, select 'Request addresses'. Note that you can also request address space on the Dashboard by clicking 'Request address space'. [[File:request-address-space-dashboard-v4.png|750px]]
# You should see a dialog box entitled 'Request Address Space'. Select your address type (should be IPv4, as IPv6 is not currently available), use case, and click 'Continue'. Please see the below instructions for your particular use case. [[File:Request-address-space-form-v3.png|750px]]

=== Use case: IPIP tunnel mesh, radio, globally unique space, or general address assignment ===

# If you selected IPIP tunnel mesh, radio, globally unique space, or general address assignment as your use case, you will see a dialog box entitled 'Request IP Assignment'. Fill out the 'Request IP Assignment' dialog box with the required information; agree to the EULA; and click 'Continue'. [[File:Request-ip-assignment-v4.png|750px]]
# You will then see the following note thanking you for requesting address space from ARDC, which includes detailed information about next steps. [[File:Ty-for-requesting-address-space-v4.png|750px]]
# Once your address space has been assigned, you can proceed to step 6 under 'Requesting Address Space (via Network List)'.

=== Use case: BGP direct announce ===

#If you selected 'BGP Direct Announce' as your use case, you will see a dialog box entitled 'Request IP Assignment'. Fill out the 'Request IP Assignment' dialog box with the required information, agree to the EULA, and click 'Continue'. [[File:Request-ip-assignment-for-bgp-v4.png|750px]]
# Proceed to step 3 under 'Requesting Address Space for BGP Use (via Network List)'.

=== Other use cases ===

Selecting any of the below use cases will give you a dialog box that provides more details about the network:
* AREDN
* HAMNET
* HamWAN

== Requesting address space (via network list) ==

# Under the 'Networks' menu, select 'All IPv4 Networks'.
# In the 'List IPv4 Networks' dialog box, click the + sign to expand a line, or use the 'Expand All' button. [[File:List-ipv4-networks-v4.png|500px]]
# Scroll to look for the address space you are looking for (e.g., 44.63.0.0/16 - IPIP Mesh Assignments) and click on the green clipboard icon to the right of the assignment to request an assignment. [[File:Request-network-assignment-v4.png|750px]]
# Fill out the 'Request IP Assignment' dialog box with the required information, and click 'Continue'. [[File:Request-ip-assignment-v4-via-network-list.png|750px]] You will see the dialog box titled 'Thank you for requesting address space from ARDC' (see step 2 under 'Use Case: IPIP Tunnel Mesh, Radio, Globally Unique Space, or General Address Assignment'), which includes detailed information about next steps.
# To confirm that your address space has been successfully requested, you can go to 'Tickets' > 'View my tickets' to see if the request is in your ticket list. Note that you may be asked to provide more information to the Ticket Handler about your request before your address space is assigned. [[File:Confirm-address-request-in-tickets-v4.png|750px]] [[File:Justification-for-address-space-v4.png|750px]]
# Once your space has been assigned (and the associated ticket has been closed), you can view your IPv4 networks by going to 'Networks' > 'my IPv4 networks', where your network detail(s) will be provided. [[File:Network-detail-of-requested-address-space-v4.png|750px]]

== Adding DNS records to a subdomain ==

# On the 'DNS' dropdown menu, select 'My subdomains' and then click 'Request a subdomain' in the 'My subdomains' dialog box. [[File:my-subdomain-dialog-box.png|750px]]
# Choose your domain, determine a name for your subdomain (i.e., most likely your call sign), click 'Create request', and you should see a note [[File:Create-new-subdomain-request-v4.png|750px]] saying 'Subdomain $[call sign].ampr.org has been assigned to you'. [[File:Subdomain-has-been-assigned-to-you-v4.png|750px]] Please be aware that if your call sign has not been verified or if you are requesting a domain other than $[call sign].ampr.org, a ticket will be opened for an administrator to review your request(s). You can verify that your subdomain has been created by going to 'DNS' > 'My subdomains', and your subdomain should appear in the 'My subdomains' dialog box. [[File:Subdomain-creation-verification-v4.png|750px]]
# Once your subdomain has been created, you can add DNS records by going to 'DNS' > 'My subdomains', and click the icon under 'Actions' in the 'Subdomains' dialog box (see step 2 above).
# In the 'Resource records for $subdomain.ampr.org', click 'Add a resource record'. [[File:add-resource-record.png|750px]]
# In the 'Create resource record for $subdomain.ampr.org', select the record type, and click 'Next' (see below). [[File:create-resource-record-step-1.png|750px]]
# Add the details relevant to the record type and ensure that Active is checked, click 'Create', [[File:Create-resource-record-step-2-v4.png|750px]] and you should get an alert that says 'Subdomain Record created successfully'. [[File:Subdomain-record-created-successfully-v4.png|750px]]
# You can verify that your record has been created by going to 'DNS' > 'My records' and look for the record that is associated with your subdomain. [[File:record-associated-with-subdomain.png|750px]]

== Creating a gateway ==

# Go to 'Networks' > 'My gateways' and click 'Create a Gateway' in the 'My Gateways' dialog box. [[File:my-gateways.png|750px]]
# In the 'Create new Gateway' dialog box, fill out all required fields (Hostname can be left blank), click 'Add', and you should get an alert saying 'Gateway created successfully.' [[File:create-new-gateway.png|750px]] [[File:Gateway-created-successfully-v4.png|750px]]
# To add a subnet to your gateway, click the edit button under 'Actions' (see step 2 above). You will be taken to an 'Update Gateway' dialog box, which includes information about your gateway. Click 'Add New Network'. [[File:Update-gateway-v4.png|750px]]
# You will then see an 'Add New Network' dialog box (see below). Select a network from your list of networks; leave 'Find Network' field blank; and then click 'Add'. You should see an alert titled 'Network Successfully Linked to this Gateway' (see below). You can verify that your network has been added by clicking 'View My Gateways' and seeing said gateway under 'My Gateways' (see below). [[File:add-new-network-v3.png|750px]] [[File:Network-successfully-linked-to-gateway-v4.png|750px]] [[File:verify-my-gateways-v3.2.png|750px]]
# If you would like to add someone else's network using their unique code, click 'Add New Network', which will take you to the 'Add New Network' dialog box. Fill out the required information, and click 'Find'. You should have a 44Net address displaying in the 'Network found' field. Click 'Add', and you should see an alert titled 'Network Successfully Linked to this Gateway' (see step 4 above). [[File:Add-network-to-gateway-v4.png|750px]]
# You can add or remove linked networks by clicking the 'Add New Network' or 'Unlink' button, respectively (see steps 3 and 4 above).

== Requesting address space for BGP use (via network list) ==

# From the 'Networks' dropdown menu, go to 'All IPv4 networks', and request a BGP assignment (e.g., 44.31.0.0/16 - BGP Assignments) by clicking on the 'Request Assignment' icon to the right of the listed assignment (green clipboard). [[File:Request-bgp-assignment-v4.png|500px]]
# On the 'Request IP Assignment' dialog box, fill out the mandatory fields, agree to the EULA, and click 'Continue'. [[File:Request-ip-assignment-for-bgp-v4.png|750px]]
# You should see a 'BGP Information' dialog box on the UI. Fill out the mandatory information, click 'Submit Request', [[File:Bgp-information-v4.png|750px]] and you should now see 'Thank you for requesting address space from ARDC' (see Step 2 under 'Use Case: IPIP Tunnel Mesh, Radio, Globally Unique Space, or General Address Assignment'). Note that the justification must be at least 100 characters.
# You can confirm the address has been successfully requested by going to 'Tickets' > 'View my tickets', and your request should be visible in the 'List your tickets' dialog box. Once the ticket has been closed, you should see the allocation listed in your IPv4 networks. [[File:all-ipv4-allocations-by-user.png|500px]] Clicking 'Edit' will bring you to the 'Update Network' dialog box, where you can make appropriate updates, download the EULA, download the Letter of Authorization (LOA), etc (see below). [[File:update-network-v3.2.png|750px]]

== v2.0 Features ==

=== Dashboard ===

After logging in, you should see your Dashboard. If your email has been verified, you should see an 'Account' menu and a 'Tickets' menu at the top right-hand side of the UI. If you have been granted additional privileges, you will see additional menus for those related privileges. The Dashboard will also display information boxes, such as your latest login, IP, and timestamp, or outstanding notifications you need to be aware of.

[[File:Dashboard-v4.png|750px]]

=== Help ===

The 'Help' dropdown menu provides the following options:
*'''View EULA''': displays a copy of the Portal's End User License Agreement (EULA)

* '''2FA''': defines 2FA and provides details on multiple 2FA options to choose from to add to your account

* '''LoT''': provides an overview of Level of Trust (LoT), how it works, and how to increase your LoT

* '''CIDR''': provides an overview of Classless Inter-Domain Routing (CIDR)

* '''Limits''': provides an explanation of your specific limits on Portal activities, which are directly related to your current LoT

* '''Member pages''': These are pages generated by other members

* '''Subdomains''': provides an overview of subdomains and DNS and steps needed to request subdomains

* '''Passwords''': provides password requirements and recommendations for how to create a strong password for your Portal account

* '''Glossary''': includes definitions for terminology relevant to using the Portal

* '''Community''': includes links to ARDC's Groups.io group, along with links to relevant subgroups

* '''Lookup callsign''': allows you to look up call signs of other users on the Portal

=== Maps ===

* '''Distance''': allows you to perform distance and bearing calculations

* '''Maidenhead''': allows you to generate a map from a Maidenhead locator

* '''Conversions''': allows you to convert from DMS to lat/long and back

* '''World map''': a map that displays the approximate location for all members

=== Account ===

The 'Account' dropdown menu provides the following options:
* '''Profile''': allows you to view and update your personal data

* '''Call signs''': allows you to add/remove/verify your call sign(s)

* '''LoT entries''': lists your Level of Trust (LoT) entires

* '''Verify address''': allows you to go through the address verification process, which is needed if you are requesting BGP announced address space

* '''Organisations''': allows you to create organizations and view information of the organizations you are affiliated with

* '''Notifications''': displays a list of user notifications

* '''Notification types''': displays all notification types/options

* '''View all notifications''': displays all your active notifications

* '''Logs''': displays all your log entries

* '''My public page''': displays any public pages you have added and provides the ability to add more

* '''Delete my account''': allows a user to delete their account

==== Profile ====

A user's profile is always available, whether or not a their email address has been verified. Through the profile, a user has access to the following:
* Personal Information (PII) a user chooses to share with ARDC

* The ability for a user to update their account

* The ability for a user to enable 2FA on their account

Changes made to the profile will require the current password to be entered at the bottom of the page and clicking 'Save' for changes take effect.

==== Call signs ====

Here, the user is presented with a list of all call signs they have entered. A user can add up to a maximum of five call signs (can be adjusted on a per user basis), with only one call sign being the primary. Clubs and organization can add up to 10 of their own call signs by default. Call signs must be verified before they can be used. All verified call signs must be unique within the system.

==== Level of Trust (LoT) and LoT Entries ====

The Portal uses various methods to verify users and thus gain 'trust', which is referred to as the 'Level of Trust' (LoT). LoT is used to increase confidence that a user is who they say they are and record that there is a skill set and knowledge that is needed to assign responsibilities to said user in the Portal.

As various tasks are accomplished, such as verification of email and/or call signs, points will be assigned to a users' account. The more points a user has, the higher the LoT. You can learn more about LoT by going to either 'Help' > 'LoT' or 'Account' > 'LoT info' on the navigation menu.

The LoT List is a read-only list for LoT entries of a user. You can find this list by going to 'Account' > 'LoT list'. A user will have at least one entry that shows that their email address was verified. Below are a few examples of what accesses are granted based on a user's LoT.

* Email is not verified
** User can login, access their own profile, delete their account
* Call sign is not verified
** User cannot access DNS records or request address space

==== Notifications ====

The system informs users of various events via notifications. [[File:Notification-types-v4.png|750px]]

Mandatory Notifications:
* Contact Member
* Password Reset
* Ticket Reminder
* LoT Expiry
* LoT Added
* Account Expiry
* LOA Expiry

Optional Notifications:
* Login
* Profile Update
* Ticket Assigned
* ...and many more

Clicking on 'Methods' (under the 'Actions' column, see above) will allow the user to choose a preferred method of notification: [[File:notification-methods.png|750px]]

* Email
* SMS
* many more coming soon, e.g. Zulip, Signal, Telegram...

=== Tickets ===

Tickets track tasks, along with their associated progress, within the Portal. Items managed by tickets include, but are not limited to:
* Call sign verification
* Request(s) for resources (e.g., address space)

The 'Tickets' dropdown menu will allow the user to view all of their tickets, create a new support ticket, and serves as a reference to check the status of any user requests.

Ticket types that are not 'Support' are available within the system and are accessible to a user in a specific circumstance.

=== Domain name system (DNS) records ===

ARDC manages the ampr.org domain for its own use and supports Portal user needs.

Once a user's call sign is verified, they should see the DNS dropdown menu with submenu options 'Domains', 'My subdomains', and 'My records'.

[[File:dns-menu.png|750px]]

=== Networks ===

Once a user's call sign is verified, they should see the 'Networks' dropdown menu with submenu options 'Request addresses', 'All IPv4 networks', 'All IPv6 networks', 'All gateways', 'My IPv4 networks', 'My IPv6 networks', 'My gateways'.

=== Contact ===

Clicking 'Contact' takes you to the 'CONTACT US' form, where you can reach out to Portal admins with inquiries, reporting issues, etc.

[[File:contact-us-v3.png|750px]]

=== API ===

An [[API]] enables programs to access data maintained in the Portal.

== Helpful resources ==

'''Subnet calculator''': [https://www.calculator.net/ip-subnet-calculator.html https://www.calculator.net/ip-subnet-calculator.html]

[[Category:How-To]]
[[Category:How-To Guides]]
[[Category:Portal]]
[[Category:Portal Workflows]]