TZUTC: -0700
MSGID: 55057.sync@1:103/705 2d5d2f97
REPLY: 51995.dove-syncdisc@12:1/2 2d5ccc5d
PID: Synchronet 3.21a-Linux master/88b423313 Sep 29 2025 GCC 12.2.0
TID: SBBSecho 3.30-Linux master/88b423313 Sep 29 2025 GCC 12.2.0
COLS: 80
BBSID: VERT
CHRS: CP437 2
FORMAT: flowed
NOTE: FSEditor.js v1.105
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)
SEEN-BY: 10/0 1 102/401 103/1 17 705 105/81 106/201 124/5016 128/187
SEEN-BY: 129/14 153/7715 154/110 218/0 1 215 601 610 700 840 860 880
SEEN-BY: 226/30 227/114 229/110 206 317 400 426 428 470 700 705 266/512
SEEN-BY: 280/464 291/111 301/1 320/219 322/757 342/200 396/45 460/58
SEEN-BY: 633/280 712/848 902/26 5075/35
PATH: 103/705 218/700 229/426
|
