Both sides previous revisionPrevious revisionNext revision | Previous revision |
ref:fidonet_packets [2017/02/28 17:52] – More links, moved timeline digital man | ref:fidonet_packets [2018/11/05 22:32] (current) – [See Also] Added link to Stephen Hurd's FSP draft about Type 2 packets digital man |
---|
- Zero or more "Packed Messages" (each with its own header and body text, null terminated) | - Zero or more "Packed Messages" (each with its own header and body text, null terminated) |
- A single "Packet Terminator" (16-bits of 0) | - 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. | "Type-1", "Type-3" and other deprecated or proposed FidoNet packet formats are not discussed here since they are not widely used. |
| |
^ Format ^ Spec ^ Version ^ File ^ Notes ^ | ^ Format ^ Spec ^ Version ^ File ^ Notes ^ |
| Type-2 | FTS-1 | 16 | [[http://ftsc.org/docs/fts-0001.016|FTS-0001.016]] | Derived from FSC-1, initially standardized at version 12 | | | Type-2 | FTS-1 | 16 | [[http://ftsc.org/docs/fts-0001.016|FTS-0001.016]] | Derived from FSC-1. Initially standardized at version 12. Supports 3D addresses. | |
| Type-2e | FSC-39 | 4 | [[http://ftsc.org/docs/fsc-0039.004|FSC-0039.004]] | The name "Type-2e" is being coined here in this article | | | Type-2e | FSC-39 | 4 | [[http://ftsc.org/docs/fsc-0039.004|FSC-0039.004]] | Adds 4D address suppoort. The name "Type-2e" is being coined here in this article. | |
| Type-2+ | FSC-48 | 2 | [[http://ftsc.org/docs/fsc-0048.002|FSC-0048.002]] | Packet header is loosely based on FSC-39 | | | Type-2+ | FSC-48 | 2 | [[http://ftsc.org/docs/fsc-0048.002|FSC-0048.002]] | Packet header is based on FSC-39 with improved backward compatibility with FTS-1. | |
| Type-2.2 | FSC-45 | 1 | [[http://ftsc.org/docs/fsc-0045.001|FSC-0045.001]] | Packet header differs considerably from other Type-2 formats, but includes full 5D addressing | | | Type-2.2 | FSC-45 | 1 | [[http://ftsc.org/docs/fsc-0045.001|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 ((FSC-39 packets lack the ''auxNet'' field specified in FSC-48)). |
==== Timeline ==== | ==== Timeline ==== |
| |
==== Header Fields ==== | ==== Header Fields ==== |
| |
^ Offset ^ Length ^ FSC-1 ^ FTS-1 (Type-2) ^ FSC-39 (Type-2e) ^ FSC-48 (Type-2+) ^ FSC-45 (Type-2.2) ^ | ^ Offset ^ Length ^ FSC-1 ^ FTS-1 (Type-2) ^ FSC-39 (Type-2e) ^ FSC-48 (Type-2+) ^ FSC-45 (Type-2.2) ^ |
| 0x00 | 2 | origNode ||||| | | 0x00 | 2 | origNode ||||| |
| 0x02 | 2 | destNode ||||| | | 0x02 | 2 | destNode ||||| |
| 0x10 | 2 | baud |||| sub-version (2) | | | 0x10 | 2 | baud |||| sub-version (2) | |
| 0x12 | 2 | version/type (2) ||||| | | 0x12 | 2 | version/type (2) ||||| |
| 0x14 | 2 | origNet ||||| | | 0x14 | 2 | origNet ||| (0xFFFF when origPoint != 0) | OrigNet | |
| 0x16 | 2 | destNet ||||| | | 0x16 | 2 | destNet ||||| |
| 0x18 | 1 | prodCode ||||| | | 0x18 | 1 | prodCode ||||| |
| 0x34 | 2 | reserved || destPoint ||::: | | | 0x34 | 2 | reserved || destPoint ||::: | |
| 0x36 | 4 | reserved || prodData ||| | | 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 ==== | ==== Fill ==== |
danger that a point is seen as the boss node is eliminated. | 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 ===== | ===== See Also ===== |
* [[http://ftsc.org/docs/fts-0001.016|FTS-1: A Basic FidoNet(r) Technical Standard, Randy Bush, version 16]] | * [[http://ftsc.org/docs/fts-0001.016|FTS-1: A Basic FidoNet(r) Technical Standard, Randy Bush, version 16]] |
* [[http://ftsc.org/docs/fsc-0048.002|FSC-48: A Proposed Type-2 Packet Extension, Jan Vroonhof, version 2]] | * [[http://ftsc.org/docs/fsc-0048.002|FSC-48: A Proposed Type-2 Packet Extension, Jan Vroonhof, version 2]] |
* [[http://ftsc.org/docs/fsc-0045.001|FSC-45: A Proposal for A New Packet Header Format, Thom Henderson, version 1]] | * [[http://ftsc.org/docs/fsc-0045.001|FSC-45: A Proposal for A New Packet Header Format, Thom Henderson, version 1]] |
| * [[http://bbsdev.net/fsp/FSP-Draft.txt|FSP-Draft: Packet Type 2 Compatible Formats, Stephen Hurd]] |
* [[:ref:|References]] | * [[:ref:|References]] |
| |
{{tag>}} | {{tag>fidonet}} |
| |