Define Packet Validation
2 unresolved threads
2 unresolved threads
Captures some of the discussion in Issue #7 by explicitly calling out what checks are required to validate a CATS packet.
Merge request reports
Activity
Filter activity
70 CATS aims to avoid this problem. A packet that does not conform rigidly to the standard must have its contents discarded. Even if only one whisker is malformed, all whiskers must be ignored. It is considered an implementation bug if this does not occur. Note that unknown whisker types are not invalid. This allows for future whisker types to be added without breaking compatibility with existing implementations. 70 \subsubsection{Required Validation Criteria} 71 72 There are some base validation criteria that all CATS implementations must follow. 73 74 \paragraph{Discard CATS packets if the Header's Data length field is greater than 8191.} This standard requires all CATS packets to be no more than 8191 bytes long. Any reported length greater than that must be in err. 75 76 \paragraph{Discard CATS packets if the CRC does not match the CRC of the packet contents.} The CRC is the primary mechanism for verifying that the data received matches the data sent. Any difference must mean the packet has been corrupted in some manner or another, so none of the data can be trusted. 77 78 \paragraph{Discard CATS packets if the length of the Whiskers does not exactly match the length of the available data.} All of the data in the packet must be inside Whiskers. If the Whisker length fields suggest there should be more data than is actually present, either the Whisker lengths are malformed, or there is missing data. In both cases, the data is not suitable. \emph{Note that due to the construction of the packet format, there is no way for there to be ``extra'' or ``left over'' data, only missing data.} 79 80 \subsubsection{Implementation-Specific Required Validation Criteria} 81 82 Implementations are not required to implement any specific Whiskers, or any Whiskers at all, for that matter. Unknown or un-implemented Whiskers are \emph{not} considered invalid. However, for each Whisker Type that \emph{is} implemented, the implementation must discard CATS packets that contain even a single invalid Whisker of that type. 83 84 While it may initially seem overly-strict to discard an entire CATS packet for a single malformed Whisker, consider a scenario where a Destination type Whisker is malformed. Retransmitting the packet without the Destination would consume air time and power with no chance of successful communication. In general, only the sender knows which Whiskers are or are not critical to the packet's meaning. Without that understanding, dropping the whole packet is safer than accidentally modifying the meaning by altering the packet. - Resolved by reed
65 65 66 66 \subsection{Invalid CATS Packets} 67 67 68 The APRS standard is plagued by the existence of invalid packets. A good APRS parser not only handles valid packets --- it also handles slightly malformed ones. Different parsers may handle malformed packets differently, since by definition, they are not in a unified standard. This complicates new implementations and leads to fragmentation of the ecosystem. 68 The APRS standard is plagued by the existence of invalid packets. A good APRS parser not only handles valid packets --- it also handles slightly malformed ones. Different parsers may handle malformed packets differently, since by definition, they are not in a unified standard. This complicates new implementations and leads to fragmentation of the ecosystem. CATS aims to avoid this problem. A packet that does not conform rigidly to this standard must have its contents discarded. 69 69 70 CATS aims to avoid this problem. A packet that does not conform rigidly to the standard must have its contents discarded. Even if only one whisker is malformed, all whiskers must be ignored. It is considered an implementation bug if this does not occur. Note that unknown whisker types are not invalid. This allows for future whisker types to be added without breaking compatibility with existing implementations. 70 \subsubsection{Required Validation Criteria} 71 72 There are some base validation criteria that all CATS implementations must follow. 73 74 \paragraph{Discard CATS packets if the Header's Data length field is greater than 8191.} This standard requires all CATS packets to be no more than 8191 bytes long. Any reported length greater than that must be in err. 75 76 \paragraph{Discard CATS packets if the CRC does not match the CRC of the packet contents.} The CRC is the primary mechanism for verifying that the data received matches the data sent. Any difference must mean the packet has been corrupted in some manner or another, so none of the data can be trusted. 77 78 \paragraph{Discard CATS packets if the length of the Whiskers does not exactly match the length of the available data.} All of the data in the packet must be inside Whiskers. If the Whisker length fields suggest there should be more data than is actually present, either the Whisker lengths are malformed, or there is missing data. In both cases, the data is not suitable. \emph{Note that due to the construction of the packet format, there is no way for there to be ``extra'' or ``left over'' data, only missing data.}