Discuss: Future of AX25, NETROM and ROSE in the kernel ?

Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Hugh Blemings]

Hi,

Long time lurker, (nearly) first time poster as the saying goes[0].

My email here seeks to see that we, as a technical community, navigate a 
potentially tricky point in the hobbies presence in the Linux kernel as 
well as possible.  I've a decent long term view of the matters at hand, 
but lack a good "current" picture[1].

There's a thread[2] that kicked off, primarily in linux-hams that 
initially focused on bug fixes in the Netrom code. This has broadened 
into a discussion about the future of the AX25, NETROM and ROSE code in 
the kernel.

A couple of well respected mainline kernel maintainers have noted the 
maintenance overhead of these (relatively) lightly used protocols. This 
has led to, quite reasonably I think, some discussion of whether they 
should be removed or deprecated - the perception being they're not used 
much. Note that none of this a judgement on the hobby itself or the 
utility to the broader community.

There's also been some very good points raised in that thread by hams 
around whether it makes sense to move the implementation into userspace 
or to out of tree kernel code. Both can be done in such a way as to 
cause little to no impact from the actual application code that makes 
use of the protocols.

My intuition is that we probably have folks here on linux-vger that have 
the requisite skills and reputation, or ability to gain them, to keep 
the in tree drivers up to date. But perhaps that's just "old" thinking 
on my part?

So I figure a thread here to discuss how we go forward made some sense - 
stay with the current in kernel model, look to go oot or userspace.

If the consensus is that trying to keep the drivers in thee tree up to 
date is the way ahead I'm happy to put my hand up to do this if no one 
else is so inclined - I've a couple friends I can bug to help me get 
back up to speed.

But I'm also mindful there are other hams that have been more recently 
involved in kernel work, so am going to give them a gentle nudge offline 
too :)

Cheers/73,
Hugh
VK3YYZ/AD5RV


[0] First licensed in the late 80's and can even remember the smell and 
sound of a Model 33 teletype connected to a TNC :)

[1] Installed Slackware in the early 90's and never fully recovered, 
some of my code still in the kernel to this day :)

[2] 
https://lore.kernel.org/linux-hams/761f83cc-58eb-4b4a-ba91-d11412e7b2a6@gmail.com/T/#t



-- 
I am slowly moving tohugh@blemings.id.au as my main email address.
If you're usinghugh@blemings.org please update your address book accordingly.
Thank you :)

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Dan Cross]

On Sat, Apr 11, 2026 at 3:36 AM Hugh Blemings <hugh@blemings.org> wrote:
> [snip]
> My email here seeks to see that we, as a technical community, navigate a
> potentially tricky point in the hobbies presence in the Linux kernel as
> well as possible.  I've a decent long term view of the matters at hand,
> but lack a good "current" picture[1].
>
> There's a thread[2] that kicked off, primarily in linux-hams that
> initially focused on bug fixes in the Netrom code. This has broadened
> into a discussion about the future of the AX25, NETROM and ROSE code in
> the kernel.
>
> A couple of well respected mainline kernel maintainers have noted the
> maintenance overhead of these (relatively) lightly used protocols. This
> has led to, quite reasonably I think, some discussion of whether they
> should be removed or deprecated - the perception being they're not used
> much. Note that none of this a judgement on the hobby itself or the
> utility to the broader community.
>
> There's also been some very good points raised in that thread by hams
> around whether it makes sense to move the implementation into userspace
> or to out of tree kernel code. Both can be done in such a way as to
> cause little to no impact from the actual application code that makes
> use of the protocols.
>
> My intuition is that we probably have folks here on linux-vger that have
> the requisite skills and reputation, or ability to gain them, to keep
> the in tree drivers up to date. But perhaps that's just "old" thinking
> on my part?
>
> So I figure a thread here to discuss how we go forward made some sense -
> stay with the current in kernel model, look to go oot or userspace.

I think it would help frame the discussion to present some background,
go into the various options, and present pros and cons of each. With
respect to keeping protocol implementations in the kernel and in-tree,
it further makes sense to present these from two separate
perspectives: a) hams who use the software, and b) the Linux kernel as
a project.

# Background

Linux has had implementations of AX.25, NET/ROM, and ROSE in the
kernel since the 1990s.  Though it is nowhere near as popular as it
was in the 1980s and early 90s, packet radio using these protocols is
still in use world-wide: AX.25 in particular is the basis for APRS,
and beyond that remains broadly popular for accessing packet BBSes,
exchanging mail, sending radio telegrams via the various traffic
services (e.g., NTS in the US), and so on.

