Protocol Verification and QA Harness

Overview

Part 18 introduced a focused protocol-verification harness for exercising the hardened Wire v3 RX path with hostile and boundary-condition inputs.

The intent of this harness is to verify that RX continues operating safely when presented with malformed, malicious, replayed, or boundary-value frames.

Verification Model

The verification model intentionally separates roles:

• TX runs a QA frame generator
• RX runs normal production receiver firmware

This approach validates the real RX rejection path rather than a test-only RX path.

Enabling the QA Harness

Protocol verification is enabled by defining:

#define RADIOLINK_QA_TEST

When enabled:

• TX builds and transmits targeted QA frames
• RX remains on the normal production receive path

Execution Expectations

During QA execution, RX must:

• reject invalid or hostile frames without halting
• avoid mutating replay state on rejected frames
• continue processing subsequent traffic
• accept valid frames, including maximum legal payload cases

Verified Test Coverage

1. Truncated Frame Rejection

   Frames shorter than the expected Wire v3 header were injected.

   Expected RX behavior:

   • frame rejected
   • no system halt
   • receiver continues running

2. Frame Length Mismatch

   Frames where the declared payload length did not match the received frame size were injected.

   Expected RX behavior:

   • frame rejected
   • no replay-state corruption
   • receiver continues running

3. CMAC Authentication Failure

   Frames with intentionally corrupted authentication tags were injected.

   Expected RX behavior:

   • frame rejected
   • no plaintext accepted
   • receiver continues running

4. Replay Rejection

   Duplicate frames with identical (nodeId, sessionSeqId, msgCounter) values were injected.

   Expected RX behavior:

   • first frame accepted
   • duplicate rejected
   • replay state remains correct

5. Maximum Payload Boundary Acceptance

   Frames containing the maximum legal plaintext size were transmitted.

   Expected RX behavior:

   • frame accepted
   • payload decrypted successfully

6. Oversized Payload Rejection

   Frames declaring a plaintext length larger than RADIOLINK_WIRE_V3_MAX_PLAINTEXT_LEN were injected.

   Expected RX behavior:

   • frame rejected
   • receiver continues running

7. Invalid NodeId Rejection

   Frames with nodeId >= RADIOLINK_MAX_NODE_ID were injected.

   Expected RX behavior:

   • frame rejected before replay-table indexing
   • receiver continues running

RX Rejection Behavior Requirement

Rejected protocol frames must be discarded without invoking Error_Handler().

The verified RX contract is:

• discard the rejected frame
• preserve receiver liveness
• preserve replay-state integrity
• continue processing future frames

Future Logging Hooks

This verification work also establishes the categories that should eventually map to unique structured logging identifiers for remote syslog forwarding, for example:

• RX_REJECT_TRUNCATED
• RX_REJECT_LENGTH_MISMATCH
• RX_REJECT_PAYLOAD_TOO_LARGE
• RX_REJECT_CMAC_FAIL
• RX_REJECT_REPLAY
• RX_REJECT_NODE_ID_OOB