F439_CPP_TX-RX_LoRa_Project

Loading...
Searching...
No Matches
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