AX.25 is a bit of an odd duck by modern standards; if fits into
neither the IP/TCP nor ISO/OSI models neatly, and in OSI terms,
provides functionality spanning layers 2-4; details may be found in
the relevant specification documents.  Note that Linux implements
version 2.0 of the protocol
(http://bitsavers.informatik.uni-stuttgart.de/communications/arrl/AX.25_Link-Layer_Protocol_Ver_2.0_198410.pdf),
while the current version is 2.2
(http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf), with updates in 2017
(https://tarpn.net/t/faq/files/AX25.2.2-Sep%2017-1-10Sep17.pdf).

NET/ROM adds multi-hop routing on top of AX.25 with dynamic routing,
and provides a facility to address nodes using an alias (e.g., "CHAT"
resolving to "G8BPQ-6" or similar).  As far as I know, the
specification is rather less formal than those for AX.25, and the
protocol was original specified as a chapter in the manual for the
original software.  This has been extracted a few times, such as
https://packet-radio.net/wp-content/uploads/2017/04/netrom1.pdf

ROSE is basically an implementation of the CCITT X.25 network layer
with some elements of AX.25 mixed in. Stations are addressed using a
10-digit "telephone numbers".  It is statically routed.  Its
documentation describes it as, "The ROSE X.25 Packet Switch", e.g.:
https://web.tapr.org/meetings/CNC_1989/CNC1989-ROSE-PacketSwitch-W2VY.pdf

Of these, surely AX.25 is the most widely used (after all, it forms
the basis for the others), with NET/ROM next and ROSE last.  It's
unclear how widely used ROSE is at this point; lack of
interoperability with other packages that just don't implement it is
probably a limiting factor here.

A folks have run TCP/IP over packet radio by embedded IP datagrams (or
their fragments) inside of AX.25 frames that are then sent over the
air using the in-kernel stack.

## Recent Activity Outside of the Linux Kernel

Newer developments in the amateur packet radio world have focused on:

* Improving the implementation of AX.25 to increase robustness and
throughput.  For example, adaptations of Jacobson/Karels congestion
control have been incorporated into some AX.25 implementations, as
have adaptively pausing protocol timers if the link is detected to be
in use.  Also, adding forward error correcting codes at layer 2 to
help with transit over marginal RF links e.g. FX.25
(https://web.archive.org/web/20110718212817/http://www.stensat.org/Docs/FX-25_01_06.pdf).
* Newer protocols to try and work around some of the deficiencies of
AX.25: IL2P ("Improved layer 2 Protocol":
https://packet-radio.net/wp-content/uploads/2020/10/il2p-specification0-4.pdf),
and ARNGLL (https://github.com/arngll/arngll-spec/blob/main/n6drc-arngll.md)
are examples here.
* The European amateur radio community noted problems with NET/ROM
some time ago and proposed FlexNET as an alternative
(https://www.qsl.net/ww2bsa/index_htm_files/DCC1995-FlexNet-DK7WJ-N2IRZ.pdf),
but details on the protocol itself are scant. Similar problems were
noted by others, and by all accounts, the best ideas of NET/ROM and
FlexNET were synthesized into the INP3 protocol
(https://wiki.oarc.uk/_media/packet:internodeprotocolnp.pdf).

Not much, if any, of this work has been picked up by Linux writ large.
Some doesn't make a lot of sense from a kernel perspective: FX.25, for
instance, is more of a physical layer thing.  However, while there
have been patches proposed at various times (e.g., there was an
implementation of INP3 done as a delta on top of the in-kernel NET/ROM
code), little of it seems to have been integrated: I didn't see
evidence that INP3 support was incorporated when I looked earlier this
morning.

## Problems With the Kernel Implementations

Put bluntly, the kernel implementations are showing their age.
Although it has incorporated some enhancements (7-bit sequence
numbers, for example) the AX.25 protocol implementation remains at
version 2.0.

Thomas Habets has noted a number of problems in a blog post:
https://blog.habets.se/2021/11/AX25-user-space.html Some of these are
purely quality of implementation issues ("setting CRC mode resets all
other settings") but others seem rather more fundamental: e.g., the
"10 REJs in a row" problem: this suggests that the kernel does not
iterate over frames in the outbound window or examine the outbound
queue when processing inbound supervisor frames.

Problems including data corruption, leaked references, deadlocks,
panics, etc, occur distressingly regularly.  E.g.,
https://lore.kernel.org/linux-hams/CAEoi9W4FGoEv+2FUKs7zc=XoLuwhhLY8f8t_xQ6MgTJyzQPxXA@mail.gmail.com/
and https://lore.kernel.org/linux-hams/my4l7ljo35dnwxl33maqhyvw7666dmuwtduwtyhnzdlb6bbf5m@5sbp4tvg246f/
for recent-ish examples.

A search of the `linux-hams` archive turns up a lot of problem
reports, some of which are unaddressed for significant chunks of time.
As Habets put it, if the current implementations were proposed for
incorporation into the kernel today, they probably wouldn't be
accepted, as they would not meet the required quality bar.  Note
that's not a comment on the original authors or their work, but
rather, just an acknowledgement of the current state of affairs and
how things have changed since these were first introduced.  As the man
page for ax25(4) puts it, "BUGS: Too numerous to list in full
currently."

# The Various Options

It seems that there's consensus that the current situation is
untenable, and something should be done.  As I see it, there are
essentially three paths, with some variations on each:

1. Keep AX.25, NET/ROM, and ROSE in the kernel and in-tree
2. Move the protocols to an out-of-tree module (so they still run in
the kernel, but are not maintained in-tree)
3. Move the protocols into a userspace implementation, and provide
backwards compatibility with a shim library that exposes the existing
API, but implements it in terms of a new implementation

## Staying in-kernel, in-tree.

This is the current state of affairs. Right now, the code receives
token maintenance, and there are two paths forward:

1. Status quo, in which no maintainer(s) step up, and the code remains
in a state of perpetual gloom, hovering between mostly working and
mostly broken.  It works _well enough_ for those who invest time in
getting it up and running that it's not critical to change, but system
updates are risky.  As time goes forward, and more people are scouring
the kernel looking for zero-day security exploits and DOS
opportunities, it becomes an obvious attack vector.  This is obviously
not ideal.
2. One or more maintainers actively begin active work to modernize and
clean up the implementations. It's a fairly large task, and requires
coordination with a much larger effort (that is, the rest of the
kernel).  There are obviously folks who are skilled at working in the
Linux kernel, well integrated into the community, and thus positioned
to provide maintenance going forward.  There are also folks who are
interested in keeping this code in-tree.  The question is whether the
intersection of these two sets is large enough to be sustainable.

Then there's the question of a larger roadmap: if the code stays
in-tree, does it gain new functionality (e.g., implementing the latest
version of AX.25) or is this just to keep what's there working well?

### Pros and Cons of Staying in the Kernel (for hams)

Pros:
* No need to change anything.  Those with working AX.25/NETROM/ROSE
configurations can keep using them as-is.  There is no additional
software to install, no additional services to set up, configure or
monitor, nothing else to keep up to date, etc.  Installation is de
facto handled by the distribution.
* Compatibility with existing software.  Programs written to use the
sockets API and these protocol families (e.g., `socket(AF_AX25,
...);`) work unchanged.
* Likely some amount of prestige is attached to having a working
implementation in a project as important as the Linux kernel.

Cons:
* Inaccessibility to most developers.  The number of people who can
write reasonable software in a higher-level language is pretty large
at this point; the number who can do so in C is much smaller.  The
number who can competently write software in the Linux kernel and
shepherd it through the review and integration process is a tiny
fraction of that.
* Slow rate of change. Updates goes through upstream and are generally
filtered down through distros and vendors; this can take quite some
time. Of course, users can compile and install their own kernels, but
many do not.
* A bug in the stack often manifests as a system `panic`, taking down
the entire machine, not just the AX.25, NET/ROM, or ROSE software.
* Shifting to active maintenance requires long-term investment.  The
intersection of people using this code and capable of working on it is
small; unlike (say) TCP/IP, or process scheduling, memory management,
or filesystems and management of storage devices, the number of people
who are concerned about the health of this code at more than an
abstract level is tiny, which means incentive to keep it up-to-date
and well-maintained is inherently lower than other areas of the
kernel.
* Documentation is poor, in the sense that it hasn't been kept up to
date as things have changed.  The TLDP pages have good information,
but their age shows, and the necessary formulae for figuring all of
this out in 2026 is scattered across web pages, blogs, video
tutorials, and mailing list archives in a way that can be bewildering
to newcomers.  I tried to document my own setup at https://kz2x.radio,
but that just underscores the point.

### Pros and Cons of Staying in the Kernel (for Linux)

Pros:
* It keeps the kernel honest.  Having a protocol that doesn't match
the usual pattern of TCP/IP in-tree is a forcing function for
exercising the common networking code (e.g., sockets etc) in useful
ways to keep it flexible.  Doing so makes it easier to incorporate
future protocols that follow different models.
* Goodwill with the ham community.

Cons:
* It is a maintenance drag.  The state of this code is not great, it
has many known bugs, and the amount of effort required to bring it up
to current quality standards, not to mention incorporate e.g. the new
versioner version of AX.25 or anything else, is substantial.  A single
motivated maintainer with kernel experience can likely stop the
bleeding, but doing much more in a reasonable timeframe is going to
need more folks who are invested and have the time to devote to it.
* A bug in AX.25 usually kills the kernel.  This isn't just a problem
for hams, its a problem for the rest of the kernel, as well.
* Related, if folks really started looking into it, it would probably
turn into a security quagmire.  Running in-kernel, with complete
privileges over the entire machine, is the antithesis of a modern
security posture, for that a tiny fraction of the overall Linux
installed base would use.  And as Habets pointed out, what _should_
the semantics be for e.g. network ACLs and AX.25?

### Discussion

The most likely course of action is some middle path between status
quo and active maintenance; my suspicion is that we can probably
muster up a couple of folks who will improve the code to a point that
it's substantially less buggy, leaky, and crash-prone as it is
currently.  That would certainly be an improvement; but will we be
able to attract the combination of folks with the time, motivation,
and familiarity required to, say, update the AX.25 v2.2?

The central question I come back to is, what advantage is conferred by
keeping these protocols in the kernel?  Put another way, what is it
about having them in the kernel that cannot be replicated by moving
them out of the kernel and running them elsewhere?

## Moving to an Out-of-Tree Kernel Module

An alternative that keeps the stack in the kernel, thus retaining the
ham-perspective compatibility "Pro" listed above, is to move the
implementations out-of-tree, so that they are still loaded as kernel
modules, but no longer maintained in the kernel tree proper.

### Pros and Cons of an Out-of-Tree Kernel Module

Pros:
* As with an in-tree kernel module, compatibility with existing
software is preserved.
* Similarly, a working setup is mostly unchanged, caveat that the
out-of-tree modules must be installed as an additional, explicit step.
* Most kernel developers are freed from any sort of maintenance
burden.  The AX.25, NET/ROM, and ROSE code is not a priori a vector
for security exploits, nor a magnet for sloppy LLM-generated patches
or syzkaller fuzzing reports.

Cons:
* Maintenance is now squarely on the amateur radio community (which is
not necessarily a bad thing)
* Installing the modules for AX.25, NET/ROM, and ROSE would require
additional steps, though would hopefully be facilitated by distros and
package managers.  Note that the userspace programs used with these
protocols already require an additional step to install; this would
just be adding a handful of other packages to the mix.
* It is likely to be seen as a demotion by the ham community.  No
matter how much you explain it to folks, there will be some who view
removal from the main kernel tree as a step down.
* Inevitably, there will be impedance mismatches as kernel interfaces
change.  Whereas now these are mostly taken care of since the code
is-tree along with the interfaces that are changing, out-of-tree
modules will lag the kernel. Moreover, there is a versioning burden
that does not exist right now: one must ensure one has the correct
module version of their kernel, etc.
* This code as a forcing function of an unusual protocol family to
prevent the kernel's network stack from becoming too IP-centric is
significantly lessened; it would still need to be accommodated, since
it would run in the context of the kernel, but since it was not in the
kernel by default, it wouldn't exert as much pressure on design.
* It doesn't do much, if anything, for the documentation problem.
* It doesn't do much to address the accessibility issue for most developers.

### Discussion

Some more details are needed here, in particular around infrastructure
to support this (where does it live? How is it tested?) and
interaction with the kernel proper (how are breaking changes detected
and mitigated?).

## Moving to a Userspace Implementation

The final option on the list of viable alternatives is to excise the
protocols from the kernel entirely, and run them in a userspace
program.  This is predicated on the observation that each of the three
is run over relatively low-speed links: 1200 BAUD to 9600.  In that
case, there the performance penalty for crossing the
userspace<->kernel boundary is insignificant.

There is significant precedence for this: among extant AX.25
implementations, JNOS2, LinBPQ, Direwolf, Sailer's SoundModem (and
probably others I'm unaware of), are all userspace implementation.

### Pros and Cons of a Userspace Implementation

Pros:
* The protocol code could be made completely independent of the
kernel, and thus both are free to change at their own rate; the
interface boundaries would be the usual system call interfaces.
* A bug or failure merely crashes a program (which could be
restarted); it does not take down the entire machine.
* It could be reimplemented in whatever language one likes, or
accessed via FFI; it not be constrained to C (or Rust).  Libraries
implementing the protocols could be incorporated into larger systems
that use open monitoring systems, are managed by e.g. systemd, and so
forth.
* A suitable userspace implementation may already exist: LinBPQ and/or
JNOS2, for example.  LinFBB was brought up as a use case, and at a
glance it appears that it may be possible to make LinFBB use LinBPQ
directly.
* Userspace code is arguably easier to develop and iterate on:
portions can be unit-tested, it can be put into artificial test
scaffolds and exercised, and so forth.  The edit/compile/test cycle is
fast and can be made fairly easy.  Sanitizers, fuzzing, and other
tooling can be easily brought to bear to flush out bugs and increase
robustness.  While much of this can likely be done in the kernel, as
well, it requires considerably more expertise to do that well.
* Userspace implementations of these protocols are not constrained by
e.g., the sockets API that the existing kernel implementation exposes
to client programs.  They can provide whatever interface to clients
that makes sense, specifically tailored to amateur radio use.
* This could lead to further simplifications inside of the kernel: for
example, special cases for routing IP over AX.25 and/or NET/ROM (if
these exist) could be removed; TAP/TUN could handle that use case
instead.
* A userspace implementation is more portable.  Perhaps Linux hams
don't particularly care so much, but with some care, the
implementation could be made to run on e.g. a microcontroller or
another OS.

Cons:
* Compatibility with existing software requires more work.  In
particular, to use existing software that expects the sockets API
unmodified, we would have provide a shim library that implements that
interface, and then inject that into existing software: for
dynamically linked executables, this can be done using `LD_PRELOAD`
tricks; statically linked binaries would be out of luck.
* Just emulating the sockets API doesn't give exact fidelity for other
functionality.  Files tied to AX.25 and synthesized by the kernel,
such as those under /sys, are not easily provided (unless we overload
`open` in addition to the socket APIs).  Tools like `netstat` would no
longer display information about amateur radio protocol state; to be
fair, the `ip` and `ss` tools are already pretty anemic for these
protocols, but the point is that some amount of retooling would be
necessary.
* Messaging would ideally be handled with thoughtfulness, care, and
attention.  I would anticipate that some members of the amateur radio
community would have a hard time not misinterpreting removal from the
kernel as "Linux kicking out hams!"  Of course that wouldn't be the
case; a significant factor of the motivation for proposing a userspace
implementation is getting a much _better_ implementation for hams.

### Discussion

Again, I would ask why people want AX.25, NET/ROM, and ROSE in the
kernel, specifically.  To my mind, the important part is being able to
use these protocols from a stable platform; whether they are
implemented in or out of the kernel is an implementation detail, and
mostly irrelevant.

To that end, the userspace route seems like the best, long-term,
provided it is messaged and socialized properly, and folks step up who
are committed to providing the necessary compatibility shim libraries.

> If the consensus is that trying to keep the drivers in thee tree up to
> date is the way ahead I'm happy to put my hand up to do this if no one
> else is so inclined - I've a couple friends I can bug to help me get
> back up to speed.
>
> But I'm also mindful there are other hams that have been more recently
> involved in kernel work, so am going to give them a gentle nudge offline
> too :)

The above are my two cents.  I'd be interested in other perspectives.

        - Dan C.
          (KZ2X)

> Cheers/73,
> Hugh
> VK3YYZ/AD5RV
>
>
> [0] First licensed in the late 80's and can even remember the smell and
> sound of a Model 33 teletype connected to a TNC :)
>
> [1] Installed Slackware in the early 90's and never fully recovered,
> some of my code still in the kernel to this day :)
>
> [2]
> https://lore.kernel.org/linux-hams/761f83cc-58eb-4b4a-ba91-d11412e7b2a6@gmail.com/T/#t
>
>
>
> --
> I am slowly moving tohugh@blemings.id.au as my main email address.
> If you're usinghugh@blemings.org please update your address book accordingly.
> Thank you :)
>
>

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Dan Cross]

[Top-posting to make meta-commendary]

I wonder if other folks have thoughts, here? It doesn't bode well that
the discussion hasn't progressed. :-(

        - Dan C.

On Mon, Apr 13, 2026 at 7:31 PM Dan Cross <crossd@gmail.com> wrote:
> On Sat, Apr 11, 2026 at 3:36 AM Hugh Blemings <hugh@blemings.org> wrote:
> > [snip]
> > My email here seeks to see that we, as a technical community, navigate a
> > potentially tricky point in the hobbies presence in the Linux kernel as
> > well as possible.  I've a decent long term view of the matters at hand,
> > but lack a good "current" picture[1].
> >
> > There's a thread[2] that kicked off, primarily in linux-hams that
> > initially focused on bug fixes in the Netrom code. This has broadened
> > into a discussion about the future of the AX25, NETROM and ROSE code in
> > the kernel.
> >
> > A couple of well respected mainline kernel maintainers have noted the
> > maintenance overhead of these (relatively) lightly used protocols. This
> > has led to, quite reasonably I think, some discussion of whether they
> > should be removed or deprecated - the perception being they're not used
> > much. Note that none of this a judgement on the hobby itself or the
> > utility to the broader community.
> >
> > There's also been some very good points raised in that thread by hams
> > around whether it makes sense to move the implementation into userspace
> > or to out of tree kernel code. Both can be done in such a way as to
> > cause little to no impact from the actual application code that makes
> > use of the protocols.
> >
> > My intuition is that we probably have folks here on linux-vger that have
> > the requisite skills and reputation, or ability to gain them, to keep
> > the in tree drivers up to date. But perhaps that's just "old" thinking
> > on my part?
> >
> > So I figure a thread here to discuss how we go forward made some sense -
> > stay with the current in kernel model, look to go oot or userspace.
>
> I think it would help frame the discussion to present some background,
> go into the various options, and present pros and cons of each. With
> respect to keeping protocol implementations in the kernel and in-tree,
> it further makes sense to present these from two separate
> perspectives: a) hams who use the software, and b) the Linux kernel as
> a project.
>
> # Background
>
> Linux has had implementations of AX.25, NET/ROM, and ROSE in the
> kernel since the 1990s.  Though it is nowhere near as popular as it
> was in the 1980s and early 90s, packet radio using these protocols is
> still in use world-wide: AX.25 in particular is the basis for APRS,
> and beyond that remains broadly popular for accessing packet BBSes,
> exchanging mail, sending radio telegrams via the various traffic
> services (e.g., NTS in the US), and so on.
>
> AX.25 is a bit of an odd duck by modern standards; if fits into
> neither the IP/TCP nor ISO/OSI models neatly, and in OSI terms,
> provides functionality spanning layers 2-4; details may be found in
> the relevant specification documents.  Note that Linux implements
> version 2.0 of the protocol
> (http://bitsavers.informatik.uni-stuttgart.de/communications/arrl/AX.25_Link-Layer_Protocol_Ver_2.0_198410.pdf),
> while the current version is 2.2
> (http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf), with updates in 2017
> (https://tarpn.net/t/faq/files/AX25.2.2-Sep%2017-1-10Sep17.pdf).
>
> NET/ROM adds multi-hop routing on top of AX.25 with dynamic routing,
> and provides a facility to address nodes using an alias (e.g., "CHAT"
> resolving to "G8BPQ-6" or similar).  As far as I know, the
> specification is rather less formal than those for AX.25, and the
> protocol was original specified as a chapter in the manual for the
> original software.  This has been extracted a few times, such as
> https://packet-radio.net/wp-content/uploads/2017/04/netrom1.pdf
>
> ROSE is basically an implementation of the CCITT X.25 network layer
> with some elements of AX.25 mixed in. Stations are addressed using a
> 10-digit "telephone numbers".  It is statically routed.  Its
> documentation describes it as, "The ROSE X.25 Packet Switch", e.g.:
> https://web.tapr.org/meetings/CNC_1989/CNC1989-ROSE-PacketSwitch-W2VY.pdf
>
> Of these, surely AX.25 is the most widely used (after all, it forms
> the basis for the others), with NET/ROM next and ROSE last.  It's
> unclear how widely used ROSE is at this point; lack of
> interoperability with other packages that just don't implement it is
> probably a limiting factor here.
>
> A folks have run TCP/IP over packet radio by embedded IP datagrams (or
> their fragments) inside of AX.25 frames that are then sent over the
> air using the in-kernel stack.
>
> ## Recent Activity Outside of the Linux Kernel
>
> Newer developments in the amateur packet radio world have focused on:
>
> * Improving the implementation of AX.25 to increase robustness and
> throughput.  For example, adaptations of Jacobson/Karels congestion
> control have been incorporated into some AX.25 implementations, as
> have adaptively pausing protocol timers if the link is detected to be
> in use.  Also, adding forward error correcting codes at layer 2 to
> help with transit over marginal RF links e.g. FX.25
> (https://web.archive.org/web/20110718212817/http://www.stensat.org/Docs/FX-25_01_06.pdf).
> * Newer protocols to try and work around some of the deficiencies of
> AX.25: IL2P ("Improved layer 2 Protocol":
> https://packet-radio.net/wp-content/uploads/2020/10/il2p-specification0-4.pdf),
> and ARNGLL (https://github.com/arngll/arngll-spec/blob/main/n6drc-arngll.md)
> are examples here.
> * The European amateur radio community noted problems with NET/ROM
> some time ago and proposed FlexNET as an alternative
> (https://www.qsl.net/ww2bsa/index_htm_files/DCC1995-FlexNet-DK7WJ-N2IRZ.pdf),
> but details on the protocol itself are scant. Similar problems were
> noted by others, and by all accounts, the best ideas of NET/ROM and
> FlexNET were synthesized into the INP3 protocol
> (https://wiki.oarc.uk/_media/packet:internodeprotocolnp.pdf).
>
> Not much, if any, of this work has been picked up by Linux writ large.
> Some doesn't make a lot of sense from a kernel perspective: FX.25, for
> instance, is more of a physical layer thing.  However, while there
> have been patches proposed at various times (e.g., there was an
> implementation of INP3 done as a delta on top of the in-kernel NET/ROM
> code), little of it seems to have been integrated: I didn't see
> evidence that INP3 support was incorporated when I looked earlier this
> morning.
>
> ## Problems With the Kernel Implementations
>
> Put bluntly, the kernel implementations are showing their age.
> Although it has incorporated some enhancements (7-bit sequence
> numbers, for example) the AX.25 protocol implementation remains at
> version 2.0.
>
> Thomas Habets has noted a number of problems in a blog post:
> https://blog.habets.se/2021/11/AX25-user-space.html Some of these are
> purely quality of implementation issues ("setting CRC mode resets all
> other settings") but others seem rather more fundamental: e.g., the
> "10 REJs in a row" problem: this suggests that the kernel does not
> iterate over frames in the outbound window or examine the outbound
> queue when processing inbound supervisor frames.
>
> Problems including data corruption, leaked references, deadlocks,
> panics, etc, occur distressingly regularly.  E.g.,
> https://lore.kernel.org/linux-hams/CAEoi9W4FGoEv+2FUKs7zc=XoLuwhhLY8f8t_xQ6MgTJyzQPxXA@mail.gmail.com/
> and https://lore.kernel.org/linux-hams/my4l7ljo35dnwxl33maqhyvw7666dmuwtduwtyhnzdlb6bbf5m@5sbp4tvg246f/
> for recent-ish examples.
>
> A search of the `linux-hams` archive turns up a lot of problem
> reports, some of which are unaddressed for significant chunks of time.
> As Habets put it, if the current implementations were proposed for
> incorporation into the kernel today, they probably wouldn't be
> accepted, as they would not meet the required quality bar.  Note
> that's not a comment on the original authors or their work, but
> rather, just an acknowledgement of the current state of affairs and
> how things have changed since these were first introduced.  As the man
> page for ax25(4) puts it, "BUGS: Too numerous to list in full
> currently."
>
> # The Various Options
>
> It seems that there's consensus that the current situation is
> untenable, and something should be done.  As I see it, there are
> essentially three paths, with some variations on each:
>
> 1. Keep AX.25, NET/ROM, and ROSE in the kernel and in-tree
> 2. Move the protocols to an out-of-tree module (so they still run in
> the kernel, but are not maintained in-tree)
> 3. Move the protocols into a userspace implementation, and provide
> backwards compatibility with a shim library that exposes the existing
> API, but implements it in terms of a new implementation
>
> ## Staying in-kernel, in-tree.
>
> This is the current state of affairs. Right now, the code receives
> token maintenance, and there are two paths forward:
>
> 1. Status quo, in which no maintainer(s) step up, and the code remains
> in a state of perpetual gloom, hovering between mostly working and
> mostly broken.  It works _well enough_ for those who invest time in
> getting it up and running that it's not critical to change, but system
> updates are risky.  As time goes forward, and more people are scouring
> the kernel looking for zero-day security exploits and DOS
> opportunities, it becomes an obvious attack vector.  This is obviously
> not ideal.
> 2. One or more maintainers actively begin active work to modernize and
> clean up the implementations. It's a fairly large task, and requires
> coordination with a much larger effort (that is, the rest of the
> kernel).  There are obviously folks who are skilled at working in the
> Linux kernel, well integrated into the community, and thus positioned
> to provide maintenance going forward.  There are also folks who are
> interested in keeping this code in-tree.  The question is whether the
> intersection of these two sets is large enough to be sustainable.
>
> Then there's the question of a larger roadmap: if the code stays
> in-tree, does it gain new functionality (e.g., implementing the latest
> version of AX.25) or is this just to keep what's there working well?
>
> ### Pros and Cons of Staying in the Kernel (for hams)
>
> Pros:
> * No need to change anything.  Those with working AX.25/NETROM/ROSE
> configurations can keep using them as-is.  There is no additional
> software to install, no additional services to set up, configure or
> monitor, nothing else to keep up to date, etc.  Installation is de
> facto handled by the distribution.
> * Compatibility with existing software.  Programs written to use the
> sockets API and these protocol families (e.g., `socket(AF_AX25,
> ...);`) work unchanged.
> * Likely some amount of prestige is attached to having a working
> implementation in a project as important as the Linux kernel.
>
> Cons:
> * Inaccessibility to most developers.  The number of people who can
> write reasonable software in a higher-level language is pretty large
> at this point; the number who can do so in C is much smaller.  The
> number who can competently write software in the Linux kernel and
> shepherd it through the review and integration process is a tiny
> fraction of that.
> * Slow rate of change. Updates goes through upstream and are generally
> filtered down through distros and vendors; this can take quite some
> time. Of course, users can compile and install their own kernels, but
> many do not.
> * A bug in the stack often manifests as a system `panic`, taking down
> the entire machine, not just the AX.25, NET/ROM, or ROSE software.
> * Shifting to active maintenance requires long-term investment.  The
> intersection of people using this code and capable of working on it is
> small; unlike (say) TCP/IP, or process scheduling, memory management,
> or filesystems and management of storage devices, the number of people
> who are concerned about the health of this code at more than an
> abstract level is tiny, which means incentive to keep it up-to-date
> and well-maintained is inherently lower than other areas of the
> kernel.
> * Documentation is poor, in the sense that it hasn't been kept up to
> date as things have changed.  The TLDP pages have good information,
> but their age shows, and the necessary formulae for figuring all of
> this out in 2026 is scattered across web pages, blogs, video
> tutorials, and mailing list archives in a way that can be bewildering
> to newcomers.  I tried to document my own setup at https://kz2x.radio,
> but that just underscores the point.
>
> ### Pros and Cons of Staying in the Kernel (for Linux)
>
> Pros:
> * It keeps the kernel honest.  Having a protocol that doesn't match
> the usual pattern of TCP/IP in-tree is a forcing function for
> exercising the common networking code (e.g., sockets etc) in useful
> ways to keep it flexible.  Doing so makes it easier to incorporate
> future protocols that follow different models.
> * Goodwill with the ham community.
>
> Cons:
> * It is a maintenance drag.  The state of this code is not great, it
> has many known bugs, and the amount of effort required to bring it up
> to current quality standards, not to mention incorporate e.g. the new
> versioner version of AX.25 or anything else, is substantial.  A single
> motivated maintainer with kernel experience can likely stop the
> bleeding, but doing much more in a reasonable timeframe is going to
> need more folks who are invested and have the time to devote to it.
> * A bug in AX.25 usually kills the kernel.  This isn't just a problem
> for hams, its a problem for the rest of the kernel, as well.
> * Related, if folks really started looking into it, it would probably
> turn into a security quagmire.  Running in-kernel, with complete
> privileges over the entire machine, is the antithesis of a modern
> security posture, for that a tiny fraction of the overall Linux
> installed base would use.  And as Habets pointed out, what _should_
> the semantics be for e.g. network ACLs and AX.25?
>
> ### Discussion
>
> The most likely course of action is some middle path between status
> quo and active maintenance; my suspicion is that we can probably
> muster up a couple of folks who will improve the code to a point that
> it's substantially less buggy, leaky, and crash-prone as it is
> currently.  That would certainly be an improvement; but will we be
> able to attract the combination of folks with the time, motivation,
> and familiarity required to, say, update the AX.25 v2.2?
>
> The central question I come back to is, what advantage is conferred by
> keeping these protocols in the kernel?  Put another way, what is it
> about having them in the kernel that cannot be replicated by moving
> them out of the kernel and running them elsewhere?
>
> ## Moving to an Out-of-Tree Kernel Module
>
> An alternative that keeps the stack in the kernel, thus retaining the
> ham-perspective compatibility "Pro" listed above, is to move the
> implementations out-of-tree, so that they are still loaded as kernel
> modules, but no longer maintained in the kernel tree proper.
>
> ### Pros and Cons of an Out-of-Tree Kernel Module
>
> Pros:
> * As with an in-tree kernel module, compatibility with existing
> software is preserved.
> * Similarly, a working setup is mostly unchanged, caveat that the
> out-of-tree modules must be installed as an additional, explicit step.
> * Most kernel developers are freed from any sort of maintenance
> burden.  The AX.25, NET/ROM, and ROSE code is not a priori a vector
> for security exploits, nor a magnet for sloppy LLM-generated patches
> or syzkaller fuzzing reports.
>
> Cons:
> * Maintenance is now squarely on the amateur radio community (which is
> not necessarily a bad thing)
> * Installing the modules for AX.25, NET/ROM, and ROSE would require
> additional steps, though would hopefully be facilitated by distros and
> package managers.  Note that the userspace programs used with these
> protocols already require an additional step to install; this would
> just be adding a handful of other packages to the mix.
> * It is likely to be seen as a demotion by the ham community.  No
> matter how much you explain it to folks, there will be some who view
> removal from the main kernel tree as a step down.
> * Inevitably, there will be impedance mismatches as kernel interfaces
> change.  Whereas now these are mostly taken care of since the code
> is-tree along with the interfaces that are changing, out-of-tree
> modules will lag the kernel. Moreover, there is a versioning burden
> that does not exist right now: one must ensure one has the correct
> module version of their kernel, etc.
> * This code as a forcing function of an unusual protocol family to
> prevent the kernel's network stack from becoming too IP-centric is
> significantly lessened; it would still need to be accommodated, since
> it would run in the context of the kernel, but since it was not in the
> kernel by default, it wouldn't exert as much pressure on design.
> * It doesn't do much, if anything, for the documentation problem.
> * It doesn't do much to address the accessibility issue for most developers.
>
> ### Discussion
>
> Some more details are needed here, in particular around infrastructure
> to support this (where does it live? How is it tested?) and
> interaction with the kernel proper (how are breaking changes detected
> and mitigated?).
>
> ## Moving to a Userspace Implementation
>
> The final option on the list of viable alternatives is to excise the
> protocols from the kernel entirely, and run them in a userspace
> program.  This is predicated on the observation that each of the three
> is run over relatively low-speed links: 1200 BAUD to 9600.  In that
> case, there the performance penalty for crossing the
> userspace<->kernel boundary is insignificant.
>
> There is significant precedence for this: among extant AX.25
> implementations, JNOS2, LinBPQ, Direwolf, Sailer's SoundModem (and
> probably others I'm unaware of), are all userspace implementation.
>
> ### Pros and Cons of a Userspace Implementation
>
> Pros:
> * The protocol code could be made completely independent of the
> kernel, and thus both are free to change at their own rate; the
> interface boundaries would be the usual system call interfaces.
> * A bug or failure merely crashes a program (which could be
> restarted); it does not take down the entire machine.
> * It could be reimplemented in whatever language one likes, or
> accessed via FFI; it not be constrained to C (or Rust).  Libraries
> implementing the protocols could be incorporated into larger systems
> that use open monitoring systems, are managed by e.g. systemd, and so
> forth.
> * A suitable userspace implementation may already exist: LinBPQ and/or
> JNOS2, for example.  LinFBB was brought up as a use case, and at a
> glance it appears that it may be possible to make LinFBB use LinBPQ
> directly.
> * Userspace code is arguably easier to develop and iterate on:
> portions can be unit-tested, it can be put into artificial test
> scaffolds and exercised, and so forth.  The edit/compile/test cycle is
> fast and can be made fairly easy.  Sanitizers, fuzzing, and other
> tooling can be easily brought to bear to flush out bugs and increase
> robustness.  While much of this can likely be done in the kernel, as
> well, it requires considerably more expertise to do that well.
> * Userspace implementations of these protocols are not constrained by
> e.g., the sockets API that the existing kernel implementation exposes
> to client programs.  They can provide whatever interface to clients
> that makes sense, specifically tailored to amateur radio use.
> * This could lead to further simplifications inside of the kernel: for
> example, special cases for routing IP over AX.25 and/or NET/ROM (if
> these exist) could be removed; TAP/TUN could handle that use case
> instead.
> * A userspace implementation is more portable.  Perhaps Linux hams
> don't particularly care so much, but with some care, the
> implementation could be made to run on e.g. a microcontroller or
> another OS.
>
> Cons:
> * Compatibility with existing software requires more work.  In
> particular, to use existing software that expects the sockets API
> unmodified, we would have provide a shim library that implements that
> interface, and then inject that into existing software: for
> dynamically linked executables, this can be done using `LD_PRELOAD`
> tricks; statically linked binaries would be out of luck.
> * Just emulating the sockets API doesn't give exact fidelity for other
> functionality.  Files tied to AX.25 and synthesized by the kernel,
> such as those under /sys, are not easily provided (unless we overload
> `open` in addition to the socket APIs).  Tools like `netstat` would no
> longer display information about amateur radio protocol state; to be
> fair, the `ip` and `ss` tools are already pretty anemic for these
> protocols, but the point is that some amount of retooling would be
> necessary.
> * Messaging would ideally be handled with thoughtfulness, care, and
> attention.  I would anticipate that some members of the amateur radio
> community would have a hard time not misinterpreting removal from the
> kernel as "Linux kicking out hams!"  Of course that wouldn't be the
> case; a significant factor of the motivation for proposing a userspace
> implementation is getting a much _better_ implementation for hams.
>
> ### Discussion
>
> Again, I would ask why people want AX.25, NET/ROM, and ROSE in the
> kernel, specifically.  To my mind, the important part is being able to
> use these protocols from a stable platform; whether they are
> implemented in or out of the kernel is an implementation detail, and
> mostly irrelevant.
>
> To that end, the userspace route seems like the best, long-term,
> provided it is messaged and socialized properly, and folks step up who
> are committed to providing the necessary compatibility shim libraries.
>
> > If the consensus is that trying to keep the drivers in thee tree up to
> > date is the way ahead I'm happy to put my hand up to do this if no one
> > else is so inclined - I've a couple friends I can bug to help me get
> > back up to speed.
> >
> > But I'm also mindful there are other hams that have been more recently
> > involved in kernel work, so am going to give them a gentle nudge offline
> > too :)
>
> The above are my two cents.  I'd be interested in other perspectives.
>
>         - Dan C.
>           (KZ2X)
>
> > Cheers/73,
> > Hugh
> > VK3YYZ/AD5RV
> >
> >
> > [0] First licensed in the late 80's and can even remember the smell and
> > sound of a Model 33 teletype connected to a TNC :)
> >
> > [1] Installed Slackware in the early 90's and never fully recovered,
> > some of my code still in the kernel to this day :)
> >
> > [2]
> > https://lore.kernel.org/linux-hams/761f83cc-58eb-4b4a-ba91-d11412e7b2a6@gmail.com/T/#t
> >
> >
> >
> > --
> > I am slowly moving tohugh@blemings.id.au as my main email address.
> > If you're usinghugh@blemings.org please update your address book accordingly.
> > Thank you :)
> >
> >

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Nate Bargmann]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

* On 2026 18 Apr 14:29 -0500, Dan Cross wrote:
> [Top-posting to make meta-commendary]
> 
> I wonder if other folks have thoughts, here? It doesn't bode well that
> the discussion hasn't progressed. :-(

Your reply was so comprehensive, there isn't much to add!

A few years ago I had in mind to give using the kernel AX25 stack a go
but reading various reports kind of turned me away.  I had last done so
in the late '90s or so as I recall.  I did do some testing with Direwolf
at the time instead.

As a potential user it really makes no difference whether support is in
the kernel proper or user space.  From a maintainer's view, it's likely
that putting the AX25 code entirely in user space (option 3) is the best
practice these days.

Let's face it.  The kernel is no longer a niche hobby project but is
very much an enterprise project.  It makes sense to move the AX25 stack
entirely into user space.  Before doing so, what could the AX25 stack in
user space do that Direwolf cannot?  I know no one is suggesting this,
but should an option four be considered where the AX25 code is dropped
entirely from the kernel and potential users are directed to Direwolf or
some such existing project?

73, Nate, N0NB

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Steven R. Loomis]

I have a dormant project [1] to add Node.js bindings for AX25 to be able to write Node.js apps directly on AX25.
My AX25 use is also dormant, but I would love to bring it back up someday.

User space makes a lot of sense for the reasons given.
Since maintenance is a question though, perhaps it’s a question of who would volunteer for making any change (beyond no change)? 

> what could the AX25 stack in user space do that Direwolf cannot?  

The AX25 stack would still attach to Direwolf so that connected AX25 apps could run.

[1]: https://github.com/srl295/node-ax25-seqpacket/blob/add-actual-stuff/lib/ax25-seqpacket.js

--
Steven R. Loomis
K6SPI

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[jj]

I have actual RF ports with ax25/netrom/tcpip connectivity to our MARCAN 
packet system on vhf 1200b and I'm willing to do any real-world testing 
if needed..

On 2026-04-18 22:31, Steven R. Loomis wrote:
> I have a dormant project [1] to add Node.js bindings for AX25 to be able to write Node.js apps directly on AX25.
> My AX25 use is also dormant, but I would love to bring it back up someday.
>
> User space makes a lot of sense for the reasons given.
> Since maintenance is a question though, perhaps it’s a question of who would volunteer for making any change (beyond no change)?
>
>> what could the AX25 stack in user space do that Direwolf cannot?
> The AX25 stack would still attach to Direwolf so that connected AX25 apps could run.
>
> [1]: https://github.com/srl295/node-ax25-seqpacket/blob/add-actual-stuff/lib/ax25-seqpacket.js
>
> --
> Steven R. Loomis
> K6SPI
>
>

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Stuart Longland VK4MSL]

On 19/4/26 05:28, Dan Cross wrote:
> [Top-posting to make meta-commendary]
> 
> I wonder if other folks have thoughts, here? It doesn't bode well that
> the discussion hasn't progressed. 🙁

I haven't had a chance to fully review what you've posted… there was a 
lot of historical information in there including detail on the protocols 
in question.  I've earmarked it to go through closely however. (e.g. I 
had heard of "ROSE" but never seen a spec for it.)

My situation was wanting a library that I could use to do AX.25 
networking from userspace without having applications having to elevate 
to `root` to achieve it.  There was also a maintenance concern.  Rather 
than try and work out the AX.25 kernel stack, I opted to instead build 
my own.

Instructive, but difficult as the documentation is sketchy in places.

My implementation was written in Python 3.5+ for ease of development. 
Probably not the best option, but it got the job done.  `aioax25` 
allowed me to deliver a project for an emergency comms group and 
provides a reasonable foundation for simple tasks.  The stack is also 
portable to other platforms.  (I mostly only care about Linux and *BSD, 
but well written software should work elsewhere too.  Apparently it 
works fine on Apple MacOS X.)

A userspace AX.25 daemon which implements the stack would seem to be the 
best course of action, but the elephant in the room is what the API 
would look like.

The only thing I've seen close to achieving something like that would be 
the AGWPE protocol, however the author of that AX.25 stack has 
categorically stated that he "owns" that protocol.  I don't feel like 
going to court to argue copyright of interfaces for the sake of a hobby.

The AGWPE protocol is also very limiting: a lot of fields in the AX.25 
frame are not accessible via this protocol, either for reading or 
setting.  Want to use the two reserved bits to signal something in a 
custom protocol?  Too bad.

I was therefore pondering a "stream"-like protocol using KISS-style 
framing (to re-use existing code).  The frames would serve as an RPC 
mechanism for implementing something like the `libax25` API, exposing 
the same functionality and allowing an application to interact with the 
AX.25 stack without having to implement the whole protocol (as they'd 
have to do with KISS).

Client applications could connect either via Unix domain sockets or TCP.

You mention the performance hit of crossing the kernel/user-space 
boundary… I think Direwolf experimentally can work as high as 38400bps. 
A turn-of-the-century desktop PC was easily able to keep up with that 
for PPP links (with `pppd` running in userspace).  ARMv7 single board 
computers made 15 years later can deliver similar performance.  I don't 
think this will be much of a bottleneck in practice.

I think userspace is the right way forward given the niche use case here.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Hugh Blemings]

