Send-side "answer-as-asked" response re-encapsulation (CRC-16 0x56, Security S0/S2)

[dfederm]

Summary

When a request arrives transport-encapsulated, the spec requires the response to be sent back with the same encapsulation ("answer-as-asked"). The receive-side de-encapsulation for CRC-16 and Multi Command is implemented in #144; the send-side (re-wrapping the outgoing response) is still missing for CRC-16, and the same hook will be needed for Security S0/S2.

Spec requirement (answer-as-asked)

CRC-16 Encapsulation CC, Transport-Encapsulation spec (SDS13783) §3.1.1.2:

A node supporting the CRC-16 Encapsulation Command Class may receive a combination of ... encapsulated and normal non-encapsulated requests and the response MUST be as follows:

a) If the request is sent encapsulated, the response MUST be returned encapsulated.
b) If the request is sent non-encapsulated, the response MUST be sent non-encapsulated.

Security S0/S2 carry the equivalent requirement. CRC-16 is deprecated in favor of Security 2, but some device types still require CRC-16, so both must be handled.

Scope

• Wrap the driver's outgoing response in CRC-16 when the originating request was CRC-16-encapsulated.
• Design the send-side transport-encapsulation hook generically so Security S0 (0x98) / Security 2 (0x9F) can reuse the same response-re-wrap plumbing.

Out of scope

• Multi Command (0x8F): its answer-as-asked behavior is obsoleted (§3.4.1) with an explicit exception (§2). No send-side Multi Command wrapping is needed.
• The full Security S0/S2 implementation (keying, nonces, encryption). Only the shared response-re-wrap hook (plus CRC-16 itself) is in scope here; the Security crypto work is a separate, larger effort.

Design considerations / open questions

• Threading the context. The receive path de-encapsulates and dispatches the inner command to the node/endpoint; the response is generated and sent from within that flow. To answer-as-asked, the driver must know that "the request that triggered this response was CRC-16-wrapped" and apply the wrap on send. That context does not currently flow from receive to send: IDriver.SendCommandAsync(nodeId, endpointIndex, frame) carries no encapsulation information.
• Existing send pipeline. The Driver already has a send-side encapsulation pipeline (send order: payload → Multi Command → Supervision → Multi Channel → Security/CRC-16, outermost). A CRC-16 send-side wrap plugs in as the outermost layer of that pipeline; the missing piece is the per-request state that tells the pipeline to apply it.
• What counts as "the response". Confirm whether only the direct answer to the request must be re-wrapped, or also induced/unsolicited reports generated while handling it.
• Multicast/broadcast. Answer-as-asked applies to unicast responses; confirm the behavior for multi-target sends (no per-node wrapping).

Related

• Implement CRC-16 Encapsulation CC (0x56) and Multi Command CC (0x8F) #144 — CRC-16 (0x56) and Multi Command (0x8F) CCs; receive-side de-encapsulation
• Driver encapsulation pipeline: src/ZWave/Driver.cs