Subj : sbbsecho and bad packets To : deon From : Digital Man Date : Mon Oct 20 2025 23:04:54 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. 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 --- SBBSecho 3.30-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .