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

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.