Just making sure that it hits my various networks properly.
Hey all,
Just been converting my board over to my self-rolled BBS software now that it seems ready.
Just making sure that it hits my various networks properly.
Just making sure that it hitsmy various networks properly.
Appears to have hit Agency.
Interesting. I'll have to investigate if that has anything to do
with how I have my tosser written or not. Let me know if you see
this reply (and if the reply_id) seems to populate correctly.
I've been testing against Synchronet primarily and want to make sure
I don't have anything in place that prevents Mystic or other major
software from passing things along.
> Doesn't look like the original message ever made it over here on my node on
> 3 but I recieved the replies.
Interesting. I'll have to investigate if that has anything to do with how I have my tosser written or not. Let me know if you see this reply (and if the reply_id) seems to populate correctly.
--- Canectic BBS v0.9.5a
* Origin: The Undermine 21:4/103
Seems to look fine from here (a Synchronet system none-the-less). I believe Hub 3 is a bit overly finicky and if it doesn't like a message (or possibly even a different message in that packet/bundle was bad, but this isn't confirmed), it will outright delete the message (or entire packet/bundle) and not send it on to it's downlinks.
Clrghouz should have fallen back to the msgid, which does have your AKA, so I might need to double check that.
[...I looked...]
Actually, I cant see your original message coming to Hub 3 at all...
> The origin line is not parsing, because your AKA isnt in parenthesis.
Well that was another latent bug. No idea when the parenthesis string concat got supressed, but should be working again now.
--- Canectic BBS v0.9.5a
* Origin: The Undermine 21:4/103
I've replied about this message already. (I'm not sure that the
offending message made it to hub 3, but I havent looked in great
depth).
But just as a correction - while in the past, if the packet with
more than 1 message had a bad packed message in it (it seems to be
mostly from mystic systems), it wouldnt process the remaining
messages - that is not so true anymore.
We won't even get into how many pieces of different FTN software
I've discovered do something different than spec that have needed
special catch and handle cases
So your messages werent processed by hub 3 because the from AKA in
message couldnt be determined.
On Wed, Apr 08 2026 21:03:10 -0500, you wrote:
So your messages werent processed by hub 3 because the from AKA in
message couldnt be determined.
With that said, there was no way of your system contacting his to let him know it wasn't processed, either?
That said, I do send a netmail to the person who gave me the packet
with the offending messages - in this case it was Hub 4. In theory,
if all hubs validated messages before processing them, then the
uploader of the packet would be notified immediately - sadly that's
not done and some tossers happily pass on technically bad messages.
Had you been the only hub, no one else would have seen it, nor would it have been mentioned that a few people never received the original.
> FWIW, this message it wasnt :|
Gah! Found and condensed one other divergent piece of tossing logic (should all be condensed now), that could have been getting hit under some circumstances.
> It still has bad kludges though.
What kludges are you having trouble with so I can look into them?
Synchronet and Mystic both seem to be decoding them.
No. You've only mentioned the address in the origin lacking
parenthesis previously. I appreciate help in testing, but simply
posting the spec is far less helpful if you don't report what's
being seen on receipt. Obviously the spec was referenced during
design.
They should be delimited by a space after the colon, ie: ": ".
While you're correct that they SHOULD have a space after the colon
and if they do not I need to investigate what's stripping it during
the outbound process, that should never impede decoding on receive
as it IS NOT the ": " that should be taken as delineation. ^A
delineates kludges as per spec. The space after the colon is only
ever mentioned as a "Should" (best practice), and only during
reference to MSGID.
previously. I appreciate help in testing, but simply posting the spec is far less helpful if you don't report what's being seen on receipt. Obviously the spec was referenced during design.
> They should be delimited by a space after the colon, ie: ": ".
While you're correct that they SHOULD have a space after the colon and if they do not I need to investigate what's stripping it during the outbound process, that should never impede decoding on receive as it IS NOT the ": " that should be taken as delineation.
For what it's worth, I don't see a TZUTC kludge here on my Synchronet system. Maybe it's just being eliminated upon receipt? Either that, or
Lastly, I see your MSGID here as:
21:4/103 19d78e0cbb4
Am I wrong in assuming (from memory) the second field should only be an 8 character string?
@MSGID:21:4/103 19d7689c620
@REPLY:8017.fsx_tst@21:2/116 2e3db52b
@TID:Canectic Tosser v0.1
@TZUTC:-0600
It still has bad kludges though.What kludges are you having trouble with so I can look into them? Synchronet and Mystic both seem to be decoding them.
2) I don't see any good reason why any kind of modern string comparison that needs to strip those spaces anyways would fail to parse because of their absence. So if something is failing due to the absence of the space, that might be reason and opportunity to check if anything else is failing to parse as desired.
So if something is failing due to the absence of the space, that might be reason and opportunity to check if anything else is failing to parse as desired.
No disagreement at all here, and I did immediately agree that the lack of space after the colon was a regression I needed to chase down. My point was just that I'd be concerned if that was causing a system to drop or lose messages, and it would also be worth investigating.
No disagreement at all here, and I did immediately agree that the
lack of space after the colon was a regression I needed to chase
down. My point was just that I'd be concerned if that was causing a
system to drop or lose messages, and it would also be worth
investigating.
Spot on there, too. There seems to have been more than a few long
fixed bugs that came back after I condensed my two message storage
systems to one. Frustrating, but part of life, I suppose.
| Sysop: | John Richards |
|---|---|
| Location: | Escatawpa, MS |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 493529:49:47 |
| Calls: | 5 |
| Files: | 46 |
| U/L today: |
2 files (59K bytes) |
| D/L today: |
12 files (16,621K bytes) |
| Messages: | 4,282 |