[robdobsn]

Summary

ufStart has an optional CRC16. It was parsed and passed along with every block, but never checked, so clients verified uploads with a separate filehash request.

• The check. FileStreamSession keeps a CRC16-CCITT of the data as it writes it, in order, the same CRC filehash reports. For background writes this runs on the file system worker. After the final block it compares the result with the given CRC16.
• On a mismatch (new RAFT_CRC_MISMATCH):
  • the file is deleted;
  • the client gets a ufCancel with reason failCRC instead of the final ack;
  • or, if blocks are written as they arrive, a ufStatus reply with reason CRCMismatch.
• On a match, the ufEnd reply says so with "crc16":"xxxx", so a client can skip filehash. The session ends once the final block is written, so ufEnd usually finds no session. ProtocolExchange therefore keeps the checked CRC, by channel and file name, after the session ends. A CRC is reported only once the whole file has been written and has matched.
• Compatibility. Older firmware gives no crc16, so a client that doesn't see one keeps checking with filehash. Firmware updates aren't checked here, since ESP-IDF validates the image.

RaftCLI sends the CRC and uses the reply: robdobsn/RaftCLI#4.

Testing

• Linux:
  • test_file_upload_background covers matching, wrong and absent CRCs: no cancel and a checked CRC; failCRC and the file deleted; no check.
  • test_protocol_exchange covers the real sequence: upload, the session ends, then ufEnd, with the CRC in the reply only when it matched.
  • make check passes.
• On an Axiom, over the WebSocket:
  • right CRC: blocks acked, and ufEnd replies {"crc16":"19ff","rslt":"ok"};
  • wrong CRC: failCRC in place of the final ack, no crc16 in the ufEnd reply, and the file gone.
• RaftCLI on the same device: uploads over HTTP, WebSocket, serial and BLE all verified and read back identical.

🤖 Generated with Claude Code