Re: [PATCH net] netrom: do some basic forms of validation on incoming frames

[Chris Maness]

forms of validation on incoming frames

I for one run two BBS’s that use LinFBB.  LinFBB uses the kernel code
for its AX.25 stack.  This is still excellent software that is
maintained.  I also use Linux as a netrom node for said BBS with real
radio ports and internet connectivity to out of town nodes using the
ax25ipd/netromd that both use kernel stacks.


73 de Chris KQ6UP


Thanks,

Chris Maness


Thanks,
Chris Maness
-Sent from my iPhone


On Fri, Apr 10, 2026 at 4:53 PM Chris Maness
<christopher.maness@xxxxxxxxx> wrote:
>
> I for one run two BBS’s that use LinFBB.  LinFBB uses the kernel code for its AX.25 stack.  This is still excellent software that is maintained.  I also use Linux as a netrom node for said BBS with real radio ports and internet connectivity to out of town nodes using the ax25ipd/netromd that both use kernel stacks.
>
> 73 de Chris KQ6UP
>
> Thanks,
> Chris Maness
> -Sent from my iPhone
>
>
> On Fri, Apr 10, 2026 at 4:38 PM Hugh Blemings <hugh@xxxxxxxxxxxx> wrote:
>>
>>
>> On 11/4/2026 08:51, Craig wrote:
>> >> If the main concern here is ongoing maintenance of these Ham Radio
>> >> related protocols/drivers, can we pause for a moment on anything as
>> >> dramatic as removing from the tree entirely ?
>> >>
>> >> There is a good cohort of capable kernel folks that either are or
>> >> were ham radio operators who I believe, upon realising that things
>> >> have got to this point, will be happy to redouble efforts to ensure
>> >> this code maintained and tested to a satisfactory standard.
>> >>
>> >> Or, alternatively, as a technical community it may be that the Ham
>> >> Radio interested folks conclude that out of tree or user space
>> >> solutions are a better way forward as others have proposed.
>> >>
>> >> Give us a few days, please, for the word to be put around that we
>> >> need to pull ourselves together a bit as a technical group :)
>> >>
>> >
>> > I, for one, really can't imagine pulling an entire network subsytem
>> > out of the kernel without any
>> > knowledge of how/if/when it's used.  Like intercontinental radio
>> > networks, global email, ax.25
>> > keyboard-to-keyboard, BBS and other emergency-communication systems
>> > throughout the
>> > world.  If you're sure the Internet will never fail, I guess it makes
>> > sense removing all of this
>> > since it's inconvenient to maintain.
>> >
>> > Global AX.25 keyboard-to-keyboard on 14.105Mhz
>> >
>> >    https://qsl.net/kb9pvh/105.html
>> >
>> > AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
>> >
>> >  https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
>> >
>> > Global radio email using AX.25
>> >
>> >   https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
>> > the Earth and Space)
>> >
>> > This is all in operation by Amateur Radio ARES emergency
>> > protocols/technologies.  This
>> > will not pass the headline test when it comes to Linux detractors.
>> >
>> > Most of this is running on Raspberry Pi / Linux 24/7.
>> >
>> > If we want to kill all these apps and somehow force them into user space,
>> > it's akin to just switching to Windows - and flounder with the
>> > Microsoft folks
>> > trying to do the same thing.
>>
>> Your email Craig neatly encapsulates just some of the practical and
>> ongoing applications of the kernel code in question - I don't think this
>> is in dispute.
>>
>> What's pertinent is if we as the ham/amatuer radio community can agree
>> on whether in tree, out of tree modules, or a userspace device driver
>> approach make the most sense.  If we are to keep code in the kernel in
>> any form, we as a community need to find someone(s) that have the skills
>> and bandwidth to keep the in tree code up to date.
>>
>> I don't think this would be onerous and I have a couple of people in
>> mind to nudge who may be happy to do so if that proves the right way
>> forward.  At a pinch I could do it, but that'll mean a lot of catching
>> up. But I think it reasonable that the responsibility here falls to
>> folks that are closer to the code in question than the wider and
>> overworked kernel maintainer community.
>>
>> That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong
>> case for moving out of the kernel while still providing a way to have
>> backward compatibility, perhaps this might be the way forward?
>>
>> In any case, done well, this approach would not kill the apps or force
>> anything like switching to Windows! :) Great projects like digipi would
>> be able to continue with minimal changes.
>>
>> I wonder if a separate thread in linux-hams makes sense to discuss the
>> various longer term approaches to maintaining these capabilities - I'll
>> try make time later today to kick one off - such deliberations will be
>> of less interest to the broader LKML and other lists.
>>
>> Cheers/73
>> Hugh
>>
>>
>>
>> >
>> >
>> > -craig
>> > https://digipi.org/
>> >
>> >
>> --
>> I am slowly moving to hugh@xxxxxxxxxxxxxx as my main email address.
>> If you're using hugh@xxxxxxxxxxxx please update your address book accordingly.
>> Thank you :)
>>
>>


-- 
Thanks,
Chris Maness