HI All,

On 19/4/2026 14:01, Stuart Longland VK4MSL wrote:
> On 19/4/26 05:28, Dan Cross wrote:
>> [Top-posting to make meta-commendary]
>>
>> I wonder if other folks have thoughts, here? It doesn't bode well that
>> the discussion hasn't progressed. 🙁
>
> I haven't had a chance to fully review what you've posted… there was a 
> lot of historical information in there including detail on the 
> protocols in question.  I've earmarked it to go through closely 
> however. (e.g. I had heard of "ROSE" but never seen a spec for it.)
>
> My situation was wanting a library that I could use to do AX.25 
> networking from userspace without having applications having to 
> elevate to `root` to achieve it.  There was also a maintenance 
> concern.  Rather than try and work out the AX.25 kernel stack, I opted 
> to instead build my own.
>
> Instructive, but difficult as the documentation is sketchy in places.
>
> My implementation was written in Python 3.5+ for ease of development. 
> Probably not the best option, but it got the job done.  `aioax25` 
> allowed me to deliver a project for an emergency comms group and 
> provides a reasonable foundation for simple tasks.  The stack is also 
> portable to other platforms.  (I mostly only care about Linux and 
> *BSD, but well written software should work elsewhere too.  Apparently 
> it works fine on Apple MacOS X.)
>
> A userspace AX.25 daemon which implements the stack would seem to be 
> the best course of action, but the elephant in the room is what the 
> API would look like.
>
> The only thing I've seen close to achieving something like that would 
> be the AGWPE protocol, however the author of that AX.25 stack has 
> categorically stated that he "owns" that protocol.  I don't feel like 
> going to court to argue copyright of interfaces for the sake of a hobby.
>
> The AGWPE protocol is also very limiting: a lot of fields in the AX.25 
> frame are not accessible via this protocol, either for reading or 
> setting.  Want to use the two reserved bits to signal something in a 
> custom protocol?  Too bad.
>
> I was therefore pondering a "stream"-like protocol using KISS-style 
> framing (to re-use existing code).  The frames would serve as an RPC 
> mechanism for implementing something like the `libax25` API, exposing 
> the same functionality and allowing an application to interact with 
> the AX.25 stack without having to implement the whole protocol (as 
> they'd have to do with KISS).
>
> Client applications could connect either via Unix domain sockets or TCP.
>
> You mention the performance hit of crossing the kernel/user-space 
> boundary… I think Direwolf experimentally can work as high as 
> 38400bps. A turn-of-the-century desktop PC was easily able to keep up 
> with that for PPP links (with `pppd` running in userspace). ARMv7 
> single board computers made 15 years later can deliver similar 
> performance.  I don't think this will be much of a bottleneck in 
> practice.
>
> I think userspace is the right way forward given the niche use case here.

Apologies, I kicked off this thread and life intervened a bit and have 
only now had a chance to get back to read through the excellent 
discourse since.

I did have one off list conversation about this which was similarly 
leaning towards a well managed/discussed shift to a userspace approach. 
The individual in question has had quite a lot of both ham radio and 
FOSS experience - I'll give them a nudge and see if they would be 
willing to weigh in here too as I think they'd add a lot to the thread.

I wonder if anyone on list feels they have the right skills to put 
together the shim/compatibility library that would be needed to allow 
the kernel code to be removed?  Seems like that might be the next thing 
to explore ?

Hoping things settle down a bit and will be able to contribute more to 
ongoing discussion

vy 73
Hugh
VK1YYZ/AD5RV



-- 
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Steve Conklin]

