• Tutorial for rookies

    From x1pepe@21:1/150 to All on Sat Jun 19 09:18:04 2021
    Hi all!
    I would like to start with radio packet with a friend, we dont have tnc
    modems, only a windows sound modem emulated.
    We are a total rookies and we are looking for a tutorial, link, to start
    since zero.
    We have the radios and the wires, but we dont understand how sound modem
    works.
    Also I would like to know how I can access to a BBS throught radio.
    Thanks :)

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From N1uro@21:4/107 to x1pepe on Sat Jun 19 09:35:00 2021
    Hello x1pepe;

    x1pepe wrote to All <=-

    Hi all!
    I would like to start with radio packet with a friend, we dont have tnc modems, only a windows sound modem emulated.
    We are a total rookies and we are looking for a tutorial, link, to
    start since zero.
    We have the radios and the wires, but we dont understand how sound
    modem works.
    Also I would like to know how I can access to a BBS throught radio.
    Thanks :)

    Me personally, I'm not a fan of soundcard based TNCs... I'm of the opinion
    that they emulate the old failed Winmodems of the late 90s, but you'll need
    to look up how to wire your radio to it. You can find great used TNCs for around $25.00USD which is super cheap at flea markets and on eBay.

    To access a bbs like this one, you'll want node software that can act as a gateway for it. My URONode system will let you telnet into your bbs fine.



    ... Good evening! I am Count Dracula! I'd like a suite with a bath!
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From Avon@21:1/101 to N1uro on Sun Jun 20 14:59:20 2021
    On 19 Jun 2021 at 09:35a, N1uro pondered and said...

    To access a bbs like this one, you'll want node software that can act as
    a gateway for it. My URONode system will let you telnet into your bbs fine.

    I've always wanted to hook my BBS up to packet so that someone could send/receive echomail between BBS over RF.

    I've seen some old youtube clips with HAMs seemingly running TCP/IP over RF using the AX.25 protocol and slow baud rates. I figured this would be the
    first thing to have to get sorted before the BBS software could answer telnet calls and/or push PKT message files out over RF for another BBS to receive
    and import... I think??

    --- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From x1pepe@21:1/150 to N1uro on Sun Jun 20 08:55:57 2021
    I was looking like you said for a cheap TNC modem but alls I had found cost around the 300euros :(
    Do you know something cheaper, some link please?

    For the moment only I can to test radio packet on a sounds modems.
    Thanks.

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From x1pepe@21:1/150 to N1uro on Sun Jun 20 08:58:01 2021
    Sorry, where can find de Uron node program?
    Thanks.

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From N1uro@21:4/107 to Avon on Sun Jun 20 08:59:00 2021
    Hello Avon;

    Avon wrote to N1uro <=-

    I've always wanted to hook my BBS up to packet so that someone could send/receive echomail between BBS over RF.

    I've seen some old youtube clips with HAMs seemingly running TCP/IP
    over RF using the AX.25 protocol and slow baud rates. I figured this
    would be the first thing to have to get sorted before the BBS software could answer telnet calls and/or push PKT message files out over RF for another BBS to receive and import... I think??

    My BBS and packet hub are all on one machine and they share the same IPs,
    they just use different ports. When it comes to SMTP mail, *everything*
    is sent via MX records in DNS to my main postfix MTA which runs the mail through spamassassin and ClamSMTP for viri checking before it's final destination. In postfix there's a transport file you can set to redirect
    mail to different ports. To get a message for example from your BBS to my LinFBB packet BBS you'd send it to:
    n1uro%n1uro.#cct.ct.usa.noam@n1uro.ampr.org
    I may have to reset my non-RF mail out from LinFBB as I was forced to do some emergency repairs and had to shut down a node but incoming works fine. I've sent mails from my smartphone through my packet hub to end users to receive
    and they get them all the time.

    Some of our nodes run my axMail-FAX system which is an SMTP plugin for my URONode software. You could send me a message to:
    n1uro@wb2snn.ampr.org and I'll get it as well. Wb2snn by the way is 100%
    RADIO! There is no internet there at all - and it hosts both IPv4 & IPv6.
    If your IPv6 is working that'd be the default IP it'd use.

    My URONode supports incoming telnet via both IPv4 and IPv6 as well. I wrote
    it so that if one is on 44net they do NOT need a password as chances are they're a validated licensed ham. Non 44-net IPv4 and all IPv6 for now the
    user requires a password to login. Instructions are sent at login and at the failure error message.

    Linking my SBBS to my URONode was tricky but I figured it out. I don't
    know about your software but SBBS has a MUD gateway system in it's doors config. I set in a sense a "MUD" to my node's telnet port. Sometimes when
    I'm playing the old DOS door games, if I want to take a break, I may do some packet for a bit before gaming again.

    My node is running a Z80 emulator and so far I have Zork and Eliza loaded.
    I wrote a routine for the Elizabot so the user can opt to have the chat transcript emailed to them :) It's pretty cool. The best thing you can do
    is to get on the amprnet. This opens a lot of doors for you to do different things.

    ... Geometry teaches us to bisex angels.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From N1uro@21:4/107 to x1pepe on Sun Jun 20 09:00:00 2021
    Hello x1pepe;

    x1pepe wrote to N1uro <=-

    Sorry, where can find de Uron node program?
    Thanks.

    You may find it at:
    https://uronode.sf.net
    If you use Fedora or Debian, or a Debian-based system you may find it
    in your repositories.

    ... Verbal agreements frequently lead to verbal disagreements.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From N1uro@21:4/107 to x1pepe on Sun Jun 20 09:04:00 2021
    Hello x1pepe;

    Do you know something cheaper, some link please?

    https://www.ebay.com/itm/133792697662?hash=item1f26aa8d3e:g:KbUAAOSwtwhgpVuT
    He has 2 for sale but the condition is unknown. These are good TNCs if you
    wish to run specific firmwares such as SMACK, 6-pack, or even X1J-4

    ... Zonker Harris *HAS* to be related to Al Gore.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From x1pepe@21:1/150 to N1uro on Sun Jun 20 16:23:25 2021
    Thanks N1uro I will take a look :)

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From N1uro@21:4/107 to x1pepe on Sun Jun 20 18:32:00 2021
    x1pepe;

    x1pepe wrote to N1uro <=-

    Thanks N1uro I will take a look :)

    You're quite welcome. Most issues have been directly related to either kernel or ax25-apps/tools bugs. The node itself has been quite solid.

    ... Musicians do it with feeling.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From Vk3jed@21:1/109 to Avon on Mon Jun 21 20:31:00 2021
    On 06-20-21 14:59, Avon wrote to N1uro <=-

    On 19 Jun 2021 at 09:35a, N1uro pondered and said...

    I've seen some old youtube clips with HAMs seemingly running TCP/IP
    over RF using the AX.25 protocol and slow baud rates. I figured this
    would be the first thing to have to get sorted before the BBS software could answer telnet calls and/or push PKT message files out over RF for another BBS to receive and import... I think??

    I used to run IP over AX.25 back in 1991, so you weren't imagining it. :)


    ... - BBSing: Files, folks and fun.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From N1uro@21:4/107 to Vk3jed on Tue Jun 22 08:49:00 2021
    Greetings OMS;

    Vk3jed wrote to Avon <=-

    I used to run IP over AX.25 back in 1991, so you weren't imagining it.
    :)

    I still do... but for the past few years it's IPv4 & IPv6! Try to telnet
    to wb2snn.ampr.org on port 3694 and use either IPv4 or IPv6. There's no
    wired or wifi internet there.

    ... I have kleptomania but when it gets bad I take something for it.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From Vk3jed@21:1/109 to N1uro on Tue Jul 6 11:57:00 2021
    On 06-22-21 08:49, N1uro wrote to Vk3jed <=-

    Greetings OMS;

    Vk3jed wrote to Avon <=-

    I used to run IP over AX.25 back in 1991, so you weren't imagining it.
    :)

    I still do... but for the past few years it's IPv4 & IPv6! Try to
    telnet to wb2snn.ampr.org on port 3694 and use either IPv4 or IPv6. There's no wired or wifi internet there.

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


    ... My install is probably 3-4 Weeks Old; It's Time for an Update. P. F.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From N1uro@21:4/107 to Vk3jed on Wed Jul 7 19:00:00 2021
    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.

    ... What is mind? No matter! What is matter? Never mind! - Homer S.
    --- MultiMail/Linux v0.49
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From x1pepe@21:1/150 to N1uro on Sat Jul 10 14:33:04 2021
    I bought a TNC MODEM (DG3 TNC PLUS) by Telegram group, only for 50e.
    :)

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From N1uro@21:4/107 to x1pepe on Tue Jul 13 08:15:00 2021
    Hello x1pepe

    x1pepe wrote to N1uro <=-

    I bought a TNC MODEM (DG3 TNC PLUS) by Telegram group, only for 50e.
    :)

    I'm not familiar with that make/model. I've had great luck with PacComm
    Tiny II's. You can find them around $50USD on eBay. I also have great luck
    with Symek TNC3S. It's a shame Ulf shut things down. They have a flash eprom
    so changing firmware is very simple... and they're dual port TNCs. I have 2
    of them:
    One is 1200/1200 and one is 1200/9600.
    They can run a multitude of firmwares including (3)Net (Xnet). On EastNet
    it was the fastest TNC on the entire network with RTTL pings of 5ms!

    ... Old hackers never die, they just go to bits.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From Vk3jed@21:1/109 to N1uro on Wed Jul 14 18:26: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.

    Good luck, hope it works out OK. I've been a bit quiet on here, on a down cycle for BBSing, but I'm sure it'll come back. Currently, ham radio (especially M17 and RoIP), ans sport are the main focus ATM. :)


    ... Spiders are high in protein, but they tickle.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (21:1/109)
  • From N1uro@21:4/107 to Vk3jed on Wed Jul 14 12:01:00 2021
    Hello Vk3jed;

    Vk3jed wrote to N1uro <=-

    Good luck, hope it works out OK. I've been a bit quiet on here, on a
    down cycle for BBSing, but I'm sure it'll come back. Currently, ham
    radio (especially M17 and RoIP), ans sport are the main focus ATM. :)

    It's going to take it a LONG time to heal. The infection is still there
    and very visible now. Only have a couple layers of skin under my foot but
    it is healing according to my pcp.

    ... Spiders are high in protein, but they tickle.

    So does corn <G>

    ... Artery - The study of paintings
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From x1pepe@21:1/150 to N1uro on Thu Aug 12 07:38:20 2021
    Thanks for your tips!
    There it's a new world to me, a new concepts, ... and still I am learning how it is work.
    Actually I don't have much time, to my hobbies, but I am testing with some wires (home self) to comunicate both TNC MODE and computer.

    telnet sotanomsxbbs.org:23
    *The last Msx user in Ibiza*

    --- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
    * Origin: Sotano Msx BBS (21:1/150)
  • From N1uro@21:4/107 to x1pepe on Thu Aug 12 13:26:00 2021
    Hello x1pepe;

    x1pepe wrote to N1uro <=-

    Thanks for your tips!
    There it's a new world to me, a new concepts, ... and still I am
    learning how it is work.
    Actually I don't have much time, to my hobbies, but I am testing with
    some wires (home self) to comunicate both TNC MODE and computer.

    Good luck with your experiments! Hopefully you'll have a good stretch of time where you can focus on them and learn good.

    ... The number you have dailed...Nine-one-one...has been changed.
    --- MultiMail/Linux v0.49
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From N1uro@21:1/143 to Vk3jed on Thu Aug 26 10:34:00 2021
    Hey Tony;

    Vk3jed wrote to N1uro <=-

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

    As long as you don't hear those words from the YL it's all good <G>

    ... Terminal Illness - Getting sick at the airport
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From N1uro@21:1/143 to x1pepe on Thu Aug 26 10:37:00 2021
    Hello x1pepe;

    x1pepe wrote to N1uro <=-

    I bought a TNC MODEM (DG3 TNC PLUS) by Telegram group, only for 50e.
    :)

    I'm not familiar with those units. I have several makes from various manufacturers. MFJ and PacComms are pretty flexible IF you have access
    to different eproms... which I can burn them. If you can find a Symek
    TNC2 or TNC3, those have flash-proms! Nice for trying out various softwares. They're also very quick!

    ... "Are we clinging tenatiously to my buttocks?"- Powdered Toast Man
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From N1uro@21:1/143 to x1pepe on Thu Aug 26 10:37:00 2021
    Hello x1pepe;

    x1pepe wrote to N1uro <=-

    Thanks for your tips!
    There it's a new world to me, a new concepts, ... and still I am
    learning how it is work.
    Actually I don't have much time, to my hobbies, but I am testing with
    some wires (home self) to comunicate both TNC MODE and computer.

    You're quite welcome. I have more tips/tricks on my website: https://uronode.n1uro.com/linux/

    ... Run out of recipes: (A)bort (R)eread (S)teal
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From N1uro@21:1/143 to Vk3jed on Thu Aug 26 10:41:00 2021
    Hello Tony;

    Vk3jed wrote to N1uro <=-

    Good luck, hope it works out OK. I've been a bit quiet on here, on a
    down cycle for BBSing, but I'm sure it'll come back. Currently, ham
    radio (especially M17 and RoIP), ans sport are the main focus ATM. :)

    Still fighting the infection! Got the swelling in my leg and foot down but
    just this one little strip won't heal! It's under the foot behind my big
    toe!

    ... Elves do it in the trees.
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From phigan@21:1/101 to x1pepe on Wed Sep 22 01:06:38 2021
    Do you know something cheaper, some link please?

    It's not super cheap, and only a KISS TNC, but I really like the one from http://mobilinkd.com . I have their first bluetooth TNC as well as the newer TNC3 that does both bluetooth and USB. I have used it with ax.25 to connect
    to two local packet systems/gateways and also regularly use it for APRS.

    --- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From phigan@21:1/101 to N1uro on Wed Sep 22 01:27:14 2021
    https://uronode.sf.net

    It's weird that your message is not that old but that URL gives 404 now.

    --- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From N1uro@21:4/107 to phigan on Wed Sep 22 08:43:00 2021
    Hello philgan;

    phigan wrote to N1uro <=-

    https://uronode.sf.net

    It's weird that your message is not that old but that URL gives 404
    now.

    There's ax.25 stack issues in the linux kernel and most guys are blaming me
    for it when I don't maintain the stack in the kernel, someone else does so until the fix it, that link has been pulled.

    ... He does the work of 3 Men...Moe, Larry & Curly
    --- MultiMail/Linux v0.49
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From N1uro@21:1/143 to phigan on Tue Sep 28 19:43:00 2021
    Hello phigan

    phigan wrote to N1uro <=-

    https://uronode.sf.net

    It's weird that your message is not that old but that URL gives 404
    now.

    It's not at all weird. The kernel maintainers broke the ax.25 stack in the kernel and refuse to fix it. We've even provided them the fix for it, but because so many believe that the protocol stack is maintained by URONode,
    I've pulled the project until those responsible for breaking the protocol
    stack fixes it.

    ... No filter in the coffee maker
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From Don Epi@21:4/167 to N1uro on Wed Sep 29 09:16:09 2021
    It's not at all weird. The kernel maintainers broke the ax.25 stack in
    the kernel and refuse to fix it. We've even provided them the fix for
    it, but because so many believe that the protocol stack is maintained by URONode, I've pulled the project until those responsible for breaking
    the protocol stack fixes it.

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

    Thanks!! I mean another software or something like that.

    |05//thevaultbbs.ddns.net:2323//Easy and clean board//
    |03--._._.-_.-Epimundo in Text Mode HQ!-._-._._.--


    --- Mystic BBS v1.12 A46 2020/05/26 (Windows/64)
    * Origin: The Vault BBS (21:4/167)
  • From tenser@21:1/101 to Don Epi on Thu Sep 30 06:59:38 2021
    On 29 Sep 2021 at 09:16a, Don Epi pondered and said...

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

    You mean a userspace AX.25 implementation? That may be possible.
    It'd be instructive to see what, precisely, is wrong with it;
    perhaps a few folks can prod a maintainer somewhere.

    --- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From tenser@21:1/101 to tenser on Thu Sep 30 07:00:53 2021
    On 30 Sep 2021 at 06:59a, tenser pondered and said...

    On 29 Sep 2021 at 09:16a, Don Epi pondered and said...

    Ohh... And isnt there a chance to use another decoder other than the Kernel one? Im not a Linux user, thats why I asked this silly questio :)

    You mean a userspace AX.25 implementation? That may be possible.
    It'd be instructive to see what, precisely, is wrong with it;

    "It" in this base being the Linux kernel AX.25 implementation.

    perhaps a few folks can prod a maintainer somewhere.

    Meaning kernel maintainers.

    --- Mystic BBS v1.12 A47 2021/09/24 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From N1uro@21:1/143 to Don Epi on Thu Sep 30 00:22:00 2021
    Hello Don;

    Don Epi wrote to N1uro <=-

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

    Thanks!! I mean another software or something like that.


    There are others out there but you won't get the routing or switching
    speeds as you do from the native kernel. That's one of the benefits of using it. There's older versions you may use however I wouldn't recommend putting then on the internet.

    ... My plan to develop a novelty doorbell has just got fun ding
    --- MultiMail/Linux v0.52
    # Origin: Carnage - risen from the dead now on SBBS (432:1/157)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From phigan@21:1/158.6 to Don Epi on Tue Oct 5 03: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)
  • From Avon@21:1/101 to phigan on Thu Oct 7 11: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)
  • From tenser@21:1/101 to phigan on Fri Oct 8 06: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)
  • From N1uro@21:1/143 to tenser on Fri Oct 8 13: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From tenser@21:1/101 to N1uro on Sat Oct 9 07: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)
  • From tenser@21:1/101 to tenser on Sat Oct 9 07: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)
  • From tenser@21:1/101 to tenser on Sat Oct 9 07: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)
  • From N1uro@21:4/107 to tenser on Fri Oct 8 14: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)
  • From N1uro@21:1/143 to tenser on Sat Oct 9 09: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From tenser@21:1/101 to N1uro on Tue Oct 12 10: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)
  • From N1uro@21:4/107 to tenser on Mon Oct 11 22: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)
  • From tenser@21:1/101 to N1uro on Wed Oct 13 01: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)
  • From N1uro@21:4/107 to tenser on Tue Oct 12 13: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)
  • From tenser@21:1/101 to N1uro on Wed Oct 13 08: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)
  • From N1uro@21:4/107 to tenser on Wed Oct 13 00: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)
  • From N1uro@21:4/107 to tenser on Wed Oct 13 00: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)
  • From tenser@21:1/101 to N1uro on Thu Oct 14 02: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)
  • From N1uro@21:4/107 to tenser on Wed Oct 13 12: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)
  • From tenser@21:1/101 to N1uro on Fri Oct 15 04: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)
  • From N1uro@21:4/107 to tenser on Thu Oct 14 15: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)
  • From Vorlon@21:1/195 to N1uro on Fri Oct 15 12: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)
  • From Vorlon@21:1/195 to tenser on Fri Oct 15 12: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)
  • From MeaTLoTioN@21:1/143 to Avon on Fri Oct 15 06: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From Avon@21:1/101 to MeaTLoTioN on Fri Oct 15 19: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)
  • From MeaTLoTioN@21:1/158 to Avon on Fri Oct 15 08: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)
  • From Vk3jed@21:1/143 to N1uro on Fri Dec 17 19: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From N1uro@21:1/143 to Vk3jed on Sun Dec 19 20: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From Vk3jed@21:1/109 to N1uro on Mon Dec 20 18: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)
  • From Avon@21:1/101 to N1uro on Tue Dec 21 16:16:13 2021
    On 19 Dec 2021 at 08:22p, N1uro pondered and said...

    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!

    Sorry to hear of this, I hope you can rest up and do feel better in the weeks to come. Best wishes from over here in NZ.

    --- Mystic BBS v1.12 A47 2021/11/06 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Vk3jed@21:1/109 to N1uro on Mon Dec 20 18: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)
  • From N1uro@21:4/107 to Avon on Fri Dec 24 15:11:00 2021
    Hello Avon;

    Avon wrote to N1uro <=-

    Sorry to hear of this, I hope you can rest up and do feel better in the weeks to come. Best wishes from over here in NZ.

    Thanks for the wishes... and Merry Christmas to you and yours! The more I
    try to rest up, the more people lean on me for things. While it's nice to
    be wanted... it's not so nice while on the brink of losing my driving foot
    and in dire need of heart surgery. I've had a series of heart attacks already. I just hope if I have anymore that it does not affect others such as while
    I'm driving!

    ... No matter how much you push the envelope, it'll still be stationery.
    --- MultiMail/Linux v0.52
    * Origin: Carnage - risen from the dead now on SBBS (21:4/107)
  • From N1uro@21:1/143 to Vk3jed on Fri Dec 24 15: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)
    * Origin: Ham Inter-network Echomail Gateway. (21:1/143.0)
  • From Vk3jed@21:1/109 to N1uro on Sat Dec 25 17: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)
  • From N1uro@21:4/107 to Vk3jed on Sat Dec 25 16: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)
  • From Vk3jed@21:1/109 to N1uro on Sun Dec 26 21: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)