Skip to content
Snippets Groups Projects

Define Packet Validation

Open reed requested to merge Reed/cats-standard:define-validation into master
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

Members who can merge are allowed to add commits.

Pipeline #7518 passed

Pipeline passed for 297eebec on Reed:define-validation

Ready to merge by members who can write to the target branch.
  • The source branch is 6 commits behind the target branch.
  • 0 commits and 1 merge commit will be added to .
  • Source branch will not be deleted.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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.
  • Hm, I'm on the fence about leaving this in. I think focusing on the Destination whisker specifically misses the point a bit, since any malformed whisker could change the meaning of the packet

  • Please register or sign in to reply
  • Stephen D
  • Stephen D
    Stephen D @stephen started a thread on the diff
  • 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.}
    • I'm a bit confused about this. Couldn't you have a packet with a length of 5, with the first whisker's length of 10? Or a packet with a length of 10, with a whisker of length 5. Seems like you could have both missing data or extra data

    • Please register or sign in to reply
  • Looks good, just had a few small comments

  • reed added 1 commit

    added 1 commit

    Compare with previous version

  • Please register or sign in to reply
    Loading