On Sun, Apr 19, 2026 at 4:36 AM Hugh Blemings <hugh@blemings.org> wrote:
>
> HI All,
>
> On 19/4/2026 14:01, Stuart Longland VK4MSL wrote:
> > On 19/4/26 05:28, Dan Cross wrote:
> >> [Top-posting to make meta-commendary]
> >>
> >> I wonder if other folks have thoughts, here? It doesn't bode well that
> >> the discussion hasn't progressed. 🙁
> >
> > I haven't had a chance to fully review what you've posted… there was a
> > lot of historical information in there including detail on the
> > protocols in question.  I've earmarked it to go through closely
> > however. (e.g. I had heard of "ROSE" but never seen a spec for it.)
> >
> > My situation was wanting a library that I could use to do AX.25
> > networking from userspace without having applications having to
> > elevate to `root` to achieve it.  There was also a maintenance
> > concern.  Rather than try and work out the AX.25 kernel stack, I opted
> > to instead build my own.
> >
> > Instructive, but difficult as the documentation is sketchy in places.
> >
> > My implementation was written in Python 3.5+ for ease of development.
> > Probably not the best option, but it got the job done.  `aioax25`
> > allowed me to deliver a project for an emergency comms group and
> > provides a reasonable foundation for simple tasks.  The stack is also
> > portable to other platforms.  (I mostly only care about Linux and
> > *BSD, but well written software should work elsewhere too.  Apparently
> > it works fine on Apple MacOS X.)
> >
> > A userspace AX.25 daemon which implements the stack would seem to be
> > the best course of action, but the elephant in the room is what the
> > API would look like.
> >
> > The only thing I've seen close to achieving something like that would
> > be the AGWPE protocol, however the author of that AX.25 stack has
> > categorically stated that he "owns" that protocol.  I don't feel like
> > going to court to argue copyright of interfaces for the sake of a hobby.
> >
> > The AGWPE protocol is also very limiting: a lot of fields in the AX.25
> > frame are not accessible via this protocol, either for reading or
> > setting.  Want to use the two reserved bits to signal something in a
> > custom protocol?  Too bad.
> >
> > I was therefore pondering a "stream"-like protocol using KISS-style
> > framing (to re-use existing code).  The frames would serve as an RPC
> > mechanism for implementing something like the `libax25` API, exposing
> > the same functionality and allowing an application to interact with
> > the AX.25 stack without having to implement the whole protocol (as
> > they'd have to do with KISS).
> >
> > Client applications could connect either via Unix domain sockets or TCP.
> >
> > You mention the performance hit of crossing the kernel/user-space
> > boundary… I think Direwolf experimentally can work as high as
> > 38400bps. A turn-of-the-century desktop PC was easily able to keep up
> > with that for PPP links (with `pppd` running in userspace). ARMv7
> > single board computers made 15 years later can deliver similar
> > performance.  I don't think this will be much of a bottleneck in
> > practice.
> >
> > I think userspace is the right way forward given the niche use case here.
>
> Apologies, I kicked off this thread and life intervened a bit and have
> only now had a chance to get back to read through the excellent
> discourse since.
>
> I did have one off list conversation about this which was similarly
> leaning towards a well managed/discussed shift to a userspace approach.
> The individual in question has had quite a lot of both ham radio and
> FOSS experience - I'll give them a nudge and see if they would be
> willing to weigh in here too as I think they'd add a lot to the thread.
>
> I wonder if anyone on list feels they have the right skills to put
> together the shim/compatibility library that would be needed to allow
> the kernel code to be removed?  Seems like that might be the next thing
> to explore ?
>
> Hoping things settle down a bit and will be able to contribute more to
> ongoing discussion
>
> vy 73
> Hugh
> VK1YYZ/AD5RV
>
>
>
> --
> I am slowly moving to hugh@blemings.id.au as my main email address.
> If you're using hugh@blemings.org please update your address book accordingly.
> Thank you :)
>
>
Hi all,

