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

[Hugh Blemings <hugh@blemings.org>]

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