Hey DM,

Since updating a few days ago, I've now got a bunch of bad packet in my inbound, and all have been marked bad "msg-hdr".

pktdump rev 1.18 - Dump FidoNet Packets

Opening df43a202.msg-hdr.bad
df43a202.msg-hdr.bad Packet Type 2e (prod: 10FF, rev: 1.9) from 3:633/280 to 3:633/509
df43a202.msg-hdr.bad 00003A Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 000658 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 000B83 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 001273 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 001FAC Corrupted Message Header (DateTime) root@alterant:/opt/sbbs/fido/inbound# pktdump df74da02.msg-hdr.bad
pktdump rev 1.18 - Dump FidoNet Packets

Opening df74da02.msg-hdr.bad
df74da02.msg-hdr.bad Packet Type 2e (prod: 10FF, rev: 1.9) from 3:633/280 to 3:633/509
df74da02.msg-hdr.bad 00003A Corrupted Message Header (DateTime)

When I look at a few, it looks like SBBSecho (and pktdump) thinks they are bad because of DateTime, but they look ok to me:

Here's one:

00000000 18 01 fd 01 e9 07 09 00 03 00 11 00 00 00 02 00 |................| 00000010 00 00 02 00 79 02 79 02 ff 01 00 00 00 00 00 00 |....y.y.........| 00000020 00 00 03 00 03 00 00 00 00 01 10 09 01 00 03 00 |................| 00000030 03 00 00 00 00 00 00 00 00 00 02 00 18 01 fd 01 |................| 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.| 00000060 54 68 65 20 4e 61 74 75 72 61 6c 20 50 68 69 6c |The Natural Phil|

Why is SBBSecho marking them bad?

I compiled on the 3rd - using git hash master/b7d3db6c3


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

Hey DM,

Since updating a few days ago, I've now got a bunch of bad packet in my inbound, and all have been marked bad "msg-hdr".

pktdump rev 1.18 - Dump FidoNet Packets

Opening df43a202.msg-hdr.bad
df43a202.msg-hdr.bad Packet Type 2e (prod: 10FF, rev: 1.9) from 3:633/280 to 3:633/509
df43a202.msg-hdr.bad 00003A Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 000658 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 000B83 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 001273 Corrupted Message Header (DateTime) df43a202.msg-hdr.bad 001FAC Corrupted Message Header (DateTime) root@alterant:/opt/sbbs/fido/inbound# pktdump df74da02.msg-hdr.bad
pktdump rev 1.18 - Dump FidoNet Packets

Opening df74da02.msg-hdr.bad
df74da02.msg-hdr.bad Packet Type 2e (prod: 10FF, rev: 1.9) from 3:633/280 to 3:633/509
df74da02.msg-hdr.bad 00003A Corrupted Message Header (DateTime)

When I look at a few, it looks like SBBSecho (and pktdump) thinks they are bad because of DateTime, but they look ok to me:

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. --
digital man (rob)

Rush quote #42:
Media messiahs preying on my fears, pop culture prophets playing in my ears Norco, CA WX: 72.7øF, 63.0% humidity, 12 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.30-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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?


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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?

DateTime is defined as follows in FTS-1:

DateTime = (* a character string 20 characters long *)
(* 01 Jan 86 02:34:56 *)
DayOfMonth " " Month " " Year " "
" " HH ":" MM ":" SS
Null

The "Null" is explicit there. These FidoNet specs are pretty terrible, but FTS-1 is one of the better ones. :-)
--
digital man (rob)

Synchronet/BBS Terminology Definition #97:
XPDEV = Cross-platform Development
Norco, CA WX: 59.4øF, 88.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)

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

I didnt think DateTime was a null terminated string? Its 20 Bytes in the

Howdy,

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?

DateTime is defined as follows in FTS-1:

DateTime = (* a character string 20 characters long *)
(* 01 Jan 86 02:34:56 *)
DayOfMonth " " Month " " Year " "
" " HH ":" MM ":" SS
Null

The "Null" is explicit there. These FidoNet specs are pretty terrible, but FTS-1 is one of the better ones. :-)

