Userspace AX.25 stack library [was Re: Kernel 6.9.1 AX.25 Crash]

[Stuart Longland VK4MSL <me@vk4msl.com>]

On 23/5/24 08:22, David Ranch wrote:
> There are a lot of fine protocol details in the Linux stack that are NOT 
> exposed via the "defacto" AGW API standard that stands today.  Maybe if 
> the AGW API was heavily enhanced, maybe it would be possible but there 
> is a whole other level of potential legal issues with that.
> The following was posted years after tools like ldsped, soundmodem, 
> direwolf, etc. were already creating AGW "Server" API services:
> 
> https://www.sv2agw.com/Home/Developers
> -- 
> License Agreement
> 
> You must not reverse engineering the TCP/IP protocol that Packet Engine 
> uses to communicate with client applications. This protocol copyright 
> belongs to me and you cannot emulate it. You can only use it for writing 
> client applications.

Ehh, fun stuff.  I suppose the question then is, what would a home-grown 
packet API look like?

I recall looking at the AGW API and observing some of its limitations 
(the full list illudes me just now, but I recall things like the 
reserved bits were inaccessible).

One thing I observed recently, is that other userspace stacks like BPQ32 
will switch protocols after connecting, so the initial I-frame might be 
sent without routing protocol data (PID 0xf0), but then it'll switch to 
NETROM (PID 0xcf) with its own "frame" format within.

https://gist.github.com/sjlongland/0199d5a7cc7bbc71e83d0cc5577a2509

For someone like myself who's been used to dealing with TCP/IP, AX.25 
seems quite weird… yes, there's UI frames that behave like UDP and 
connected-mode that's sort-of like TCP; but then that connected-mode 
stream is actually functions as a multiplex separated by PID code.

I haven't tried picking apart NETROM yet, nor have I looked at how ROSE 
was structured.  Finding relevant documentation for these protocols is 
getting tricky now.  So the Linux kernel stack, for all its faults and 
failings, is still valuable as it at least implements these once 
documented protocols.

Do we start with maybe defining a wire-representation of the Linux 
kernel AX.25 stack data types and an RPC mechanism?  Or should we toss 
that and start afresh?

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

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