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 :)
--- Mystic BBS v1.12 A47 2020/11/22 (OnePlus6T/arm32)
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.
tenser wrote to phigan <=-
If there are problems with the Linux kernel AX.25 stack, it would be useful to know what they are.
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.
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.
tenser wrote to N1uro <=-
linux-hams apparently hasn't had a message sent to it since March.
That's not useful if you want to get something into the kernel.
Is there really no bug tracking these issues?
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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.
elsetimeout
{
// YO2LOJ: this is needed for proper NETROM connection cleanup on
ax25_destroy_socket(ax25);
}
Understand now? And if axip/axudp is used,
this leaves the IP socket open awaiting any outside resource to connect
to it.
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.
*raises a vulcan eyebrow*
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?
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.
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?
Your own statements that the project is not available on
sourceforge because of these kernel issues you continue to
talk about.
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.
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.
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!
Mariustimeout
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
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.
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.
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 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.
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 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.
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,295timeout
else
{
// YO2LOJ: this is needed for proper NETROM connection cleanup o
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 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.
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.
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."
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).
So is it publicly tracked or privately?
Also, you _could_ have mentioned this before instead of flying off
the handle.
Yeah, that's how open-source software works.
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?
I suspect that if your "core base" had an alternative they
would use it. *shrug*
I won't use it because the author behaves poorly.
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?
No you haven't. Objectively false statements like this, and your
aversion to being corrected, are why I doubt you.
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.
Non-sequitor.
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.
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?
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.
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
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.
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.
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.
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.
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.
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."
The only issue I have is what I listed above.
[...]tenser wrote to N1uro <=-own. You doubt me, you doubt Marius. In my eyes that displays hatred.
You asked for bugtracking on software that I neither maintain or
That's absurd.
[...]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.
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)
Not sure I have but I remember you being very happy at the time of setup :)
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.
Vk3jed wrote to N1uro <=-
Hope all went well. I've been away for months, had a burnout episode
that affected BBSing.
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!
... I went to buy some camouflage pants the other day, but I couldn't
find any
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!
... I went to buy some camouflage pants the other day, but I couldn't
find any
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. :)
Hahaha added to my collection. ;)
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>
Hahaha added to my collection. ;)
Steal at will! :)
... Eyedropper \I-drop-ur\: a clumsy ophthalmologist.
Vk3jed wrote to N1uro <=-
Seems mid 80s is the most common longevity in my family, regardless of gender. :)
I did, again! :D
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.
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.
| Sysop: | Chris Crash |
|---|---|
| Location: | Huntington Beach, CA. |
| Users: | 577 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 61:28:27 |
| Calls: | 10,734 |
| Calls today: | 1 |
| Files: | 5 |
| Messages: | 442,632 |