[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed removal of kernel AX.25 support




Hello Iain,

This was just an example. We have had issues on x86 and x86_64 where
packets would be emitted twice for no good reason, clogging up channels
with duplicates.

Hmmm.. I'm not sure if I've seen this issue.  Is this reproducible?


The programs in the ax25-apps package often have segfaults during normal
operation.

Yes..  since I started with Linux packet around 2009, I've seen both segfaults and even kernel panics.  It seems that every time, the issue was around sequencing or misconfiguration.  For example, killing the kissattach process and then shutting down the rose0 interface.  That's obviously backwards but if you do that, bad things would happen.  Some improvements have been proposed and patches exist but I don't know if all of them made it upstream.


Yes, there have been other issues too. These are not small packages,
they are complex with many code paths and many features. The lack of a
test suite makes it difficult to have confidence that updates are not
going to break things, especially as we increase compat levels and
automatically introduce new hardening options to the compiler in doing
so. I manually test these packages (although the coverage of those
manual tests is probably 10% of the code paths at best) on amd64 but not
other platforms, and other platforms are historically where I've seen
the hardening-related bugs pop up.

Yes.. unit testing is something that the AX.25 codebase badly needs to protect it from well intentioned kernel developers that break stuff.  I've tried to find out people / companies / processes on how to understand what continuous delivery systems exist for the Linux kernel and other projects and found the Intel system but I was unable to find anyone to contact to see if we could add stuff.  Maybe you know of options here so something could get started here?


The issues that have been fixed there are mostly to satisfy modern
compilers. They have not fixed functional bugs.

Yes, I've uploaded new debs to experimental to avoid breaking unstable
with a messed-up libax25. These are compiled with the latest hardening
options from compat level 12.

Partially but other true code issues have been addressed as well.


  Btw, in addition to the Official AX.25
repo, there is the VE7FET repo which also tries to sync with the
official AX.25 sources but also add additional fixes: 
https://github.com/ve7fet/linuxax25
Have these changes been pushed upstream at all? When we have tried to
ask upstream for comment on bugs we've not had a response, which is
another challenge in this packaging.

Some of them are only in the VE7FET repo, some have been proposed to the upstream maintainers, etc.  I don't know if some/all were committed into the kernel though.


Regarding ax25mail-utils , I own that package and I have updates in the
DEV branch at
https://sourceforge.net/p/ax25mail/ax25mail-utils/ci/develop/tree/ which
resolves all known warnings in Buster.  I'll try to get that promoted to
Master and then do an official release soon.   Same can be said for my
Linpac package as well.
Do these packages require kernel AX.25 support or are they able to use
KISS/AGWPE? We have KISS/AGWPE soundmodems in Debian and so this would
not preclude the continued packaging of ax25mail-utils if the support is
still there for it to be used.

They all require libax25 which means they require the kernel AX.25.  If AX.25 is disabled in the kernel and the libax25/ax25apps/ax25tools packages are removed, a LOT of Linux packet programs will no longer work or worse, fail their dependencies to build.  This potentially impacts all the code here:

   https://radio.linux.org.au/?sectpat=packet&ordpat=title

I've been contemplating what it would take to modify the libax25 program to translate calls into AGW calls that some userland tool like Direwolf could support.  I think a lot of it could be done but I'm not 100% sure that everything could be carried over.  I still believe that there are definite benefits in having the AX25 stack in the kernel so I'd like to see that get fixed. 


In addition to that, people are actively
recruiting kernel talent to help address these issues.
Do you have a reference for this? Has anyone started work?

Yes.. I've reached out to several people and some people stated interested but I haven't had any real traction.  Most recently, I've made a proposal to the ARDC / AMPR44 group to see if we can get a grant to get this work done by established professional kernel developers.  Their grant process is still developing but I remain hopeful this could fast track the effort.


I think loosing
the Linux AX25 kernel start would be a big loss and we need to rally and
get it repaired.
If I had more time to spend on this, I wouldn't be fixing kernel AX.25
but writing a userspace daemon to attach to a KISS/AGWPE TNC and then
put IP out on a tap interface.

Yes.. there are benefits to put this all in userland but some groups have some very complex setups using KISS, FlexNet, Rose, etc. that it's unclear how the routing would really work.  Some deep investigation into understanding these use cases is needed to see what could be done here.

--David
KI6ZHD

Reply to: