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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)