I'm another former maintainer who has been less active in the FOSS
hamm community for a while. Thanks for all the history, and it's been
great to see familiar names and callsigns again.
/wave

My personal take is that moving to userspace is the right long-term
goal. As for deciding the exact form that takes, this thread is a good
start.

I'd like to make an offer for a long-term home for these components.

I'm a director at ORI (Open Research Institute), and  ORI could be a
home for these. We're a project-based, completely open and volunteer
nonprofit focused on ham radio and communications. We have volunteers
with FOSS and ham radio experience, and we're already set up with a
GitHub org, slack chat, and the infrastructure to manage projects.

https://www.openresearch.institute/
https://www.openresearch.institute/your-project-is-welcome/

Anyone who currently maintains or has an interest in this is welcome
to participate there.
I personally volunteer to help move development infrastructure to ORI,
if that's the wish of the community.

Steve Conklin AI4QR

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[David Ranch]

Hello Hugh,

<snip>

> There's also been some very good points raised in that thread by hams 
> around whether it makes sense to move the implementation into 
> userspace or to out of tree kernel code. Both can be done in such a 
> way as to cause little to no impact from the actual application code 
> that makes use of the protocols.

I've done a little bit of research on the LD_PRELOAD concept and it 
seems that one major gap here is compiling those tools and their 
dependencies.  Specifically, if the AX25 headers are removed from the 
kernel tree, some if not all of these libraries and/or programs will 
file to compile.  The key dependencies consist of:

    - the libax25 library compiled which requires the AX.25 kernel headers
       - My preferred source (more up to date): 
