| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| ref:fidonet_packets [2017/02/28 17:52] – More links, moved timeline digital man | ref:fidonet_packets [2018/03/25 14:52] – Details about string field termination (or lack thereof). digital man |
|---|
| |
| ^ 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 ==== |
| |
| | 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]] |