I think we quoted the same document. Except you quoted the "a Stored Message" ("as it is the layer that the user's application sees as opposed to what FidoNet sees".) section, and I quoted the "Packed Message" ("As this is a data structure which is actually transferred, its definition is critical to FidoNet") section.

Anyway, does that mean SBBSecho will only accept packets if the datatime field is encoded as a null terminated string?


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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

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

I didnt think DateTime was a null terminated string? Its 20 Bytes in the

Howdy,

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?

DateTime is defined as follows in FTS-1:

DateTime = (* a character string 20 characters long *)
(* 01 Jan 86 02:34:56 *)
DayOfMonth " " Month " " Year " "
" " HH ":" MM ":" SS
Null

The "Null" is explicit there. These FidoNet specs are pretty terrible, but FTS-1 is one of the better ones. :-)

I think we quoted the same document. Except you quoted the "a Stored Message" ("as it is the layer that the user's application sees as opposed to what FidoNet sees".) section, and I quoted the "Packed Message" ("As this is a data structure which is actually transferred, its definition is critical to FidoNet") section.

Indeed, yes, but the DateTime field definition for the packed message is "inherited" from the Stored Message definition - it's not redefined.

Anyway, does that mean SBBSecho will only accept packets if the datatime field is encoded as a null terminated string?

Correct. It's been that way for a very long time, not new behavior.
--
digital man (rob)

Synchronet/BBS Terminology Definition #1:
ANSI = American National Standards Institute
Norco, CA WX: 59.4øF, 88.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)

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

Howdy,

Indeed, yes, but the DateTime field definition for the packed message is "inherited" from the Stored Message definition - it's not redefined.

I'm not seeing what you are seeing - but ok.

I'll tell this node that they need to have their software fixed to not send DateTimes as a 20 byte field, but a null terminated string - I think the source is hpt, so lets see if they agree...


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: deon to Digital Man on Tue Oct 07 2025 07:49 pm

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

Howdy,

Indeed, yes, but the DateTime field definition for the packed message is "inherited" from the Stored Message definition - it's not redefined.

I'm not seeing what you are seeing - but ok.

