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?

Nah.  I'm good.

--- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.