• Re: Tutorial for rookies

    From phigan@432:1/100 to Don Epi on Tue Oct 5 08:33:29 2021
    Ohh... And isnt there a chance to use another decoder other than the Kernelone? Im not a Linux user, thats why I asked this silly question :)

    While using a Raspberry Pi 4 as my main desktop for around 8 months, I followed
    some guide on setting up the native ax.25.. I had it connected to a mobilinkd TNC into an Icom, and everything worked pretty well. I could monitor, run APRS apps, call out to packet boards, etc.

    --- Mystic BBS v1.12 A47 2020/11/22 (OnePlus6T/arm32)
    # Origin: phOnE In mY pOckEt BBS (21:1/158.6)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Avon@432:1/100 to phigan on Thu Oct 7 16:38:31 2021
    On 05 Oct 2021 at 03:33a, phigan pondered and said...

    --- Mystic BBS v1.12 A47 2020/11/22 (OnePlus6T/arm32)

    That's a tearline I don't see very often :)

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to phigan on Fri Oct 8 11:06:25 2021
    On 05 Oct 2021 at 03:33a, phigan pondered and said...

    Ohh... And isnt there a chance to use another decoder other than the Kernelone? Im not a Linux user, thats why I asked this silly question

    While using a Raspberry Pi 4 as my main desktop for around 8 months, I followed some guide on setting up the native ax.25.. I had it connected
    to a mobilinkd TNC into an Icom, and everything worked pretty well. I could monitor, run APRS apps, call out to packet boards, etc.

    Indeed. I use a RockPi 4 as a packet station with the kernel AX.25
    stack; it works fine.

    If there are problems with the Linux kernel AX.25 stack, it would be
    useful to know what they are.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/157 to tenser on Fri Oct 8 18:29:00 2021
    Tenser;

    tenser wrote to phigan <=-

    If there are problems with the Linux kernel AX.25 stack, it would be useful to know what they are.

    There's issues with ROSE and ax.25 sockets, NetRom and ax.25 sockets, which
    are the two most widely used encapsulated networking protocols under ax.25. For a more detailed explination, I suggest you follow linux-hams or look
    into the archives of the URONode support list after subscribing to it.

    ... Virginity is experience not yet fulfilled
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (432:1/157)
  • From tenser@432:1/100 to N1uro on Sat Oct 9 12:00:20 2021
    On 08 Oct 2021 at 01:29p, N1uro pondered and said...

    Tenser;

    tenser wrote to phigan <=-

    If there are problems with the Linux kernel AX.25 stack, it would be useful to know what they are.

    There's issues with ROSE and ax.25 sockets, NetRom and ax.25 sockets, which are the two most widely used encapsulated networking protocols
    under ax.25. For a more detailed explination, I suggest you follow linux-hams

    linux-hams apparently hasn't had a message sent to it since March.

    or look into the archives of the URONode support list after
    subscribing to it.

    That's not useful if you want to get something into the kernel.
    Is there really no bug tracking these issues?

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to tenser on Sat Oct 9 12:07:34 2021
    On 09 Oct 2021 at 07:00a, tenser pondered and said...

    On 08 Oct 2021 at 01:29p, N1uro pondered and said...

    Tenser;

    tenser wrote to phigan <=-

    If there are problems with the Linux kernel AX.25 stack, it woul useful to know what they are.

    There's issues with ROSE and ax.25 sockets, NetRom and ax.25 sockets, which are the two most widely used encapsulated networking protocols under ax.25. For a more detailed explination, I suggest you follow linux-hams

    linux-hams apparently hasn't had a message sent to it since March.

    Ah, I'm wrong; Linux-hams is traffic heavy. Looks like a number of patches
    are going across that list.

    Perhaps N1URO could give us a rundown on what, precisely, he sees as
    problems with the Linux AX.25 stack that are NOT being addressed. I've
    seen enough existence proofs of it working just fine to suspect that
    that might be overblown.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to tenser on Sat Oct 9 12:14:47 2021
    On 09 Oct 2021 at 07:07a, tenser pondered and said...

    Ah, I'm wrong; Linux-hams is traffic heavy. Looks like a number of
    patches are going across that list.

    It might also be worth noting that a number of recent (as in, a few
    weeks ago) patches to AX.25 are being merged into the mainline Linux
    kernel. For example, a fix for 6pack was committed on Sep 8.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Fri Oct 8 19:22:00 2021
    Hello tenser;

    tenser wrote to N1uro <=-

    linux-hams apparently hasn't had a message sent to it since March.

    Try:
    https://www.spinics.net/lists/linux-hams/msg04715.html
    Dated 1 October, 2021.

    That's not useful if you want to get something into the kernel.
    Is there really no bug tracking these issues?

    It seems that they're starting to pay attention to the bugs. I don't know
    if there's any official bug tracking on them. If you see the various threads
    on kernel.org they have been a bit more diligent in trying to get these
    things fixed.

    ... Sometimes too much to drink isn't enough.
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/157 to tenser on Sat Oct 9 14:16:00 2021
    Hello tenser;

    tenser wrote to tenser <=-

    Perhaps N1URO could give us a rundown on what, precisely, he sees as problems with the Linux AX.25 stack that are NOT being addressed. I've seen enough existence proofs of it working just fine to suspect that
    that might be overblown.

    There's way to many to mention and it'd be pointless for me to duplicate the data that's already out there. As you saw, there's already a patch for 6-pack and a few for ROSE... but they seem hesitant to fix the most important one which is the NetRom transport's virtual circuit socket NOT closing when finished being in use. YO2LOJ, who's on the URONode dev team, supplied a
    patch for it but they seem so hesitant to accept it for whatever their political reasons are, and most hams don't want to go through having to recompile a kernel.

    ... Def: Dumb Blonde: A peroxymoron
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (432:1/157)
  • From tenser@432:1/100 to N1uro on Tue Oct 12 15:59:55 2021
    On 09 Oct 2021 at 09:16a, N1uro pondered and said...

    Hello tenser;

    tenser wrote to tenser <=-

    Perhaps N1URO could give us a rundown on what, precisely, he sees as problems with the Linux AX.25 stack that are NOT being addressed. I' seen enough existence proofs of it working just fine to suspect that that might be overblown.

    There's way to many to mention and it'd be pointless for me to duplicate the data that's already out there.

    What I see is modification to the stack based on incremental
    updates elsewhere in the kernel. You had said that there were
    two or so outstanding issues that were particularly problematic,
    though in exactly what way or whether they prevented Linux
    kernel AX.25 from working at all was not specified.,

    So I see activity, and my setup works. Hardly proof, but given
    that these issues you referred to don't seem to be tracked
    anywhere and we have empirical evidence that the Linux AX.25
    stack works, and given that your answer to questions about the
    state of things are pretty light on details, one wonders whether
    these things are still problems -- indeed, if they ever were at
    all.

    As you saw, there's already a patch
    for 6-pack and a few for ROSE... but they seem hesitant to fix the most important one which is the NetRom transport's virtual circuit socket NOT closing when finished being in use. YO2LOJ, who's on the URONode dev
    team, supplied a patch for it but they seem so hesitant to accept it for whatever their political reasons are, and most hams don't want to go through having to recompile a kernel.

    Ah, now we're getting somewhere: enough information to locate
    a patch! I see that Marius Petrescu lists patched copies of
    Linux AX.25 for download on his web site, and he describes a
    patch in ax25_subr.c, adding an 'else' at the end of
    `ax25_disconnect`. Immediately obvious is that it does not
    follow Linux kernel style. It's also no immediately clear
    that the patch is correct, but without knowing precisely what
    the problem is in a little more detail, it's hard to tell.
    Again, what's the actual bug here?

    But I can find no record of this patch on the LKML or on
    linux-hams (searching the archives at marc.info) and only
    a few messages from Marius in in 2014 and 2018. Perhaps
    I just haven't looked hard enough, or perhaps it was never
    sent upstream?

    An invariant of contribution to Linux is that someone really
    has to shepherd patches through until they get committed.
    Sometimes the maintainers may ask for modifications to
    patches. That's just how it works, hardly "political"
    reasons.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Tue Oct 12 03:45:00 2021
    Hello tenser;

    tenser wrote to N1uro <=-

    What I see is modification to the stack based on incremental
    updates elsewhere in the kernel. You had said that there were
    two or so outstanding issues that were particularly problematic,
    though in exactly what way or whether they prevented Linux
    kernel AX.25 from working at all was not specified.,

    So I see activity, and my setup works. Hardly proof, but given
    that these issues you referred to don't seem to be tracked
    anywhere and we have empirical evidence that the Linux AX.25
    stack works, and given that your answer to questions about the
    state of things are pretty light on details, one wonders whether
    these things are still problems -- indeed, if they ever were at
    all.

    There's stale socket bugs, critical kernel bugs that can render a box totally useless and other bugs. For me to list these bugs in specific for hams would
    be completely counter productive. Any cracker could then own your license. Basic ones have been discussed in linux-hams and that's enough. If you run something such as LinBPQ or JNOS2 you are not affected because you are NOT using the native linux protocol stack. CVE refuses to post any critical but known bugs with Winlink for the same reasons - it'd be counterproductive.

    Ah, now we're getting somewhere: enough information to locate
    a patch! I see that Marius Petrescu lists patched copies of
    Linux AX.25 for download on his web site, and he describes a
    patch in ax25_subr.c, adding an 'else' at the end of
    `ax25_disconnect`. Immediately obvious is that it does not
    follow Linux kernel style. It's also no immediately clear
    that the patch is correct, but without knowing precisely what
    the problem is in a little more detail, it's hard to tell.
    Again, what's the actual bug here?

    He described it perfectly clear, and it's been discussed on the URONode
    support list. Just because you don't see it or refuse to review the
    threads on the URONode list or elsewhere doesn't mean it does not exist. However considering what you appear to keep yourself blinded to, might I suggest Windows and BPQ32?

    ... My uncle crashed his car into a lemon tree. He's still bitter and twisted. --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to N1uro on Wed Oct 13 06:36:03 2021
    On 11 Oct 2021 at 10:45p, N1uro pondered and said...

    Hello tenser;

    tenser wrote to N1uro <=-

    What I see is modification to the stack based on incremental
    updates elsewhere in the kernel. You had said that there were
    two or so outstanding issues that were particularly problematic, though in exactly what way or whether they prevented Linux
    kernel AX.25 from working at all was not specified.,

    So I see activity, and my setup works. Hardly proof, but given
    that these issues you referred to don't seem to be tracked
    anywhere and we have empirical evidence that the Linux AX.25
    stack works, and given that your answer to questions about the
    state of things are pretty light on details, one wonders whether these things are still problems -- indeed, if they ever were at
    all.

    There's stale socket bugs, critical kernel bugs that can render a box totally useless and other bugs. For me to list these bugs in specific
    for hams would be completely counter productive. Any cracker could then own your license. Basic ones have been discussed in linux-hams and
    that's enough. If you run something such as LinBPQ or JNOS2 you are not affected because you are NOT using the native linux protocol stack. CVE refuses to post any critical but known bugs with Winlink for the same 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.

    He described it perfectly clear, and it's been discussed on the URONode support list. Just because you don't see it or refuse to review the 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.

    However considering what you appear to keep yourself blinded to, might I 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)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Tue Oct 12 18:25:00 2021
    tenser;

    tenser wrote to N1uro <=-

    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.

    Is it your policy in life to call those who develop the things you may use
    a liar? This is the sort of thing that belongs on facebook. Why not show
    a bit of appreciation for the things and be proactive rather than point fingers and say hateful things instead.

    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.

    We -did- submit requests for this to be added to some sort of a bug tracker however the cracks involved are so grave in nature it was decided best not
    to publish them as to protect the licenses of the hams who may be using
    such configurations. A full and total take-over of a system can easily be accomplished if the bugs were published. Is this what you promote in your thinking?

    "Read the archives of my project's mailing list" is not a good
    answer.

    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.

    Your opinion is quite false in nature. What proof do you have of this? URONode and my other projects are quite alive and in the various repositories. What projects do you have? Besides my own projects I also contribute to the LinFBB project. I pulled my projects off sourceforge until such time as the kernel bugs are fixed. I'm simply tired with receiving emails asking me why my stuff "doesn't work" when I have the only node project available that works on old IBM emulation systems! When the critical kernel issues are resolved they'll
    be back on sourceforge as I have upgrades for them all to release.

    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.

    No you obviously did not comprehend the NetRom bug issue at all. When a box boots up as fresh, and no users/robots have used the NetRom stack in said
    box, it will await the 1st connection to which an underlaying ax.25 VIRTUAL CIRCUIT is then created for the NetRom socket to transport through on. That
    1st and only that 1st connection will appear to work and be valid. When the session is completed, the underlaying ax.25 layer stays open thus causing
    the underlaying NetRom socket to be open and available for a remote attacker
    to attach to and own the box. Marius clearly spells this out in his patches
    and unlike a 1 line fix as you claim, it's a 4 line patch to insure that
    the ax.25 virtual circuit gets closed when NetRom is used. Understand now?
    And if axip/axudp is used, this leaves the IP socket open awaiting any outside resource to connect to it.

    In your NetStat you'd see something like:
    N1URO-4 KE6I-10 N1URO-4 nr2 LISTENING 000/000 0 0

    How can an established connection be in listening or waiting for a connect mode? With such an easy way for a non-ham to attach themself to a box perhaps now you may understand why such bugs are NOT published for the whole world
    to search. We take tests for our licenses... not to have some packet kiddie take them from us.

    This is simply one of many that need attention to.

    However considering what you appear to keep yourself blinded to, might I suggest Windows and BPQ32?

    Nah. I'm good.

    *raises a vulcan eyebrow*

    ... MultiMail, the new multi-platform, multi-format offline reader!
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to N1uro on Wed Oct 13 13:00:19 2021
    On 12 Oct 2021 at 01:25p, N1uro pondered and said...

    tenser wrote to N1uro <=-

    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.

    Is it your policy in life to call those who develop the things you may
    use a liar?

    If I ask for some data, and you cannot provide it, then yes,
    I question your veracity. In particular, if this code is being
    maintained and the issue in question isn't being effectively
    tracked, how do you know it hasn't already been fixed? How do
    you know that the people doing the maintenance are even aware?

    This is the sort of thing that belongs on facebook. Why not
    show a bit of appreciation for the things and be proactive rather than point fingers and say hateful things instead.

    I merely asked you for a pointer to a bug repository where these
    issues were being tracked. That's not "hateful". You refused
    to provide any details. Repeated refusals make me wonder if it's
    really a problem.

    You might consider showing some appreciation for people who are
    interested in these things; who knows, they may be able to fix
    some bugs.

    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.

    We -did- submit requests for this to be added to some sort of a bug tracker however the cracks involved are so grave in nature it was
    decided best not to publish them as to protect the licenses of the hams who may be using such configurations. A full and total take-over of a system can easily be accomplished if the bugs were published.

    Sounds like security through obscurity to me. Think of this way:
    what's to prevent a ham from doing this _right now_, since these
    problems are, as you claim, unsolved upstream. How would that ham
    _even know_? By your own admission, this isn't even being tracked
    anywhere. How would they possibly discover the issue?

    Is this what you promote in your thinking?

    A strawman argument wrapped in ad hominem hyperbole.

    "Read the archives of my project's mailing list" is not a good answer.

    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.

    Your opinion is quite false in nature. What proof do you have of this?

    Your own statements that the project is not available on
    sourceforge because of these kernel issues you continue to
    talk about.

    URONode and my other projects are quite alive and in the various repositories. What projects do you have?

    https://github.com/dancrossnyc/

    Besides my own projects I also
    contribute to the LinFBB project.

    That's nice...?

    I pulled my projects off sourceforge
    until such time as the kernel bugs are fixed. I'm simply tired with receiving emails asking me why my stuff "doesn't work" when I have the only node project available that works on old IBM emulation systems!

    This seems to directly contradict your statement above that your
    didn't pull your projects off of sourceforge.

    When the critical kernel issues are resolved they'll be back on sourceforge as I have upgrades for them all to release.

    Cool. What guarantee do we have that you won't yank them again?
    Once you establish a pattern of behavior, users and potential
    users will recognize it for what it is and react accordingly.

    This ham won't be running your code and will be advising others
    not to do so.

    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.

    No you obviously did not comprehend the NetRom bug issue at all.

    Well, obviously not. I've been asking for an explanation like that
    you gave below for what, a week or two now?

    When a
    box boots up as fresh, and no users/robots have used the NetRom stack in said box, it will await the 1st connection to which an underlaying ax.25 VIRTUAL CIRCUIT is then created for the NetRom socket to transport
    through on. That 1st and only that 1st connection will appear to work
    and be valid. When the session is completed, the underlaying ax.25 layer stays open thus causing the underlaying NetRom socket to be open and available for a remote attacker to attach to and own the box.

    Finally, something approaching a usable problem report!

    Marius
    clearly spells this out in his patches and unlike a 1 line fix as you claim, it's a 4 line patch to insure that the ax.25 virtual circuit gets closed when NetRom is used.

    Here's the patch:

    diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c
    290a291,295
    else
    {
    // YO2LOJ: this is needed for proper NETROM connection cleanup on
    timeout
    ax25_destroy_socket(ax25);
    }

    That's one line of executable code in an "else" branch. The other
    three lines are brackets and a comment which is extremely generic.

    No where does any of this "explain" the things that you think it
    does.

    Understand now? And if axip/axudp is used,
    this leaves the IP socket open awaiting any outside resource to connect
    to it.

    ...if you allow axip/axudp to the outside world.

    How can an established connection be in listening or waiting for a
    connect mode? With such an easy way for a non-ham to attach themself to
    a box perhaps now you may understand why such bugs are NOT published for the whole world to search. We take tests for our licenses... not to
    have some packet kiddie take them from us.

    So like I said, this is security through obscurity. Apparently,
    a ham could set this up _today_ and have no idea this is such an
    issue that could cost them their license.

    This is simply one of many that need attention to.

    None of which are tracked. Awesome.

    *raises a vulcan eyebrow*

    Indeed.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Wed Oct 13 05:07:00 2021
    tenser;

    tenser wrote to N1uro <=-

    On 12 Oct 2021 at 01:25p, N1uro pondered and said...

    If I ask for some data, and you cannot provide it, then yes,
    I question your veracity. In particular, if this code is being
    maintained and the issue in question isn't being effectively
    tracked, how do you know it hasn't already been fixed? How do
    you know that the people doing the maintenance are even aware?

    You've asked for data and I've done what I could and beyond to provide it.
    I know who's maintaining the code in question as we email amongst ourselves.
    We all share code. I know some code has been fixed, some yet has been fixed. I'm hoping by year end it'll all be fixed.

    I merely asked you for a pointer to a bug repository where these
    issues were being tracked. That's not "hateful". You refused
    to provide any details. Repeated refusals make me wonder if it's
    really a problem.

    I have not refused answers. Specific details perhaps because of the fact
    that it's not a good idea to let non-hams have information on how to exploit ham boxes. You want these published however to which I can not understand
    for the life of me why. I did point you to a more current archive of linux-hams which you claimed did not exist.

    You might consider showing some appreciation for people who are
    interested in these things; who knows, they may be able to fix
    some bugs.

    If you emailed me privately we could get into more details. In a public echo area is not the place to discuss these things. I do appreciate those who use such things, often it's me that gets the disrepect and frankly I grow tired
    of it.

    Sounds like security through obscurity to me. Think of this way:
    what's to prevent a ham from doing this _right now_, since these
    problems are, as you claim, unsolved upstream. How would that ham
    _even know_? By your own admission, this isn't even being tracked anywhere. How would they possibly discover the issue?

    Publically it's not tracked. Privately yes. Many ham projects are tracked securely via obscurity. Why would I have a reason to say that sockets are
    left open if it's not true? In what way(s) would I gain any benefit either
    way? Zero!

    Your own statements that the project is not available on
    sourceforge because of these kernel issues you continue to
    talk about.

    Those who have used my software for the 20+ years it's been around know
    me and know I would help them out. I don't want any new users at this time
    but will help those who do grab it using apt or dnf to install them with. 95% however when faced with having to compile a kernel or patch a kernel usually will flee back to DOS. I am also in very poor health and don't wish to be bothered by those who aren't willing to take the steps needed. Those who
    do use my software will wait quite patiently for the projects to be reposted with the upgrades in them. I'm not concerned.

    https://github.com/dancrossnyc/

    Ahh now I know who you are. I assigned you your block and maintain your
    ampr DNS. Considering the level of integrity I gave you to get you up and running on 44-net, what reason did I offer you to prove not to believe me? Again, I have nothing to gain either way here.

    Besides my own projects I also
    contribute to the LinFBB project.

    That's nice...?

    You could always also look inside the tickets of LinFBB on the afore mentioned issues. F6BVP and his crew supplied ROSE patches as the URONode crew has supplied NetRom fixes. Others have supplied various fixes to various codes. Some have to do with the ax25 libs some with the kernel protocol stack.
    The ones I personally am most concerned about are the 6-pack and NetRom
    bugs.

    I pulled my projects off sourceforge
    until such time as the kernel bugs are fixed. I'm simply tired with receiving emails asking me why my stuff "doesn't work" when I have the only node project available that works on old IBM emulation systems!

    This seems to directly contradict your statement above that your
    didn't pull your projects off of sourceforge.

    I -said- I pulled them off, however various distros still have the software
    in their repositories.

    Cool. What guarantee do we have that you won't yank them again?
    Once you establish a pattern of behavior, users and potential
    users will recognize it for what it is and react accordingly.

    I have announced that once the issues are fixed they'll be back. My
    core base knows that I'll hold true to my word. Hopefully the stack issues
    once fixed will remain fixed TFN. It seems as if some of these bugs have
    been in existence since the 1990s however just weren't noticed until more recently probably due to compiler instructions I'll guess.

    This ham won't be running your code and will be advising others
    not to do so.

    So you will cause defamation of my code? Under the grounds it does not work
    I presume? While I'm quite happy you will not be running my software, and
    while it's available from various distributions repositories, under what grounds will you be advising people not to use it?

    Well, obviously not. I've been asking for an explanation like that
    you gave below for what, a week or two now?

    I've stated several times, the socket is left open. As you know an open
    unused socket can easily be grabbed onto remotely by an attacker.

    When a
    box boots up as fresh, and no users/robots have used the NetRom stack in said box, it will await the 1st connection to which an underlaying ax.25 VIRTUAL CIRCUIT is then created for the NetRom socket to transport
    through on. That 1st and only that 1st connection will appear to work
    and be valid. When the session is completed, the underlaying ax.25 layer stays open thus causing the underlaying NetRom socket to be open and available for a remote attacker to attach to and own the box.

    Finally, something approaching a usable problem report!

    I've stated this several times.

    Marius
    clearly spells this out in his patches and unlike a 1 line fix as you claim, it's a 4 line patch to insure that the ax.25 virtual circuit gets closed when NetRom is used.

    Here's the patch:

    diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c
    290a291,295
    else
    {
    // YO2LOJ: this is needed for proper NETROM connection cleanup on
    timeout
    ax25_destroy_socket(ax25);
    }

    That's one line of executable code in an "else" branch. The other
    three lines are brackets and a comment which is extremely generic.

    No where does any of this "explain" the things that you think it
    does.

    It's perfectly clear to me that without the above, NetRom "cleanup" or proper socket closure does not occur leaving it in an open state

    Understand now? And if axip/axudp is used,
    this leaves the IP socket open awaiting any outside resource to connect
    to it.

    ...if you allow axip/axudp to the outside world.

    Have you seen most ham boxes? I'd safely say 95% of them do. You're not far from me... the average age of a ham is 70. Most hams I know don't even believe in passwords at all anywhere ham or internet usage! As I said recently to one developer, it's more or less up to us to help secure these guys in our code
    as best we can. While he disagreed with my statement he did end up doing so.

    So like I said, this is security through obscurity. Apparently,
    a ham could set this up _today_ and have no idea this is such an
    issue that could cost them their license.

    Possible, but not quite probable. It added to my decision to pull my
    projects offline since my installer SVNs from SF.net. Many don't know
    my stuff is in the linux repos... which is fine by me. Sometimes obscurity
    is a better way to execute security. Maybe not in all cases but under certain circumstances yes.

    This is simply one of many that need attention to.

    None of which are tracked. Awesome.

    not necessarily publically no... but tracked yes.

    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to N1uro on Thu Oct 14 07:01:48 2021
    On 13 Oct 2021 at 12:07a, N1uro pondered and said...

    tenser;

    tenser wrote to N1uro <=-

    On 12 Oct 2021 at 01:25p, N1uro pondered and said...

    If I ask for some data, and you cannot provide it, then yes,
    I question your veracity. In particular, if this code is being maintained and the issue in question isn't being effectively
    tracked, how do you know it hasn't already been fixed? How do
    you know that the people doing the maintenance are even aware?

    You've asked for data and I've done what I could and beyond to provide
    it. I know who's maintaining the code in question as we email amongst ourselves. We all share code. I know some code has been fixed, some yet has been fixed. I'm hoping by year end it'll all be fixed.

    Actually, no: you said, "go read the linux-hams list and URONode list."
    That's not really any more useful than saying, "there are bugs."

    I merely asked you for a pointer to a bug repository where these issues were being tracked. That's not "hateful". You refused
    to provide any details. Repeated refusals make me wonder if it's really a problem.

    I have not refused answers. Specific details perhaps because of the fact that it's not a good idea to let non-hams have information on how to exploit ham boxes. You want these published however to which I can not understand for the life of me why. I did point you to a more current archive of linux-hams which you claimed did not exist.

    I corrected myself on linux-hams, but this makes no sense: if the
    information isn't "safe" for public disclosure, why point me to a
    public mailing list? If it's on the public mailing list, why make
    such a fuss about it here? You can't have it both ways.

    You might consider showing some appreciation for people who are interested in these things; who knows, they may be able to fix
    some bugs.

    If you emailed me privately we could get into more details. In a public echo area is not the place to discuss these things. I do appreciate
    those who use such things, often it's me that gets the disrepect and frankly I grow tired of it.

    If you had said, "I don't feel comfortable discussing it here, please
    email me" I would have done so. You did not.

    The "disrespect" you get seems earned, frankly.

    Sounds like security through obscurity to me. Think of this way: what's to prevent a ham from doing this _right now_, since these problems are, as you claim, unsolved upstream. How would that ham _even know_? By your own admission, this isn't even being tracked anywhere. How would they possibly discover the issue?

    Publically it's not tracked. Privately yes.

    I don't believe you.

    The last message is the first you mentioned that it's _privately_
    tracked. Given that it seems relevant, I find it odd that you
    haven't mentioned it until now. Given that your initial response
    was to point to a public mailing list, it strikes me as unlikely
    that there's some kind of super-secret "ham in the know" bug
    tracker for AX.25 issues.

    Further, I see no record of YO2LOJ's one-line patch making it to
    the LKML, though you suggested that it was due to "political"
    reasons that that patch hadn't been incorporated upstream. But
    the entire thing begs the question: Was it ever sent?

    Many ham projects are tracked
    securely via obscurity.

    That's not what "securely" means.

    Why would I have a reason to say that sockets are
    left open if it's not true? In what way(s) would I gain any benefit
    either way? Zero!

    Strawman. I never suggested that you "gain" anything or that
    it wasn't true.

    Your own statements that the project is not available on
    sourceforge because of these kernel issues you continue to
    talk about.

    Those who have used my software for the 20+ years it's been around know
    me and know I would help them out. I don't want any new users at this
    time but will help those who do grab it using apt or dnf to install them with. 95% however when faced with having to compile a kernel or patch a kernel usually will flee back to DOS. I am also in very poor health and don't wish to be bothered by those who aren't willing to take the steps needed. Those who do use my software will wait quite patiently for the projects to be reposted with the upgrades in them. I'm not concerned.

    I'm sorry you are in poor health, but I've observed how you
    behave here, on the eastnet mailing list, and on the 44net
    mailing list for several years and I find your ego and constant
    persecution complex too much. It's great that you are not
    concerned that people won't be able to use your software, but
    I find your public projections unpleasant.

    https://github.com/dancrossnyc/

    Ahh now I know who you are. I assigned you your block and maintain your ampr DNS. Considering the level of integrity I gave you to get you up and running on 44-net, what reason did I offer you to prove not to believe
    me? Again, I have nothing to gain either way here.

    Well, perhaps making self-contradictory and objectively false
    statements and then behaving like a spoiled child has something
    to do with it, not to mention your personal behavior.

    Given that you are in such poor health, perhaps you should consider
    stepping down as an AMPRNet coordinator. You can also delegate DNS
    to me so that it's not such a burden for you (or, frankly, me).

    Besides my own projects I also
    contribute to the LinFBB project.

    That's nice...?

    You could always also look inside the tickets of LinFBB on the afore mentioned issues.

    So is it publicly tracked or privately?

    Also, you _could_ have mentioned this before instead of flying off
    the handle.

    F6BVP and his crew supplied ROSE patches as the
    URONode crew has supplied NetRom fixes. Others have supplied various
    fixes to various codes. Some have to do with the ax25 libs some with the kernel protocol stack. The ones I personally am most concerned about are the 6-pack and NetRom bugs.

    Yeah, that's how open-source software works.

    I pulled my projects off sourceforge
    until such time as the kernel bugs are fixed. I'm simply tired with receiving emails asking me why my stuff "doesn't work" when I have th only node project available that works on old IBM emulation systems!

    This seems to directly contradict your statement above that your didn't pull your projects off of sourceforge.

    I -said- I pulled them off, however various distros still have the software in their repositories.

    So hams can install your software and "packet kiddies" can
    own their machines (and their licenses?) today with less effort
    than it takes to find and download your software from Sourceforge.
    Explain to me again how removing your projects from sourceforge
    helps keep anyone secure?

    Cool. What guarantee do we have that you won't yank them again?
    Once you establish a pattern of behavior, users and potential
    users will recognize it for what it is and react accordingly.

    I have announced that once the issues are fixed they'll be back. My
    core base knows that I'll hold true to my word. Hopefully the stack
    issues once fixed will remain fixed TFN. It seems as if some of these
    bugs have been in existence since the 1990s however just weren't noticed

    I suspect that if your "core base" had an alternative they
    would use it. *shrug*

    until more recently probably due to compiler instructions I'll guess.

    Do you have any idea what those words mean?

    This ham won't be running your code and will be advising others
    not to do so.

    So you will cause defamation of my code? Under the grounds it does not work I presume? While I'm quite happy you will not be running my
    software, and while it's available from various distributions repositories, under what grounds will you be advising people not to use it?

    Oh no. Code is easy; I'm sure yours is fine.

    I won't use it because the author behaves poorly.

    Well, obviously not. I've been asking for an explanation like that you gave below for what, a week or two now?

    I've stated several times, the socket is left open. As you know an open unused socket can easily be grabbed onto remotely by an attacker.

    "An unused socket" is just an unused data structure. There is
    nothing inherent about an "unused socket" that makes it so that
    it "can easily be grabbed onto remotely by an attacker."

    In THIS case, you may be right, but that is due to the specifics
    of this particular bug. It was the details particular to this
    specific issue that have been utterly lacking in your descriptions
    but that are critical to understanding, and thus addressing, this
    bug you've been going on about. Just being an "unused socket"
    can mean many things (for instance, it could be a slow resource
    leak, which is otherwise harmless though annoying).

    Getting the details of what precisely was/is wrong, and the effects
    of that bug, are what I've been driving at all this time.

    You seem to believe that that is somehow an affront to you,
    personally. Perhaps you should engage in some self-reflection
    to understand why you react so personally to a technical issue
    that you are only tangentially associated with. Could it be
    that you don't like being questioned because you consider yourself
    the prima facie expert on these matters?

    When a
    box boots up as fresh, and no users/robots have used the NetRom stack said box, it will await the 1st connection to which an underlaying ax VIRTUAL CIRCUIT is then created for the NetRom socket to transport through on. That 1st and only that 1st connection will appear to work and be valid. When the session is completed, the underlaying ax.25 la stays open thus causing the underlaying NetRom socket to be open and available for a remote attacker to attach to and own the box.

    Finally, something approaching a usable problem report!

    I've stated this several times.

    No you haven't. Objectively false statements like this, and your
    aversion to being corrected, are why I doubt you.

    Marius
    clearly spells this out in his patches and unlike a 1 line fix as you claim, it's a 4 line patch to insure that the ax.25 virtual circuit g closed when NetRom is used.

    Here's the patch:

    diff -r net/ax25/ax25_subr.c $HOME/ax25-4.19.0-16/ax25_subr.c 290a291,295
    else
    {
    // YO2LOJ: this is needed for proper NETROM connection cleanup o
    timeout
    ax25_destroy_socket(ax25);
    }

    That's one line of executable code in an "else" branch. The other three lines are brackets and a comment which is extremely generic.

    No where does any of this "explain" the things that you think it does.

    It's perfectly clear to me that without the above, NetRom "cleanup" or proper socket closure does not occur leaving it in an open state

    Er, no. It might just leak a data structure in the kernel.
    Nothing there implies that the socket is left "open"; just
    that the kernel data structure isn't cleaned up.

    Understand now? And if axip/axudp is used,
    this leaves the IP socket open awaiting any outside resource to conne to it.

    ...if you allow axip/axudp to the outside world.

    Have you seen most ham boxes? I'd safely say 95% of them do. You're not far from me... the average age of a ham is 70. Most hams I know don't
    even believe in passwords at all anywhere ham or internet usage! As I
    said recently to one developer, it's more or less up to us to help
    secure these guys in our code as best we can. While he disagreed with my statement he did end up doing so.

    Non-sequitor.

    So like I said, this is security through obscurity. Apparently,
    a ham could set this up _today_ and have no idea this is such an issue that could cost them their license.

    Possible, but not quite probable. It added to my decision to pull my projects offline since my installer SVNs from SF.net. Many don't know
    my stuff is in the linux repos... which is fine by me. Sometimes
    obscurity is a better way to execute security. Maybe not in all cases
    but under certain circumstances yes.

    Nonsense. Most hams installing a Raspberry Pi know little
    more than to try "apt install". You're already in rarified
    air when you talk about people setting up a packet station.

    "Sometimes obscurity is a better way to execute security."
    Except that this is neither obscure nor secure.

    This is simply one of many that need attention to.

    None of which are tracked. Awesome.

    not necessarily publically no... but tracked yes.

    Riiiight.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Wed Oct 13 17:58:00 2021
    tenser;

    tenser wrote to N1uro <=-

    Actually, no: you said, "go read the linux-hams list and URONode list." That's not really any more useful than saying, "there are bugs."

    You asked for bugtracking on software that I neither maintain or own.
    You doubt me, you doubt Marius. In my eyes that displays hatred.
    You've been drilling me on this issue and what the bugs are about to which
    I don't own nor maintain the projects at hand. -My- software itself is fine. There's no known issues with it... but I found the root of the issue that
    you seem to have...

    Well, perhaps making self-contradictory and objectively false
    statements and then behaving like a spoiled child has something
    to do with it, not to mention your personal behavior.

    I haven't made any self-contradictory statements and the word "objectively"
    to describe "false" is opinionated. Simply put: you don't like me - and that's 100% fine. I'm not around to win a popularity contest.

    Given that you are in such poor health, perhaps you should consider stepping down as an AMPRNet coordinator. You can also delegate DNS
    to me so that it's not such a burden for you (or, frankly, me).

    I already have backups however I'm well enough to continue duties and they
    have requested that I stay on. Disliking someone for who they are is not
    any reason to request someone leave.

    I think now that:

    - you admit you dislike me
    - you tried to force me to post that which you feel others should be tracking
    publically
    - you disbelieve me and others... fine

    It's not my software or code that has the issues, thus it's not my responsibility to handle the fixes. Why would you feel it is? The more you pushed, the more I pushed back but tried to lead you to where discussions have taken place. I can only state where those discussions are, it's up to
    you to review them if you so choose however you wish not to believe me on
    the fact that issues exist when you did see indeed there were recent issues addressed on linux-hams.

    So is it publicly tracked or privately?

    LinFBB tickets are public sourceforge tickets.

    Also, you _could_ have mentioned this before instead of flying off
    the handle.

    I not once flew off the handle. This stuff is all a hobby, I don't let it
    get to me.

    Yeah, that's how open-source software works.

    Absolutely.

    So hams can install your software and "packet kiddies" can
    own their machines (and their licenses?) today with less effort
    than it takes to find and download your software from Sourceforge.
    Explain to me again how removing your projects from sourceforge
    helps keep anyone secure?

    Again you're attacking me and my software! It's not my software that has issues. Because of your hatred for who I am you're of a biased opinion.
    I've just made it a tad more difficult to find it. Perhaps I may have made
    a mistake pulling it perhaps not. It's a decision I made and I'll have to
    live with any consequences of said decision... which I really don't feel
    it's that big of a deal. Why not go after those who do have decades long outstanding issues such as shared memory leaks to fix them? (yes I filed
    a report in 1998, well before your 44-net block, and it was ignored).
    Want to talk about ego? Look across the pond. They've taking software I've done, modified it, and never once gave me any credit... yet to now I've
    not even mentioned it. It's the same folks who have the bugs to fix.

    I suspect that if your "core base" had an alternative they
    would use it. *shrug*

    I've actually suggested it, but they enjoy what they have.

    I won't use it because the author behaves poorly.

    That's your choice. I respect and appreciate your opinion. I'm not looking
    to gain users... I never was. I wrote my software for my personal usage
    and my personal usage only. It just so happened that others saw it, asked
    for copies, and it took off from there. Some actually offered ideas which
    I've given then credit for. Some found bugs which I fixed or features that should be changed which I did.

    In THIS case, you may be right, but that is due to the specifics
    of this particular bug. It was the details particular to this
    specific issue that have been utterly lacking in your descriptions
    but that are critical to understanding, and thus addressing, this
    bug you've been going on about. Just being an "unused socket"
    can mean many things (for instance, it could be a slow resource
    leak, which is otherwise harmless though annoying).

    Getting the details of what precisely was/is wrong, and the effects
    of that bug, are what I've been driving at all this time.

    My software aside, these issues, and more, have been sitting idle for some
    time because the maintainers for whatever reasons don't seem to want to acknowledge such bugs nor have a public tracker which suits your desires... however you seem to force this issue on me when it's not my responsibility
    to do so... and that's what I've been saying all this time. Someone has suggested that Ralf Baechle is the current maintainer however I am not positive this is accurate. The issue we've faced for years is that:

    - we report a bug
    - they can't replicate it so it's not to be believed
    - we follow up with traces/logs/etc
    - it's still not believed

    You seem to believe that that is somehow an affront to you,
    personally. Perhaps you should engage in some self-reflection
    to understand why you react so personally to a technical issue
    that you are only tangentially associated with. Could it be
    that you don't like being questioned because you consider yourself
    the prima facie expert on these matters?

    No you have this wrong. I reported that there were bug issues in the stack code. You challenged my integrity. I pointed you to a few places where you could verify my statement. Some places you looked, others you chose not to. That's not on me at all but it appeared you continued to attack my integrity
    on this issue.

    No you haven't. Objectively false statements like this, and your
    aversion to being corrected, are why I doubt you.

    Objectively - self opinion. You've stated you're biased against me... I get it.

    Er, no. It might just leak a data structure in the kernel.
    Nothing there implies that the socket is left "open"; just
    that the kernel data structure isn't cleaned up.

    I showed you what's seen in netstat that the socket is left in a "listening" state.

    Non-sequitor.

    No... but I get you. I just wanted to see you say that you're quite biased against who I am, and you did. I think with that in mind... we're done on this topic now.

    73




    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From tenser@432:1/100 to N1uro on Fri Oct 15 09:33:21 2021
    On 13 Oct 2021 at 12:58p, N1uro pondered and said...

    Actually, no: you said, "go read the linux-hams list and URONode list That's not really any more useful than saying, "there are bugs."

    You asked for bugtracking on software that I neither maintain or own.
    You doubt me, you doubt Marius. In my eyes that displays hatred.

    That's absurd.

    Note also that I never said I doubted Marius.

    You've been drilling me on this issue and what the bugs are about to
    which I don't own nor maintain the projects at hand.

    This ignores the context of this entire thread.

    A self-admitted "rookie" asked for assistance and you started
    talking about bugs in the Linux AX.25 stack. I asked you what
    those bugs were. That somehow seemed to offend you. You've
    been going on and on about how it would be irresponsible for
    those bugs to be publicly tracked, while simultaneously pointing
    at a public mailing list to get information about them, which
    is itself contradictory and makes no sense.

    -My- software itself is fine. There's no known issues with it...

    Sure, fine; whatever. I don't doubt that, though I don't really
    care either.

    But it's curious that you have yanked it from the public sourceforge
    repository due to bugs _outside_ of your software that you now
    claim you have nothing to do with.

    If you have nothing to do with it, then why isn't your stuff publicly available? If you care deeply about problems in Linux being fixed
    before you allow your software in the open again, then why aren't
    you tracking the status of those bugs?

    Perhaps this entire thing could have been avoided if you'd merely
    said, "I'm not tracking those things."

    but I found the root
    of the issue that you seem to have...

    The only issue I have is what I listed above.

    Well, perhaps making self-contradictory and objectively false statements and then behaving like a spoiled child has something
    to do with it, not to mention your personal behavior.

    I haven't made any self-contradictory statements and the word "objectively" to describe "false" is opinionated.

    That's not what objectively means. It means that you've made
    statements that are demonstrably incorrect (like claiming that
    "KA9Q NOS is all over" the BSD and Linux network stacks. A
    claim that is made _in the URONode.his file_. That claim is,
    bluntly, false. You should admit you were in error and correct
    yourself).

    We all make mistakes; hell, I saw archives of the _wrong_
    linux-hams list. But repeated mistakes without acknowledgment
    of correction tend to imply that one's technical judgment is
    suspect. Extraordinary claims require extraordinary evidence;
    if you repeatedly make the claims and do not provide the
    evidence, people will regard the things you say with increasingly
    extreme skepticism: that's now science and engineering work.

    Simply put: you don't
    like me - and that's 100% fine. I'm not around to win a popularity contest.

    I never like nor dislike you: I don't know you. However,
    I think you would be difficult to work with and that you
    are fickle with your software and its availability. You
    appear thin-skinned and incapable of having dispassionate
    disagreements. I find your repeated demands for
    recognition tiresome.

    I already have backups however I'm well enough to continue duties and
    they have requested that I stay on. Disliking someone for who they are
    is not any reason to request someone leave.

    Fair enough.

    I think now that:

    - you admit you dislike me

    As I said above. I do find your legal record disturbing and
    think it is reasonable grounds for not wanting to work with
    you.

    - you tried to force me to post that which you feel others should be tracking publically
    - you disbelieve me and others... fine

    You seem to view these things as somehow personal; my point,
    simply, is that if no one is tracking these problems you've
    pointed out, they may have already been fixed and you wouldn't
    know. I've also observed in you a repeated pattern of making
    specious claims and doubling down when they're shown to be
    false.

    It's not my software or code that has the issues, thus it's not my responsibility to handle the fixes. Why would you feel it is?

    You are correct: it is not your responsibility. However, you
    have yanked public access to your code as a result of the
    existence of these bugs and made public statements about them
    going so far as to allude to some "political" motivation for
    them not being patched. One might reasonably surmise that you
    feel strongly about these problems.

    But when asked what the issues were that you seem to feel so
    strongly about, you were dismissive and evasive.

    If you are so strongly about them, why don't you seem to have
    any useful information about them?
    So hams can install your software and "packet kiddies" can
    own their machines (and their licenses?) today with less effort
    than it takes to find and download your software from Sourceforge. Explain to me again how removing your projects from sourceforge
    helps keep anyone secure?

    Again you're attacking me and my software!

    Not at all. You said you closed access to your sourceforge
    repositories until these issues were fixed upstream in part
    because it was too easy for a ham to accidentally expose
    themselves to a security issue via the way that your otherwise
    correct code interacts with buggy software.

    If you cannot see that distinction, that says a lot more
    about you than it does me.

    It's not my software that has
    issues. Because of your hatred for who I am you're of a biased opinion.

    Get over yourself, man.

    I've just made it a tad more difficult to find it. Perhaps I may have
    made a mistake pulling it perhaps not. It's a decision I made and I'll have to live with any consequences of said decision... which I really don't feel it's that big of a deal. Why not go after those who do have decades long outstanding issues such as shared memory leaks to fix them? (yes I filed a report in 1998, well before your 44-net block, and it
    was ignored). Want to talk about ego? Look across the pond. They've
    taking software I've done, modified it, and never once gave me any credit... yet to now I've not even mentioned it. It's the same folks who have the bugs to fix.

    You can climb on down off that cross any time you want to
    let go of your persecution complex.

    My software aside, these issues, and more, have been sitting idle for
    some time because the maintainers for whatever reasons don't seem to
    want to acknowledge such bugs nor have a public tracker which suits
    your desires... however you seem to force this issue on me when it's
    not my responsibility to do so... and that's what I've been saying all this time. Someone has suggested that Ralf Baechle is the current maintainer however I am not positive this is accurate. The issue we've faced for years is that:

    I'm happy to talk to the maintainers. That was kind of
    my intent when I first inquired. Since I don't care about
    netrom all that much (or anything over AX.25, which is dated
    and inefficient), and the whole experience has been so
    unpleasant, I'm not sure it's worth my time.

    - we report a bug
    - they can't replicate it so it's not to be believed
    - we follow up with traces/logs/etc
    - it's still not believed

    Based on the description you made earlier, it seems like
    this particular bug ought to be easy enough to replicate.
    Did anyone work with them on a test case that could
    reproduce it?

    No you have this wrong. I reported that there were bug issues in the
    stack code. You challenged my integrity. I pointed you to a few places where you could verify my statement.

    No you didn't. You basically said, "go read linux-hams"
    and claimed there's some kind of private bug tracker. I
    can find no record that YO2LOJ's patch was ever sent upstream;
    you've never mentioned whether it was or not.

    Some places you looked, others you
    chose not to. That's not on me at all but it appeared you continued to attack my integrity on this issue.

    See above.

    Objectively - self opinion. You've stated you're biased against me... I get it.

    That's not what objectively means.

    Er, no. It might just leak a data structure in the kernel.
    Nothing there implies that the socket is left "open"; just
    that the kernel data structure isn't cleaned up.

    I showed you what's seen in netstat that the socket is left in a "listening" state.

    Oh goodness: this continues to be circular. You did that _after_
    I asked how the problem manifested itself. In the text you quoted
    above, I was referring to my questions _before_ you did that.

    Goodness.

    No... but I get you. I just wanted to see you say that you're quite
    biased against who I am, and you did. I think with that in mind... we're done on this topic now.

    Interesting that you sent me a long follow-up email.
    Done indeed.

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to tenser on Thu Oct 14 20:02:00 2021
    I'm going to scope this waaaaay down as it's too long.

    tenser wrote to N1uro <=-

    You asked for bugtracking on software that I neither maintain or own.
    You doubt me, you doubt Marius. In my eyes that displays hatred.

    That's absurd.

    Which is absurd? The fact that you said that you don't believe me or that
    by saying such could be considered hatred by the receiving party? Saying that you don't believe someone is one half step away from calling them a flat-out liar which I did not do. I even invited you to fact-check my claims. I make plenty of mistakes so by fact-checking my claims about bugs would have easily put that to rest.

    Note also that I never said I doubted Marius.

    You said something to the effect that you didn't believe me that Marius submitted anything since you did not see it. Perhaps later on you did.

    You've been drilling me on this issue and what the bugs are about to
    which I don't own nor maintain the projects at hand.

    This ignores the context of this entire thread.

    What the initial person asked about maybe, it's gone on too long now.

    A self-admitted "rookie" asked for assistance and you started
    talking about bugs in the Linux AX.25 stack. I asked you what
    those bugs were. That somehow seemed to offend you.

    Not at all. How or what reason would it be to offend me about someone else's bugs? I think what you may have detected in my words were that I did not have
    a complete list of them, and that it's really not my place or position to speak for someone else. That's one problem with ascii text - it loses the emotion behind the words.

    You've
    been going on and on about how it would be irresponsible for
    those bugs to be publicly tracked, while simultaneously pointing
    at a public mailing list to get information about them, which
    is itself contradictory and makes no sense.

    How is it contradictory? HOW to execute an exploit on a ham box should never
    be published. The fact a bug may exist is fine. Maybe I wasn't quite clear in my wordings which would definitely be my fault for doing that. No one knows
    if a bug or patch was done if it's not posted in a mailing list somewhere
    in regards to vanilla ax.25 (which you don't seem to use so you wouldn't know). I see where the confusion is... and it's on both sides.

    But it's curious that you have yanked it from the public sourceforge repository due to bugs _outside_ of your software that you now
    claim you have nothing to do with.

    I said why. I don't think a repeat is necessary.

    If you have nothing to do with it, then why isn't your stuff publicly available? If you care deeply about problems in Linux being fixed
    before you allow your software in the open again, then why aren't
    you tracking the status of those bugs?

    That's what you're not quite clear about. There is no bug tracking software available for the 3rd party software. I do keep tabs on the status of fixes however. Ralf can't confirm any bugs (which is actually typical) but said
    to one of the LinFBB coders that he'd look at the patch from Marius that
    we've all been using that seems to fix the stale socket bug. As long as there is forward motion I'm pleased... however he's seemed to have gone stale on
    the issue to which I'm hoping others will pop on linux-hams and query Ralf
    on this.

    I'm quite grateful you seem pretty concerned about the availability
    of my projects on SourceForge. Rest assured they are back.

    Perhaps this entire thing could have been avoided if you'd merely
    said, "I'm not tracking those things."

    When I said that the software in question I had nothing to do with, that included "I'm not tracking those things". I had thought you had understood that. Why would I track software bugs that aren't mine? Why would you track
    my software bugs if I had them especially since you don't use it? If Ralf
    or anyone else wishes to have their personal bug tracking system available
    to the world, that's up to them and not for me to say.

    The only issue I have is what I listed above.

    I hope I have successfully answered any questions or resolved issues you may have. I'm a bit confused since you don't seem to care about ax.25 why ask
    about it to begin with but that's basically a moot issue at this point.
    (yes that last sentence was rhetorical in nature).

    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Vorlon@432:1/100 to N1uro on Fri Oct 15 17:28:48 2021

    Hello N1uro!

    14 Oct 21 15:02, you wrote to tenser:

    tenser wrote to N1uro <=-
    You asked for bugtracking on software that I neither maintain or
    own. You doubt me, you doubt Marius. In my eyes that displays hatred.

    That's absurd.
    [...]

    I think that this is enough of this public bickering. Please stop.
    It's gone on long enough.

    You both wont see eye to eye, so end it.


    Vorlon


    --- GoldED+/LNX 1.1.5-b20180707
    # Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (21:1/195)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Vorlon@432:1/100 to tenser on Fri Oct 15 17:27:22 2021

    Hello tenser!

    15 Oct 21 04:33, you wrote to N1uro:

    You asked for bugtracking on software that I neither maintain or
    own. You doubt me, you doubt Marius. In my eyes that displays
    hatred.

    That's absurd.
    [...]


    I think that this is enough of the public bickering, please stop. It's gone on long enough.

    You both wont see eye to eye, so end it.



    Vorlon


    --- GoldED+/LNX 1.1.5-b20180707
    # Origin: Dragon's Lair BBS, Telnet: dragon.vk3heg.net (21:1/195)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From MeaTLoTioN@432:1/137 to Avon on Fri Oct 15 11:20:08 2021
    On 07 Oct 2021, Avon said the following...

    On 05 Oct 2021 at 03:33a, phigan pondered and said...
    --- Mystic BBS v1.12 A47 2020/11/22 (OnePlus6T/arm32)

    That's a tearline I don't see very often :)

    Hehehe ahh Avon, you haven't visited the "PiMP" BBS yet have you? (Phone in My Pocket BBS)

    ---
    |14Best regards,
    |11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

    |07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
    |07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

    ... A program is used to turn data into error messages.

    --- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
    * Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (432:1/137)
  • From Avon@432:1/100 to MeaTLoTioN on Sat Oct 16 00:58:41 2021
    On 15 Oct 2021 at 06:20a, MeaTLoTioN pondered and said...

    Hehehe ahh Avon, you haven't visited the "PiMP" BBS yet have you? (Phone in My Pocket BBS)

    Not sure I have but I remember you being very happy at the time of setup :)

    --- Mystic BBS v1.12 A47 2021/09/29 (Linux/64)
    # Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From MeaTLoTioN@432:1/100 to Avon on Fri Oct 15 13:46:26 2021
    On 15 Oct 2021, Avon said the following...

    Not sure I have but I remember you being very happy at the time of setup :)

    Haha I'm always happy =)

    ---
    |14Best regards,
    |11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

    |07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
    |07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

    ... The only place I want data loss is on my credit card!

    --- Mystic BBS v1.12 A47 2021/08/10 (Linux/64)
    # Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (21:1/158)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Vk3jed@432:1/101 to N1uro on Sat Dec 18 01:34:00 2021
    On 07-07-21 19:00, N1uro wrote to Vk3jed <=-

    Vk3jed wrote to N1uro <=-

    Yeah, still have to get around to playing more. :)

    Enjoy! I'm stepping back for a while to focus on trying to beat
    celluitis. Thank the lord I have neuropathy! If not I'd be in an
    excessive amount of pain! Just hoping it doesn't spread into the bloodstream. If it does I'll be SK soon.

    Hope all went well. I've been away for months, had a burnout episode that affected BBSing.


    ... Warranty (n.): See Disclaimer.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (432:1/101)
  • From N1uro@432:1/157 to Vk3jed on Mon Dec 20 02:22:00 2021
    Hello Tony;

    Vk3jed wrote to N1uro <=-

    Hope all went well. I've been away for months, had a burnout episode
    that affected BBSing.

    I've been doing down the tubes at an escalated pace. Suffered a couple heart attacks too - come to find out I'm only working on half my ticker. Trying to stay out of the hospital for the holidays - been in and out of there too much lately. Hope everything is good there for you all down under!

    ... I went to buy some camouflage pants the other day, but I couldn't find any --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (432:1/157)
  • From Vk3jed@432:1/100 to N1uro on Tue Dec 21 00:45:00 2021
    On 12-19-21 20:22, N1uro wrote to Vk3jed <=-

    I've been doing down the tubes at an escalated pace. Suffered a couple heart attacks too - come to find out I'm only working on half my
    ticker. Trying to stay out of the hospital for the holidays - been in
    and out of there too much lately. Hope everything is good there for you all down under!

    Bummer, not good to hear. Physically hasn't been an issue for me. I'm in the best shape of my life, training well, and working towards breaking that elusive 13 second barrier for the 100 metres (13.22 on Saturday, fastest in almost 4 years). :) And 60 for the 400 is looking realistic as well. :)

    ... I went to buy some camouflage pants the other day, but I couldn't
    find any

    Hahaha added to my collection. ;)


    ... Confound these ancestors They've stolen our best ideas!
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    # Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Vk3jed@432:1/100 to N1uro on Tue Dec 21 00:45:00 2021
    On 12-19-21 20:22, N1uro wrote to Vk3jed <=-

    I've been doing down the tubes at an escalated pace. Suffered a couple heart attacks too - come to find out I'm only working on half my
    ticker. Trying to stay out of the hospital for the holidays - been in
    and out of there too much lately. Hope everything is good there for you all down under!

    Bummer, not good to hear. Physically hasn't been an issue for me. I'm in the best shape of my life, training well, and working towards breaking that elusive 13 second barrier for the 100 metres (13.22 on Saturday, fastest in almost 4 years). :) And 60 for the 400 is looking realistic as well. :)

    ... I went to buy some camouflage pants the other day, but I couldn't
    find any

    Hahaha added to my collection. ;)


    ... Confound these ancestors They've stolen our best ideas!
    === MultiMail/Win v0.52

    --- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
    # Origin: Redshift BBS (21:1/109)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/157 to Vk3jed on Fri Dec 24 21:14:00 2021
    Hello Tony;

    Vk3jed wrote to N1uro <=-

    Bummer, not good to hear. Physically hasn't been an issue for me. I'm
    in the best shape of my life, training well, and working towards
    breaking that elusive 13 second barrier for the 100 metres (13.22 on Saturday, fastest in almost 4 years). :) And 60 for the 400 is looking realistic as well. :)

    Considering I'm the oldest living male of my family's generation I suppose
    I'm not doing too bad. We die early. The women on the other hand go into
    their 90's. I guess something can be said for nagging? <G>

    Hahaha added to my collection. ;)

    Steal at will! :)

    ... Eyedropper \I-drop-ur\: a clumsy ophthalmologist.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (432:1/157)
  • From Vk3jed@432:1/100 to N1uro on Sat Dec 25 23:43:00 2021
    On 12-24-21 15:14, N1uro wrote to Vk3jed <=-

    Considering I'm the oldest living male of my family's generation I
    suppose I'm not doing too bad. We die early. The women on the other
    hand go into their 90's. I guess something can be said for nagging? <G>

    Seems mid 80s is the most common longevity in my family, regardless of gender. :)

    Hahaha added to my collection. ;)

    Steal at will! :)

    ... Eyedropper \I-drop-ur\: a clumsy ophthalmologist.

    I did, again! :D


    ... The answer is "maybe" ... and that's semi-final
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    # Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From N1uro@432:1/100 to Vk3jed on Sat Dec 25 22:46:00 2021
    Hello Tony;

    Vk3jed wrote to N1uro <=-

    Seems mid 80s is the most common longevity in my family, regardless of gender. :)

    You're quite lucky. We learned on Christmas morning that an uncle just 5 years my senior passed away this week. I'm counting my days even moreso now.

    I did, again! :D

    Because you forgot to put "Oops" in front of it, Brittney doesn't approve <G>

    ... Buy thermometers in the wintertime. They're much lower then.
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (21:4/107)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)
  • From Vk3jed@432:1/100 to N1uro on Mon Dec 27 03:00:00 2021
    On 12-25-21 16:46, N1uro wrote to Vk3jed <=-

    You're quite lucky. We learned on Christmas morning that an uncle just
    5 years my senior passed away this week. I'm counting my days even
    moreso now.

    Sorry to hear. :(

    I did, again! :D

    Because you forgot to put "Oops" in front of it, Brittney doesn't
    approve <G>

    Haha

    ... Buy thermometers in the wintertime. They're much lower then.

    The market's not as heated. :P


    ... Lymph (v.), to walk with a lisp.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    # Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
    * Origin: Ham Inter-network Echomail Gateway. (432:1/100.0)