CAN Transmit Echo Is Not a Remote Acknowledgement: Define What a Send Result Proves
Label a SocketCAN observation by where it was produced before using it as delivery evidence. A successful send, a locally echoed frame, a controller-level transmit completion and a remote application’s response are different events. Even the local echo’s timing depends on whether the driver or the CAN core produced it.
This guide pins Linux v6.12 CAN_RAW and the common CAN send path. It focuses on Classical CAN and local echo provenance, not a universal controller completion contract. No socket traffic, hardware transmission or remote command was executed.
1. Record the send result at its actual boundary
The RAW send implementation returns the submitted size when can_send() succeeds. That call path does not wait for a response from the destination application.
Record the interface, submitted frame representation, socket identity, return value and monotonic submission time. Keep a failed submission separate from an accepted submission whose later outcome is unknown.
Do not infer a specific physical transmission timestamp from the return time. Queues, arbitration and controller behavior belong to later stages. If timing matters, identify the actual timestamp source and its documented point in the transmission path.
2. Decode local origin flags without promoting them
The returned-message flag contract identifies locally created frames through MSG_DONTROUTE and same-originating-socket frames through MSG_CONFIRM. Receiving one’s own RAW frames requires CAN_RAW_RECV_OWN_MSGS; ordinary filtering still applies.
| Receive observation | Useful meaning | Unproven conclusion |
|---|---|---|
| DONTROUTE set | Local-host origin | A remote application sent a reply |
| CONFIRM set | Frame originated through this socket | Intended recipient processed it |
| Same payload on another local listener | That listener received a matching local observation | Physical bus completion |
| No own echo received | Required observation is absent | Transmission definitely never occurred |
Check loopback, own-message reception, filter selection and receive loss before interpreting missing echo. A deliberately disabled observation cannot serve as a negative transmission test.
3. Distinguish driver echo from core fallback
In can_send(), an interface without IFF_ECHO uses a cloned frame for core loopback. The core delivers that clone after successful dev_queue_xmit(); it does not wait there for hardware completion.
The SocketCAN documentation conditions interpreting CONFIRM as transmission confirmation on driver-level echo support. Therefore an application must identify the actual driver path before making that stronger claim.
For a supported hardware driver, inspect which completion indication causes its echo to be released, including controller modes, one-shot operation and error handling relevant to the product. A generic ECHO capability flag is a useful starting point, not a complete description of every adapter firmware behavior.
The RAW receive code sets the flags from the originating socket relationship. Those flags themselves do not carry the name of a remote receiver or certify that a remote control task ran.
4. Keep bus acknowledgement separate from recipient identity
Kvaser’s Classical CAN explanation notes that acknowledgement establishes that one or more nodes received the frame correctly, not necessarily the intended addressee. A protocol-level ACK therefore cannot identify which application consumed the data.
For a recipient-specific requirement, use the actual application protocol’s correlated response or state observation. If it has no such mechanism, report the available lower-level evidence and leave receipt or completion unresolved.
Do not manufacture a reply by feeding the transmitted frame back into the application’s receive decoder. A local monitor showing the request again is not an independent response from the remote node.
5. Build a provenance-aware trace
Give each observation an origin class: submission result, core echo, qualified driver echo, independent bus capture or remote application response. Include the originating interface and socket relationship where available.
For the application response, retain the protocol’s actual correlation fields, sender identity rules and freshness checks. Matching only an identifier or payload can confuse a repeated telemetry value with a response to the current request.
A useful report has multiple evidence fields rather than one delivered Boolean. It can say submission accepted, local echo observed and recipient result unavailable without declaring contradictory outcomes.
6. Qualify the observation mechanism with inert fixtures
| Proposed case | Question to answer |
|---|---|
| Own-message reception enabled and disabled | Does the collector distinguish configuration from missing delivery? |
| Originating socket versus second local socket | Are origin flags retained and interpreted correctly? |
| Core fallback versus qualified driver echo | Does the report preserve the different completion boundaries? |
| Unrelated receiver present, intended application unavailable | Can lower-level activity avoid being mislabeled recipient completion? |
| Receive queue loss or restrictive filter | Does absent echo remain an evidence gap rather than false certainty? |
These cases are unexecuted. Virtual interfaces can test local provenance and software handling, but have no physical bus acknowledgement. Hardware cases require an isolated, approved network and benign messages; never use an actuator command just to obtain an echo.
Hypothetical false completion
A fictional gateway marks every command complete when it receives its own frame with CONFIRM. Its adapter uses a path whose local observation does not establish the remote application’s result. The destination task can be unavailable while the gateway still reports completion.
The corrected display names the last proven boundary and waits for whatever recipient evidence the real protocol defines. It does not automatically retransmit an uncertain physical command to force a response.
7. Preserve the driver-specific limit
Release the collector with its tested kernel, driver, adapter firmware, socket options and observation map. Requalify when any of these change. The goal is a trace that explains exactly what each event proves, without treating local visibility as a remote promise.
