Re: sbbsecho and bad packets
By: deon to Digital Man on Mon Oct 06 2025 01:07 pm

Re: sbbsecho and bad packets
By: Digital Man to deon on Sun Oct 05 2025 06:09 pm

Looks to me like the DateTime is missing the NUL terminator:
00000040 79 02 79 02 00 00 00 00 30 33 20 4f 63 74 20 32 |y.y.....03 Oct 2| 00000050 35 20 20 30 37 3a 31 37 3a 34 37 20 41 6c 6c 00 |5 07:17:47 All.|

Why is SBBSecho marking them bad?

The sbbsecho.log should say the reason why, but it's probably the same reason.

I didnt think DateTime was a null terminated string? Its 20 Bytes in the packed message header (FTS-0001.16 C.1).

"A packed message has a number of fixed length
fields followed by four null terminated strings."

(those being: to/from/subject and text are null terminated).

Or have a missed something?

FWIW, Tom Jenning's Fido software (specifically, unpmsg() from unpacket.c) would've barfed on any message without a NUL-terminated date/time as well.
https://www.sensitiveresearch.com/Archive/FidoNet/index.html

It would would even trigger a buffer overflow (off-by-one) bug in his code! Just something I came across that was probably related to this discussion.
--
digital man (rob)

Sling Blade quote #5:
Karl Childers (to father): You ought not killed my little brother...
Norco, CA WX: 85.6øF, 18.0% humidity, 4 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: sbbsecho and bad packets
By: Digital Man to deon on Mon Oct 20 2025 03:48 pm

Hey DM,

FWIW, Tom Jenning's Fido software (specifically, unpmsg() from unpacket.c) would've barfed on any message without a NUL-terminated date/time as well. https://www.sensitiveresearch.com/Archive/FidoNet/index.html

It would would even trigger a buffer overflow (off-by-one) bug in his code! Just something I came across that was probably related to this discussion.

Thanks, and interesting.

I still contend that the "standard" doesnt reflect this, which doesnt make sense (at least 2 me) on many levels. <shrug>

(And yes, I think there are probably many other things that are not following any "standards" anymore..)

Not sure what (Randy?) was thinking/intending in 1995. It certainly makes sense that it might be probably easier to code as a null terminated string and at the end of the day the most common representation of a date "yyyy-mm-dd hh:mm:ss" or "dd MMM yy hh:mm:ss" are both 19 chars, so being fixed at 19 chars (to save that byte) may have worked as well. Actually, saving the extra space before the time in the later format would have saved another byte, (or converting it to an unsigned int probably would have saved more). I guess by 1995, 2 bytes in a packet at those modem speeds wasnt a big deal, especially since it was negligble once compressed into a zip/arj file.

Anyway, I think my code handles both in case it pops up in other ways...


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: sbbsecho and bad packets
By: deon to Digital Man on Tue Oct 21 2025 10:52 am

Re: sbbsecho and bad packets
By: Digital Man to deon on Mon Oct 20 2025 03:48 pm

Hey DM,

FWIW, Tom Jenning's Fido software (specifically, unpmsg() from unpacket.c) would've barfed on any message without a NUL-terminated date/time as well. https://www.sensitiveresearch.com/Archive/FidoNet/index.html

It would would even trigger a buffer overflow (off-by-one) bug in his code! Just something I came across that was probably related to this discussion.

Thanks, and interesting.

I still contend that the "standard" doesnt reflect this, which doesnt make sense (at least 2 me) on many levels. <shrug>

The standard (FTS-1) only has that one definition of the DateTime field in packets and it includes the (single) Null byte. So I don't think the requirement of the Null byte has really ever been ambiguous.

Tom's code would always generate the 19-char date followed by the Null byte, but it was a bit more lenient on what it would accept (but again, the Null byte what still a requirement). Whether that leniency on the length of the date/time field was intentional or not, I don't know. But it was documented in FTS-1 years later as a field-length null-terminated field.

(And yes, I think there are probably many other things that are not following any "standards" anymore..)

When it comes to FidoNet, what most matters is interoperability with existing FTN software, much of it abandonware, not what any spec says. We can debate what was meant by whatever spec, but in the end, we just want our messages to go through and there to be some fault-tolerance (e.g. recognize garbage from real messages) if at all possible.

Not sure what (Randy?) was thinking/intending in 1995. It certainly makes sense that it might be probably easier to code as a null terminated string and at the end of the day the most common representation of a date "yyyy-mm-dd hh:mm:ss" or "dd MMM yy hh:mm:ss" are both 19 chars, so being fixed at 19 chars (to save that byte) may have worked as well. Actually, saving the extra space before the time in the later format would have saved another byte, (or converting it to an unsigned int probably would have saved more). I guess by 1995, 2 bytes in a packet at those modem speeds wasnt a big deal, especially since it was negligble once compressed into a zip/arj file.

I think the FTN packet (including packed-message) format is certainly older than 1995. And the unfortumate DateTime format definitely was originated by Tom Jennings (and he has some comments about regretting that format in his source code).

Anyway, I think my code handles both in case it pops up in other ways...

Good. My code assumes the DateTime is always fixed length (and null terminated, though that is a bit illogical) and I don't have any plans to change that. :-)
--
digital man (rob)

Synchronet/BBS Terminology Definition #17:
CR = Carriage Return (ASCII 13, Ctrl-M)
Norco, CA WX: 68.3øF, 49.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: sbbsecho and bad packets
By: Digital Man to deon on Mon Oct 20 2025 11:04 pm

Howdy,

The standard (FTS-1) only has that one definition of the DateTime field in packets and it includes the (single) Null byte. So I don't think the requirement of the Null byte has really ever been ambiguous.

Are we reading different versions of FTS-1?
http://ftsc.org/docs/fts-0001.016

I see a DateTime mentioned in B.1 (the stored message), and in C.1 (the packed message).

I've been referencing to the C.1 reference all along.



...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: sbbsecho and bad packets
By: deon to Digital Man on Tue Oct 21 2025 05:46 pm

Re: sbbsecho and bad packets
By: Digital Man to deon on Mon Oct 20 2025 11:04 pm

Howdy,

The standard (FTS-1) only has that one definition of the DateTime field in packets and it includes the (single) Null byte. So I don't think the requirement of the Null byte has really ever been ambiguous.

Are we reading different versions of FTS-1? http://ftsc.org/docs/fts-0001.016

I see a DateTime mentioned in B.1 (the stored message), and in C.1 (the packed message).

I've been referencing to the C.1 reference all along.

Yeah, me too. But the DateTime *definition* is only in one place in the doc. And that definition includes the Null byte.
--
digital man (rob)

Rush quote #45:
The treasure of a life is a measure of love and respect
Norco, CA WX: 65.9øF, 56.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: sbbsecho and bad packets
By: Digital Man to deon on Mon Oct 20 2025 23:04:54

...we just want our messages to go through and there to be some fault-
tolerance (e.g. recognize garbage from real messages) if at all possible.

Sometimes it's hard to tell one from the other.

---
þ Synchronet þ End Of The Line BBS - endofthelinebbs.com