This is an old revision of the document!


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:

  1. A single 58-byte “Packet Header”
  2. Zero or more “Packed Messages” (each with its own header and body text, null terminated)
  3. A single “Packet Terminator” (16-bits of 0)

“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” packet format.

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 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
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

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 version of 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.

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-0001 transitions to a FidoNet standard (FTS-0001)
  • 1989-10-25 FTS-0001.013 is published
  • 1990-02-22 FSC-0039.001 is published
  • 1990-06-17 FSC-0048.001 is published
  • 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
  • 1990-10-21 FSC-0048.002 is published
  • 1995-09-30 FTS-0001.016 is published

See Also

ref/fidonet_packets.1488318744.txt · Last modified: 2017/02/28 13:52 by digital man
Back to top
CC Attribution 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0