https://github.com/ve7fet/linuxax25
            or
       - Original AX.25 userland repos that are a bit stale: 
https://linux-ax25.in-berlin.de/wiki/Main_Page


To solve the maintenance issue, there once was an ARDC grant ( 
https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/ 
) to have someone take on this responsibility but the person who 
originally accepted the grant, backed out and that need remains 
unfulfilled.   I have also considered proposing a grant to rewrite the 
libax25 code to offer both in-kernel support but also offer the ability 
to translate requests to a remote AGW/PE stack and remove any in-kernel 
AX.25 code.  That could be an excellent alternative but the current 
defacto AGW API interface is limiting and either needs to be extended or 
a parallel control interface needs to be implemented.


> If the consensus is that trying to keep the drivers in thee tree up to 
> date is the way ahead I'm happy to put my hand up to do this if no one 
> else is so inclined - I've a couple friends I can bug to help me get 
> back up to speed.
> But I'm also mindful there are other hams that have been more recently 
> involved in kernel work, so am going to give them a gentle nudge 
> offline too :)

Until some *real* options exist, I would dearly appreciate if you'd be 
willing to take this role up and I (as well as I'm sure others) would be 
happy to help on the testing side.  It should also be noted that Dan 
Cross's comprehensive post did highlight some keys points as well.  The 
Linux AX.25 v2.1 stack is behind the times as the AX.25 v2.2 spec added 
several valuable improvements.  A few userland AX.25 stacks such as from 
WB2OSZ Direwolf, G8BPQ LinBPQ, VE4KLM JNOS, etc. have added AX.25 v2.2 
support, FX.25 FEC support, etc. It would be great to see Linux natively 
add them too but maybe Linux go even further?  Ideas like adding native 
Flexnet routing support would be an excellent addition.

Ultimately, my preference of in-linux support is all the fantastic 
routing flexibility that UNIX is naturally good at.  I suppose that 
userland could do this too but when you might be running multiple AX.25 
userland programs talking to another Userland program acting as a 
router, I imagine things will get complicated for totally different reasons.


--David
KI6ZHD
Maintainer of the Linpac packet terminal program
Silicon Valley 44-Net AMPR coordinator
Maintainer of the Linpac and AX25mail-tools programs
Long time Linux advocate since the linux-1.2 days including being a long 
run IP Masquerade HOWTO maintainer
Maintainer of other many Linux-centric documentation programs like the 
TrinityOS HOWTO, Packet Radio on Raspberry Pi HOWTO, etc.

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Hugh Blemings]

