Table of Contents
FidoNet Packets
FidoNet packets are all somewhat based on the “Type-2” packet format defined in Section F (Network Layer) of FTS-1, a.k.a. FTS-0001 which contains:
- A single 58-byte “Packet Header”
- Zero or more “Packed Messages” (each with its own header and body text, null terminated)
- A single “Packet Terminator” (16-bits of 0)
Packed Messages may consist of “NetMail” (node-to-node) or “EchoMail” (posted in a public echo area), or both intermixed within the same packet. The format of Packed Messages is also defined in FTS-1.
“Type-1”, “Type-3” and other deprecated or proposed FidoNet packet formats are not discussed here since they are not widely used.
The original Type-2 packet format is also sometimes called the “Stone-Age” or “Type-2.0” packet format.
Packet Files
FidoNet packets are most often generated and transmitted in filenames ending in a .pkt
suffix/extension. FidoNet packet files may be transferred between nodes as-is (raw) or archived and transferred in bundles. Contrary to popular confusion, FidoNet packets and bundles are not the same thing, though bundles often contain packets.
Extensions
In addition to the standard (Type-2) FidoNet packet, the following Type-2 packet extensions are also documented here:
Specification Versions
Although multiple versions (revisions) of the various Type-2 FidoNet packet specifications were published, the following versions are generally accepted as the last and final version of these documents and were used as the reference material for this article:
Format | Spec | Version | File | Notes |
---|---|---|---|---|
Type-2 | FTS-1 | 16 | FTS-0001.016 | Derived from FSC-1. Initially standardized at version 12. Supports 3D addresses. |
Type-2e | FSC-39 | 4 | FSC-0039.004 | Adds 4D address suppoort. The name “Type-2e” is being coined here in this article. |
Type-2+ | FSC-48 | 2 | FSC-0048.002 | Packet header is based on FSC-39 with improved backward compatibility with FTS-1. |
Type-2.2 | FSC-45 | 1 | FSC-0045.001 | Packet header differs considerably from other Type-2 formats. Supports 5D addresses. |
NOTES:
- 3D addresses are normally expressed as “<zone>:<net>/<node>” (e.g. “1:103/705”)
- 4D addresses are normally expressed as “<zone>:<net>/<node>[.point]” (e.g. “1:103/705.1”)
- 5D addresses are normally expressed as “<zone>:<net>/<node>[.point]@<domain>” (e.g. “1:103/705@fidonet”)
- Type-2e (FSC-39) packets are often erroneously referred to as “Type-2+” packets: they are not 3).
Timeline
- 1984-06-01 First version of FidoNet software is released by Tom Jennings
- 1987-12-27 FSC-0001.009 is published: defines “stone age” Type-2 Packet Header format
- 1989-04-?? FTS-0001.??? is published: FSC-1 transitions to a FidoNet standard: FTS-1
- 1989-10-25 FTS-0001.013 is published
- 1990-02-22 FSC-0039.001 is published: Introduces
capWord
and other new fields - 1990-04-17 FSC-0045.001 is published: Substantially re-arranges header to accommodate 5D addresses
- 1990-06-17 FSC-0048.001 is published: Builds upon ideas introduced in FSC-39.1, addresses flaws
- 1990-07-05 FTS-0001.014 is published
- 1990-08-30 FTS-0001.015 is published
- 1990-09-29 FSC-0039.004 is published: Adds the
capValid
header field (copied from FSC-48.1) - 1990-10-21 FSC-0048.002 is published: More references (e.g. to FSC-39.4) and clarifications
- 1995-09-30 FTS-0001.016 is published: TOPT corrected
Headers
All Type-2 FidoNet Packet Headers (and their derivations) are 58 bytes in length.
- Each Packet Header contains multiple single-byte and multi-byte fields.
- All multi-byte integer fields are stored in little endian byte-order.
- Text fields (e.g. password and domains) contain US-ASCII characters or nulls ('\0').
The “Type-2” is the most basic of Packet headers, but it lacks support for points (so-called “4D addresses”) or domains (“5D addresses”). Early revisions of FTS-1 lacked support for zones (“3D addresses”). The support for points in FidoNet Packet Headers was added in the Type-2 Packet Extension Proposal (FSC-39), as well as the Type-2+ and Type-2.2 packet header format/extension proposals.
None of the proposed “Type-2” extensions (e.g. FSC-39, FSC-48, FSC-45) were ever formally standardized, though they became ubiquitous in the early 1990s and have remained in wide-spread use ever since.
Header Fields
Offset | Length | FSC-1 | FTS-1 (Type-2) | FSC-39 (Type-2e) | FSC-48 (Type-2+) | FSC-45 (Type-2.2) |
---|---|---|---|---|---|---|
0x00 | 2 | origNode | ||||
0x02 | 2 | destNode | ||||
0x04 | 2 | year | origPoint | |||
0x06 | 2 | month | destPoint | |||
0x08 | 2 | day | reserved (0) | |||
0x0A | 2 | hour | reserved (0) | |||
0x0C | 2 | minute | reserved (0) | |||
0x0E | 2 | second | reserved (0) | |||
0x10 | 2 | baud | sub-version (2) | |||
0x12 | 2 | version/type (2) | ||||
0x14 | 2 | origNet | (0xFFFF when origPoint != 0) | OrigNet | ||
0x16 | 2 | destNet | ||||
0x18 | 1 | prodCode | ||||
0x19 | 1 | reserved | serialNo | prodVersionMajor | ||
0x1A | 8 | reserved | password | |||
0x22 | 2 | reserved | origZone | |||
0x24 | 2 | reserved | destZone | |||
0x26 | 2 | reserved | auxNet | origDomain | ||
0x28 | 2 | reserved | capValid (capWord copy) | |||
0x2A | 1 | reserved | prodCodeHi | |||
0x2B | 1 | reserved | prodVersionMinor | |||
0x2C | 2 | reserved | capWord | |||
0x2E | 2 | reserved | origZone | destDomain | ||
0x30 | 2 | reserved | destZone | |||
0x32 | 2 | reserved | origPoint | |||
0x34 | 2 | reserved | destPoint | |||
0x36 | 4 | reserved | prodData |
String Termination
Some of the packet header fields contain arrays of ASCII characters (“strings”):
- password
- origDomain
- destDomain
If the string values are shorter than the maximum allowed (e.g. 8 characters), then the remaining bytes of the field should be zero-filled. If the string value is exactly the maximum allowed length, then there is no required string terminator (e.g. NUL byte) following the value and the array should not be treated as a null-terminated (i.e. ASCIIZ) string.
Fill
The trailing reserved
fields were originally defined (in FTS-1) as a single contiguous fill
area. Although not explicitly specified in FTS-1, the usual assumption is that this area is zero-filled by the packet generating software. This fill
area is where the packet header was extended (new header fields were added, e.g. the fields following the prodCode
) after the initial versions of FSC-1 (the precursor to FTS-1). So being able to assume unused/reserved bytes will be zero-filled by older software has been useful for extensibility.
Type-2 Plus
So-called “Type-2+” packets appear to be the most widely supported (accepted and generated) by FidoNet software in use today. However, there appears to be some debate about whether FSC-39[.4] defines the most-commonly-accepted packets or FSC-48 defines the most-commonly-accepted packets. To add to this confusion, only FSC-48 actually mentions the term “Type-2+”.
The only differences between the packet headers defined in FSC-39.1 and FSC-48 are the capValid
(CWvalidationCopy) fields and the auxNet
fields: both fields are present in FSC-48 but absent in FSC-39.1. In FSC-39.4, the capValid
field was added, but the auxNet
field remains absent. FidoNet software that accepts an extended Type-2 packet but does not recognize the auxNet
field may be confused about the originator of packets from point nodes (where the origNet
field is set to 0xffff
and the auxNet
field is then utilized to store the originating net number).
auxNet
FSC-48 offers this explanation with regards to the auxNet
header field:
Although it (FSC-39 packet header) implements fields for zone and point number, an FTS-0001 compliant application is not required to look at these fields. When a point mails using these fields to implement its 4D address, a system only looking at the net/node info, as is required by FTS-0001, still sees it as a boss node, causing the obvious problems.
This document provides a way for transparent point handling, using a technique already exploited by many mailers internally. It will allow this document to be implemented and used by mailers not supporting it. At the same time the danger that a point is seen as the boss node is eliminated.
Although, according to FSC-48, the auxNet
field is not supposed to be initialized to a non-zero value unless the originating node is a point, some FidoNet mail software (e.g. Squish) will always set the auxNet
field to the originating net value in Type-2+ packets.
prodData
Although FSC-39 defines this 4-byte field as containing “Whatever” and FSC-48 just says “Product specific filler”, both Squish and Husky/areastat place the ASCII characters XPKT
in this field. The significance of the XPKT
string is unknown.
See Also
auxNet
field specified in FSC-48