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

On Sun, Apr 19, 2026 at 4:37=E2=80=AFPM David Ranch <[email protected]=
> 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 header=
s
>        - 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-kern=
el-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 reaso=
ns.

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