Hi All,

Just to note in this thread (top posting as it's a bit orthogonal to the 
rest of this discussion) that events have preceeded us somewhat here

A patch just recently submitted removes the AX25, NETROM and ROSE code 
from the kernel moving it to the mod-orphan sub tree of netdev

https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/T/#u

A shame but perhaps inevitable - but I think we have a good plan 
unfolding to both take care of medium term maintenance of the kernel 
code (in tree or out as it may be) as well as a move to userspace in the 
longer term.

For the benefit of the netdev readership - we had a thread over in 
linux-hams on this but that may not have been visible to folks in 
netdev.  TL;DR: we think we have a way forward but appreciate this may 
not be quick enough to meet the requirements/concerns put forward

If we can delay removal, that'd be grand, but appreciate that moment may 
have passed.

Cheers/73
Hugh
VK3YYZ/AD5RV


On 20/4/2026 02:18, Steve Conklin wrote:
> On Sun, Apr 19, 2026 at 4:36 AM Hugh Blemings <hugh@blemings.org> wrote:
>> HI All,
>>
>> On 19/4/2026 14:01, Stuart Longland VK4MSL wrote:
>>> On 19/4/26 05:28, Dan Cross wrote:
>>>> [Top-posting to make meta-commendary]
>>>>
>>>> I wonder if other folks have thoughts, here? It doesn't bode well that
>>>> the discussion hasn't progressed. 🙁
>>> I haven't had a chance to fully review what you've posted… there was a
>>> lot of historical information in there including detail on the
>>> protocols in question.  I've earmarked it to go through closely
>>> however. (e.g. I had heard of "ROSE" but never seen a spec for it.)
>>>
>>> My situation was wanting a library that I could use to do AX.25
>>> networking from userspace without having applications having to
>>> elevate to `root` to achieve it.  There was also a maintenance
>>> concern.  Rather than try and work out the AX.25 kernel stack, I opted
>>> to instead build my own.
>>>
>>> Instructive, but difficult as the documentation is sketchy in places.
>>>
>>> My implementation was written in Python 3.5+ for ease of development.
>>> Probably not the best option, but it got the job done.  `aioax25`
>>> allowed me to deliver a project for an emergency comms group and
>>> provides a reasonable foundation for simple tasks.  The stack is also
>>> portable to other platforms.  (I mostly only care about Linux and
>>> *BSD, but well written software should work elsewhere too.  Apparently
>>> it works fine on Apple MacOS X.)
>>>
>>> A userspace AX.25 daemon which implements the stack would seem to be
>>> the best course of action, but the elephant in the room is what the
>>> API would look like.
>>>
>>> The only thing I've seen close to achieving something like that would
>>> be the AGWPE protocol, however the author of that AX.25 stack has
>>> categorically stated that he "owns" that protocol.  I don't feel like
>>> going to court to argue copyright of interfaces for the sake of a hobby.
>>>
>>> The AGWPE protocol is also very limiting: a lot of fields in the AX.25
>>> frame are not accessible via this protocol, either for reading or
>>> setting.  Want to use the two reserved bits to signal something in a
>>> custom protocol?  Too bad.
>>>
>>> I was therefore pondering a "stream"-like protocol using KISS-style
>>> framing (to re-use existing code).  The frames would serve as an RPC
>>> mechanism for implementing something like the `libax25` API, exposing
>>> the same functionality and allowing an application to interact with
>>> the AX.25 stack without having to implement the whole protocol (as
>>> they'd have to do with KISS).
>>>
>>> Client applications could connect either via Unix domain sockets or TCP.
>>>
>>> You mention the performance hit of crossing the kernel/user-space
>>> boundary… I think Direwolf experimentally can work as high as
>>> 38400bps. A turn-of-the-century desktop PC was easily able to keep up
>>> with that for PPP links (with `pppd` running in userspace). ARMv7
>>> single board computers made 15 years later can deliver similar
>>> performance.  I don't think this will be much of a bottleneck in
>>> practice.
>>>
>>> I think userspace is the right way forward given the niche use case here.
>> Apologies, I kicked off this thread and life intervened a bit and have
>> only now had a chance to get back to read through the excellent
>> discourse since.
>>
>> I did have one off list conversation about this which was similarly
>> leaning towards a well managed/discussed shift to a userspace approach.
>> The individual in question has had quite a lot of both ham radio and
>> FOSS experience - I'll give them a nudge and see if they would be
>> willing to weigh in here too as I think they'd add a lot to the thread.
>>
>> I wonder if anyone on list feels they have the right skills to put
>> together the shim/compatibility library that would be needed to allow
>> the kernel code to be removed?  Seems like that might be the next thing
>> to explore ?
>>
>> Hoping things settle down a bit and will be able to contribute more to
>> ongoing discussion
>>
>> vy 73
>> Hugh
>> VK1YYZ/AD5RV
>>
>>
>>
>> --
>> I am slowly moving to hugh@blemings.id.au as my main email address.
>> If you're using hugh@blemings.org please update your address book accordingly.
>> Thank you :)
>>
>>
> Hi all,
>
> I'm another former maintainer who has been less active in the FOSS
> hamm community for a while. Thanks for all the history, and it's been
> great to see familiar names and callsigns again.
> /wave
>
> My personal take is that moving to userspace is the right long-term
> goal. As for deciding the exact form that takes, this thread is a good
> start.
>
> I'd like to make an offer for a long-term home for these components.
>
> I'm a director at ORI (Open Research Institute), and  ORI could be a
> home for these. We're a project-based, completely open and volunteer
> nonprofit focused on ham radio and communications. We have volunteers
> with FOSS and ham radio experience, and we're already set up with a
> GitHub org, slack chat, and the infrastructure to manage projects.
>
> https://www.openresearch.institute/
> https://www.openresearch.institute/your-project-is-welcome/
>
> Anyone who currently maintains or has an interest in this is welcome
> to participate there.
> I personally volunteer to help move development infrastructure to ORI,
> if that's the wish of the community.
>
> Steve Conklin AI4QR
>
-- 
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Dan Cross]

On Tue, Apr 21, 2026 at 2:28 AM Hugh Blemings <hugh@blemings.org> wrote:
> Hi All,
>
> Just to note in this thread (top posting as it's a bit orthogonal to the
> rest of this discussion) that events have preceeded us somewhat here
>
> A patch just recently submitted removes the AX25, NETROM and ROSE code
> from the kernel moving it to the mod-orphan sub tree of netdev
>
> https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/T/#u

Wow, that happened much faster than I had anticipated.

> A shame but perhaps inevitable - but I think we have a good plan
> unfolding to both take care of medium term maintenance of the kernel
> code (in tree or out as it may be) as well as a move to userspace in the
> longer term.
>
> For the benefit of the netdev readership - we had a thread over in
> linux-hams on this but that may not have been visible to folks in
> netdev.  TL;DR: we think we have a way forward but appreciate this may
> not be quick enough to meet the requirements/concerns put forward
>
> If we can delay removal, that'd be grand, but appreciate that moment may
> have passed.

Personally, I think this may actually turn out to be a good thing.  If
nothing else, it's a forcing function for the ham community to get
serious about providing an implementation that works well, and in the
short term, an out-of-tree module can keep things working for folks
while alternatives are investigated and prepared.

I appreciate that folks want to discuss timing, but it doesn't appear
that there is much else to be done at this point. It would make sense
to continue discussion of alternatives over on linux-hams, sparing the
already-overloaded readers of the netdev list from the sordid details.

        - Dan C.
          (KZ2X)

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Steven R. Loomis]

So, is an important next step, having a repo with *just* the ham items with its own build structure?  because there are a number of other modules in the repo mentioned:

https://github.com/linux-netdev/mod-orphan