FSP-1042 (still in draft stage) has the packed message header more clearly defined:
,-------------------------------------------------------------. | Name | Type | Length | Description | +--------------+------+------------+--------------------------+ | dateTime | nStr | Exactly 19 | Date and time of message | | toUserName | nStr | 0-35 | User the message is to | | fromUserName | nStr | 0-35 | User the message is from | | subject | nStr | 0-71 | Message subject | | text | nStr | 0-Infinity | Message body | `--------------+------+------------+--------------------------'


The nStr type is defined (in FSP-1024) as:
nStr:
NUL-terminated string. A sequence of zero or more non-NUL
characters followed by a single NUL character. If a length is
specified, does NOT include the terminating NUL. If an nStr
with a length of 19 is stored, it will take 20 bytes of
storage because of the terminating NUL.

I'll tell this node that they need to have their software fixed to not send DateTimes as a 20 byte field, but a null terminated string - I think the source is hpt, so lets see if they agree...

I think you have that backwards, the DateTime must be a null terminated string: exactly 19 characters followed by a NUL.
--
digital man (rob)

Sling Blade quote #7:
Karl: I don't reckon the Good Lord would send anybody like you to Hades.
Norco, CA WX: 59.4øF, 88.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)

Hey deon!

On Tue, 07 Oct 2025 19:49:30 +1100, you wrote:

I'll tell this node that they need to have their software fixed to not
send DateTimes as a 20 byte field, but a null terminated string - I
think the source is hpt, so lets see if they agree...

For the record, I run hpt/binkd as my main hub and my BBS is Synchronet. Both have exchanged mail many times per day for many years. I have no issue here with hpt and Synchronet whatsoever.

Is is possible said node is using a very old version of hpt, if that is even the tosser they're using?

Regards,
Nick

... Sarcasm: because beating people up is illegal.
--- GoldED+/LNX 1.1.5-b20250409
# Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (723:1/1)
ï¿­ Synchronet ï¿­ _thePharcyde telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: Digital Man to deon on Tue Oct 07 2025 03:34 pm

Howdy,

I'm not seeing what you are seeing - but ok.

FSP-1042 (still in draft stage) has the packed message header more clearly defined:

Yup, but its a proposal and not a standard. I dont want this to lead into an interpretation of the standards debate - that never ends well.

I think you have that backwards, the DateTime must be a null terminated string: exactly 19 characters followed by a NUL.

I dont believe I do - its not how I understand FTS-1.

Anyway, you've made your position clear - I'll leave it to the uplink to address with their software's developer, if it is in fact still being developed and/or if they care.


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: Accession to deon on Tue Oct 07 2025 06:36 pm

Howdy,

For the record, I run hpt/binkd as my main hub and my BBS is Synchronet. Both have exchanged mail many times per day for many years. I have no issue here with hpt and Synchronet whatsoever.

Yeah, I used to as well, and had no issues.

Where I think the issue stems from (which I'm guessing based on these packets) - is that the areas are PASSTHRU.

I've seent hpt happily pass through bad mystic packets, and this might be another example of that. I havent looked deep enough to work it out.

Is is possible said node is using a very old version of hpt, if that is even the tosser they're using?

I dont think so, they switched to hpt in the last couple of years, but who knows <shrug>


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: deon to Digital Man on Wed Oct 08 2025 01:36 pm

Re: sbbsecho and bad packets
By: Digital Man to deon on Tue Oct 07 2025 03:34 pm

Howdy,

I'm not seeing what you are seeing - but ok.

FSP-1042 (still in draft stage) has the packed message header more clearly defined:

Yup, but its a proposal and not a standard. I dont want this to lead into an interpretation of the standards debate - that never ends well.

My point was that it was another developer's interpretation of the packet standard (not mine) and it's gone through the FTSC review process (such that it is anyway), so I think there's pretty solid consensus that "this is the way". I would be interested to know what software it is that's not NUL-terminating the DateTime in the packed-message headers.

I think you have that backwards, the DateTime must be a null terminated string: exactly 19 characters followed by a NUL.

I dont believe I do - its not how I understand FTS-1.

Anyway, you've made your position clear - I'll leave it to the uplink to address with their software's developer, if it is in fact still being developed and/or if they care.

Okay, and if you find out for sure what software that is, please let me know. --
digital man (rob)

This Is Spinal Tap quote #8:
Derek Smalls: Making a big thing out of it would have been a good idea.
Norco, CA WX: 62.1øF, 85.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.30-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: deon to Digital Man on Tue Oct 07 2025 07:49 pm

I'm not seeing what you are seeing - but ok.

I'll tell this node that they need to have their software fixed to
not send DateTimes as a 20 byte field, but a null terminated
string - I think the source is hpt, so lets see if they agree...

why arent you saying what the software is?
---
þ Synchronet þ ::: BBSES.info - free BBS services :::
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: MRO to deon on Wed Oct 08 2025 12:58 am

Howdy,

string - I think the source is hpt, so lets see if they agree...

why arent you saying what the software is?

Huh? I did. "I think the source is hpt".


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hi deon,

On 2025-10-08 17:43:52, you wrote to MRO:

why arent you saying what the software is?

Huh? I did. "I think the source is hpt".

The source is PyGate, a new development by the node, and already fixed!

And my opinion on FTS-0001 is that it's unclear and open for interpretation regarding the datetime field in the packed message header.
But current practice is that all fido software puts a NULL in position 20 of the datetime field.

Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Re: sbbsecho and bad packets
By: deon to MRO on Wed Oct 08 2025 05:43 pm

Re: sbbsecho and bad packets
By: MRO to deon on Wed Oct 08 2025 12:58 am

Howdy,

string - I think the source is hpt, so lets see if they agree...

why arent you saying what the software is?

Huh? I did. "I think the source is hpt".

oh i dont like abbreviations. you're talking about husky, right?
that i heard of.
---
þ Synchronet þ ::: BBSES.info - free BBS services :::
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbsecho and bad packets
By: MRO to deon on Wed Oct 08 2025 03:28 am

Howdy,

oh i dont like abbreviations. you're talking about husky, right?
that i heard of.

Yup, husky.

Looks like the packets went PyGate -> hpt -> SBBS...


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 --- SBBSecho 3.30-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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 --- SBBSecho 3.30-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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
--- SBBSecho 3.30-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)