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

On Sun, Apr 19, 2026 at 4:36=E2=80=AFAM Hugh Blemings <[email protected]> w=
rote:
>
> 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. =F0=9F=99=81
> >
> > I haven't had a chance to fully review what you've posted=E2=80=A6 ther=
e 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=E2=80=A6 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 her=
e.
>
> 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 [email protected] as my main email address.
> If you're using [email protected] please update your address book accordi=
ngly.
> 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