Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
ref:fidonet_packets [2017/02/28 17:10] – [Fill] Mention FSC-1 -> FTS-1 change digital manref:fidonet_packets [2018/11/05 22:32] (current) – [See Also] Added link to Stephen Hurd's FSP draft about Type 2 packets digital man
Line 5: Line 5:
   - 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.
Line 12: Line 14:
 ===== Packet Files ===== ===== 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 into //[[fidonet_files#bundle|bundles]]//. Contrary to popular confusion, FidoNet packets and bundles are not the same thing.+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 //[[fidonet_files#bundle|bundles]]//. Contrary to popular confusion, FidoNet packets and bundles are not the same thing, though bundles often contain packets.
  
-===== Format Extensions =====+===== Extensions =====
  
 In addition to the //standard// (Type-2) FidoNet packet, the following Type-2 packet extensions are also documented here: In addition to the //standard// (Type-2) FidoNet packet, the following Type-2 packet extensions are also documented here:
Line 23: Line 25:
 ===== Specification Versions ===== ===== Specification Versions =====
  
-Although multiple versions 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:+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      | [[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]] | 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 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. 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 ==== 
 + 
 +  * 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 [[http://ftsc.org/docs/fsc-0039.001|FSC-0039.001]] is published: Introduces ''capWord'' and other new fields 
 +  * 1990-04-17 [[http://ftsc.org/docs/fsc-0045.001|FSC-0045.001]] is published: Substantially re-arranges header to accommodate 5D addresses 
 +  * 1990-06-17 [[http://bbs.idefix.net/fidonetstandards/fsc-0048.001|FSC-0048.001]] is published: Builds upon ideas introduced in FSC-39.1, addresses flaws 
 +  * 1990-07-05 [[http://cd.textfiles.com/hackersencyc/RFC/FTSC/FTS_0001.014|FTS-0001.014]] is published 
 +  * 1990-08-30 FTS-0001.015 is published 
 +  * 1990-09-29 [[http://ftsc.org/docs/fsc-0039.004|FSC-0039.004]] is published: Adds the ''capValid'' header field (copied from FSC-48.1) 
 +  * 1990-10-21 [[http://ftsc.org/docs/fsc-0048.002|FSC-0048.002]] is published: More references (e.g. to FSC-39.4) and clarifications 
 +  * 1995-09-30 [[http://ftsc.org/docs/fts-0001.016|FTS-0001.016]] is published: TOPT corrected
  
-^ Format   ^ Spec   ^ Version ^ File         ^ 
-| Type-2   | FTS-1  | 16      | [[http://ftsc.org/docs/fts-0001.016|FTS-0001.016]] | 
-| Type-2e  | FSC-39 | 4       | [[http://ftsc.org/docs/fsc-0039.004|FSC-0039.004]] | 
-| Type-2+  | FSC-48 | 2       | [[http://ftsc.org/docs/fsc-0048.002|FSC-0048.002]] | 
-| Type-2.2 | FSC-45 | 1       | [[http://ftsc.org/docs/fsc-0045.001|FSC-0045.001]] | 
 ===== Headers ===== ===== Headers =====
  
Line 44: Line 67:
 ==== Header Fields ==== ==== Header Fields ====
  
-^ Offset ^ Length ^ FSC-1 ^ FTS-1 (Type-2) ^ FSC-39 ^ 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  |||||
Line 55: Line 78:
 | 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 |||||
Line 72: Line 95:
 | 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 ====
Line 80: Line 111:
 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+". 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).+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 === === auxNet ===
Line 99: Line 130:
   danger that a point is seen as the boss node is eliminated.   danger that a point is seen as the boss node is eliminated.
  
-==== Timeline ====+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.
  
-  * 1984-06-01 First version of FidoNet software is released by Tom Jennings +=== prodData ===
-  * 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 [[http://cd.textfiles.com/hackersencyc/RFC/FTSC/FTS_0001.014|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+
  
 +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]]
Line 120: Line 142:
   * [[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}}
  
ref/fidonet_packets.1488330629.txt · Last modified: 2017/02/28 17:10 by digital man
Back to top
CC Attribution 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0