--
Steven R. Loomis
K6SPI


> El abr 21, 2026, a las 7:06 a.m., Dan Cross <crossd@gmail.com> escribió:
> 
> On Tue, Apr 21, 2026 at 2:28 AM Hugh Blemings <hugh@blemings.org> wrote:
>> Hi All,
>> 
>> Just to note in this thread (top posting as it's a bit orthogonal to the
>> rest of this discussion) that events have preceeded us somewhat here
>> 
>> A patch just recently submitted removes the AX25, NETROM and ROSE code
>> from the kernel moving it to the mod-orphan sub tree of netdev
>> 
>> https://lore.kernel.org/netdev/20260421021824.1293976-1-kuba@kernel.org/T/#u
> 
> Wow, that happened much faster than I had anticipated.
> 
>> A shame but perhaps inevitable - but I think we have a good plan
>> unfolding to both take care of medium term maintenance of the kernel
>> code (in tree or out as it may be) as well as a move to userspace in the
>> longer term.
>> 
>> For the benefit of the netdev readership - we had a thread over in
>> linux-hams on this but that may not have been visible to folks in
>> netdev.  TL;DR: we think we have a way forward but appreciate this may
>> not be quick enough to meet the requirements/concerns put forward
>> 
>> If we can delay removal, that'd be grand, but appreciate that moment may
>> have passed.
> 
> Personally, I think this may actually turn out to be a good thing.  If
> nothing else, it's a forcing function for the ham community to get
> serious about providing an implementation that works well, and in the
> short term, an out-of-tree module can keep things working for folks
> while alternatives are investigated and prepared.
> 
> I appreciate that folks want to discuss timing, but it doesn't appear
> that there is much else to be done at this point. It would make sense
> to continue discussion of alternatives over on linux-hams, sparing the
> already-overloaded readers of the netdev list from the sordid details.
> 
>        - Dan C.
>          (KZ2X)

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Andrew Lunn]

On Tue, Apr 21, 2026 at 09:43:52AM -0500, Steven R. Loomis wrote:
> So, is an important next step, having a repo with *just* the ham items with its own build structure?  because there are a number of other modules in the repo mentioned:
> 
> https://github.com/linux-netdev/mod-orphan

Please don't top post.

This git site is just to collect the modules as out of tree code, so
they don't fully disappear. They will just languish here and bitrot
over time.

If there is going to be an active Maintainer, you need a full tree, so
you can send git pull requests. Once you have the tree, send us a
patch for MAINTAINERs, adding a T: entry pointing to your tree, and
set the L: entry pointing to your mailing list etc.

    Andrew

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Dan Cross]

On Sun, Apr 19, 2026 at 4:37 PM David Ranch <linux-hams@trinnet.net> wrote:
> > [snip]
> > There's also been some very good points raised in that thread by hams
> > around whether it makes sense to move the implementation into
> > userspace or to out of tree kernel code. Both can be done in such a
> > way as to cause little to no impact from the actual application code
> > that makes use of the protocols.
>
> I've done a little bit of research on the LD_PRELOAD concept and it
> seems that one major gap here is compiling those tools and their
> dependencies.  Specifically, if the AX25 headers are removed from the
> kernel tree, some if not all of these libraries and/or programs will
> file to compile.

For things like this, usually the compat shims library provides
whatever headers are needed to build the library. It's common for most
distros to split things up so that package managers provide both "foo"
and "foo-dev" packages; the former tends to be runtime artifacts
(e.g., the `.so` libraries) and the latter build-time/development
artifacts (headers and whatever else is needed for building tools and
things).  Bottom line, I don't think this is a big obstacle.

> The key dependencies consist of:
>
>     - the libax25 library compiled which requires the AX.25 kernel headers
>        - My preferred source (more up to date):
> https://github.com/ve7fet/linuxax25
>             or
>        - Original AX.25 userland repos that are a bit stale:
> https://linux-ax25.in-berlin.de/wiki/Main_Page
>
> To solve the maintenance issue, there once was an ARDC grant (
> https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/
> ) to have someone take on this responsibility but the person who
> originally accepted the grant, backed out and that need remains
> unfulfilled.   I have also considered proposing a grant to rewrite the
> libax25 code to offer both in-kernel support but also offer the ability
> to translate requests to a remote AGW/PE stack and remove any in-kernel
> AX.25 code.  That could be an excellent alternative but the current
> defacto AGW API interface is limiting and either needs to be extended or
> a parallel control interface needs to be implemented.

It seems like upstream has made the decision to remove this code from
the kernel, and to do so on a time scale much faster than I,
personally, had anticipated.

> > If the consensus is that trying to keep the drivers in thee tree up to
> > date is the way ahead I'm happy to put my hand up to do this if no one
> > else is so inclined - I've a couple friends I can bug to help me get
> > back up to speed.
> > But I'm also mindful there are other hams that have been more recently
> > involved in kernel work, so am going to give them a gentle nudge
> > offline too :)
>
> Until some *real* options exist, I would dearly appreciate if you'd be
> willing to take this role up and I (as well as I'm sure others) would be
> happy to help on the testing side.  It should also be noted that Dan
> Cross's comprehensive post did highlight some keys points as well.  The
> Linux AX.25 v2.1 stack is behind the times as the AX.25 v2.2 spec added
> several valuable improvements.  A few userland AX.25 stacks such as from
> WB2OSZ Direwolf, G8BPQ LinBPQ, VE4KLM JNOS, etc. have added AX.25 v2.2
> support, FX.25 FEC support, etc. It would be great to see Linux natively
> add them too but maybe Linux go even further?

Probably the quickest stop-gap measure is to take the existing code
from the mod-orphans repo and get it building out-of-tree, then one
could just load it and continue as before.

> Ideas like adding native
> Flexnet routing support would be an excellent addition.

The problem with FlexNET, specifically, is that documentation for it
just doesn't seem to be available.  I tried looking, and it's possible
a version in German exists somewhere (I neither read nor speak German)
but I couldn't find it.  I went as far as looking for old DCC papers
describing it, and some exist that describe the major ideas, but
nothing with sufficient detail to do an implementation.

> Ultimately, my preference of in-linux support is all the fantastic
> routing flexibility that UNIX is naturally good at.

What flexibility are you thinking about, specifically?  A number of
places (hyperscalars, HPC) move networking out of the kernel for
greater flexibility or performance.

Importantly in this case, the Linux AX.25 stack never really took much
advantage of most of the whizbang features available from the kernel,
and it's not clear what utility some of the more advanced stuff would
have when applied to amateur radio protocols.

> I suppose that
> userland could do this too but when you might be running multiple AX.25
> userland programs talking to another Userland program acting as a
> router, I imagine things will get complicated for totally different reasons.

(It sounds like you might be referring to muxing AX.25 connections
between userspace programs?)

Multiple userspace programs handling one or more logical connections,
coordinating with a server of some kind implementing the lower-layers
of a protocol, follows a pretty well-understood implementation
pattern.  The same techniques the kernel uses to map file descriptors
to such connections can be used in userspace: each connection is
represented by some token that maps to an identifier that uniquely
identifies the protocol-level connection in the server; the actual
mapping from identifier to such connection is just a some kind of
associative container maintained by the server. As events occur (data
sent, data received, timers expire or are reset, control operations of
various kinds) those connections are looked up, logic to handle the
events is run, the connections might transition into new states, and
side-effects (e.g., actual transmission of data, or re-arming a timer)
are emitted and acted upon.

        - Dan C.

Re: Discuss: Future of AX25, NETROM and ROSE in the kernel ?

[Joshua McAdam]

On Wed, Apr 22, 2026 at 5:30 AM Dan Cross <crossd@gmail.com> wrote:

>
> Multiple userspace programs handling one or more logical connections,
> coordinating with a server of some kind implementing the lower-layers
> of a protocol, follows a pretty well-understood implementation
> pattern.  The same techniques the kernel uses to map file descriptors
> to such connections can be used in userspace: each connection is
> represented by some token that maps to an identifier that uniquely
> identifies the protocol-level connection in the server; the actual
> mapping from identifier to such connection is just a some kind of
> associative container maintained by the server. As events occur (data
> sent, data received, timers expire or are reset, control operations of
> various kinds) those connections are looked up, logic to handle the
> events is run, the connections might transition into new states, and
> side-effects (e.g., actual transmission of data, or re-arming a timer)
> are emitted and acted upon.
>
>         - Dan C.

Hi All,

Like Hugh I have also been lurking here for a long time but this is
also my first post,

As a fairly active user of the Kernel Ham stack for decades, seeing
this discussion start is timely because I have been wondering how I
could help, as I could see things seemed to be slowing down and
approaching a turning point where action is necessary.

I believe many people still rely on the kernel stack for BBS's,
Digipeaters, I-Gates, Winlink Gateways and nodes out there running IP
over AX25 - even things like PAT for Winlink which has no native KISS
support, so it relies on Kernel KISS interfaces (i use this
personally).

If there is a way I can help with maintenance or even become a
co-maintainer, I'd be interested to learn more as I've written kernel
drivers before and patched things - but never gotten involved in the
mainline kernel to date.

While I am still fairly proficient in C and have written AX25
implementations for Arduino projects among other things, I wonder (and
hope I don't unintentionally upset anyone by suggesting this) if there
is an opportunity to look at new options like using the recently
introduced kernel rust support to rewrite / tidy things up along the
way to resolve many of the memory safety and many other issues that
have been coming to light lately.

It would be a shame to let this "die on the vine" in both the kernel
and linuxax25 given all the work put in over the years.....

Regards,

Josh M
VK4JLM