Subj : Re: Tutorial for rookies
To : N1uro
From : tenser
Date : Wed Oct 13 2021 01:36 am
On 11 Oct 2021 at 10:45p, N1uro pondered and said...
N1> Hello tenser;
N1>
N1> -=> tenser wrote to N1uro <=-
N1>
N1> te> What I see is modification to the stack based on incremental
N1> te> updates elsewhere in the kernel. You had said that there were
N1> te> two or so outstanding issues that were particularly problematic,
N1> te> though in exactly what way or whether they prevented Linux
N1> te> kernel AX.25 from working at all was not specified.,
N1>
N1> te> So I see activity, and my setup works. Hardly proof, but given
N1> te> that these issues you referred to don't seem to be tracked
N1> te> anywhere and we have empirical evidence that the Linux AX.25
N1> te> stack works, and given that your answer to questions about the
N1> te> state of things are pretty light on details, one wonders whether
N1> te> these things are still problems -- indeed, if they ever were at
N1> te> all.
N1>
N1> There's stale socket bugs, critical kernel bugs that can render a box
N1> totally useless and other bugs. For me to list these bugs in specific
N1> for hams would be completely counter productive. Any cracker could then
N1> own your license. Basic ones have been discussed in linux-hams and
N1> that's enough. If you run something such as LinBPQ or JNOS2 you are not
N1> affected because you are NOT using the native linux protocol stack. CVE
N1> refuses to post any critical but known bugs with Winlink for the same
N1> reasons - it'd be counterproductive.
Bluntly, I don't believe you. With no supporting evidence of the
existence of these bugs, let alone tracking, this is nothing more
than typical ham-centric FUD.
To be clear, I was hoping for a pointer to a bug tracker. It
wouldn't be hard to produce patches for something as simple as
Linux's AX.25 implementation, but without any sort of knowledge
about what is _actually_ wrong, let alone root cause
investigation, it's not a good time investment.
"Read the archives of my project's mailing list" is not a good
answer.
N1> He described it perfectly clear, and it's been discussed on the URONode
N1> support list. Just because you don't see it or refuse to review the
N1> threads on the URONode list or elsewhere doesn't mean it does not exist.
Since you appear to keep shutting that project down on a whim, I'm
not particularly interested in looking closely at it. Sorry, it's
just not worth my time to deal with cantankerous folks who don't
want to work in a spirit of cooperation.
But he didn't actually describe the problem. There was a comment
saying something about freeing up resources; that was it. No
description of how the problem manifests itself, what goes wrong,
the failure mode, etc. There's a one-line patch that was apparently
never sent to LKML in an older version of the kernel on a random
web site.
N1> However considering what you appear to keep yourself blinded to, might I
N1> suggest Windows and BPQ32?
