CAN Receive Queue Overflow: Make Lost Frames Visible Before Computing State
Enable and validate socket-loss telemetry, then treat a positive loss indication as a gap in that consumer’s evidence. A CAN receiver can keep returning valid frames after its queue has dropped earlier ones. Those later frames do not prove that a state estimate built from every expected update remains correct.
This guide pins the Linux v6.12 CAN_RAW receive path and Linux man-pages 6.19’s socket interface description. It covers socket-level evidence, not guaranteed detection of every controller, driver or bus loss. No load generator, socket overflow or target-state test was executed.
1. Identify which queue the counter describes
The SO_RXQ_OVFL contract supplies an unsigned 32-bit ancillary count of packets dropped by the socket since its creation. Scope the value to that socket’s lifetime, not to the physical bus or an application process that may recreate sockets.
The CAN_RAW path queues received clones for each socket and calls the generic ancillary-message helper during receive. Two consumers can therefore have different queue outcomes while observing the same interface.
Keep controller overflow, interface statistics, socket drops and application-queue loss in separate fields. A zero at one boundary does not prove that another boundary retained all input.
2. Receive the metadata, not only the payload
Use the actual ancillary-capable receive interface and reserve control-buffer space for every enabled metadata type. Inspect message level, type and length before copying the overflow value into an aligned local object.
The recvmsg reference distinguishes payload truncation from ancillary truncation through MSG_TRUNC and MSG_CTRUNC. A collector must preserve that distinction: complete CAN bytes do not imply complete control metadata.
Reset input capacities appropriately before each receive call, check returned lengths and inspect all relevant control messages. Do not assume the overflow record is the first ancillary item or that a plain payload read exposes it.
| Receive outcome | Loss-evidence status |
|---|---|
| Valid overflow control message | Use its value within the current socket generation |
| Control buffer truncated | Metadata incomplete; do not manufacture a zero count |
| No overflow control message | No value reported on this receive; preserve that distinction |
| Malformed or unexpected control length | Reject that metadata and report decoder uncertainty |
| Socket recreated | Start a new counter generation |
3. Compare counters only under bounded assumptions
For two valid observations from the same socket, compute the unsigned 32-bit difference. A wrap can be handled arithmetically only if the observation interval is known not to contain a full counter modulus of drops.
For example, a hypothetical previous value of 4,294,967,293 followed by 2 gives a modulo difference of five. It does not prove five when the socket was replaced or when multiple complete wraps are possible. Keep those cases explicitly unresolved.
Record the baseline, current value, socket generation, observation interval and validity conditions. The first observation of a newly monitored existing socket may already contain historical drops; do not mislabel all of them as newly occurring since the collector started.
Because the information arrives as ancillary data attached to received packets, it is not an immediate independent alarm channel. During silence or a blocked receiver, the latest observed value can remain stale. Pair it with freshness and consumer-liveness monitoring.
4. Do not assign lost packets to an identifier without evidence
The socket count does not identify the contents of the missing frames. A socket receiving several identifiers, local echoes and diagnostic events cannot attribute every increment to one measurement stream.
Use application-protocol sequence numbers where they actually exist, with documented reset, wrap and duplicate semantics. Classical CAN identifiers are not universal message sequence numbers. If the producer supplies no completeness mechanism, keep the uncertainty instead of claiming exact lost-message identities.
A protocol sequence gap can also arise before the socket queue. Retain both observations and correlate their windows without claiming that matching counts establish a unique root cause.
5. Decide what the application can still assert
| State model | After observed loss | Recovery evidence |
|---|---|---|
| Latest absolute measurement | Mark age/quality appropriately | A fresh valid absolute update under its protocol |
| Integrated deltas or event count | Completeness is broken | Authoritative snapshot or explicitly designed resynchronization |
| Multi-frame application transaction | Do not publish an incomplete result | Protocol completion or an explicit failed/unknown outcome |
| Safety-relevant command feedback | Do not infer completion from later unrelated traffic | Product-approved correlated state observation |
These are proposed application decisions, not automatic SocketCAN behavior. Increasing queue capacity can change future buffering but cannot reconstruct already missing input or prove that every future burst will fit.
6. Qualify loss visibility on an isolated workload
Start with a synthetic receive-metadata harness for absent, truncated, malformed, wrapping and reset counter cases. Verify that the state-quality decision uses validity as well as the numeric value.
For a later integration test, use an approved virtual or inert CAN fixture with a known source sequence and a deliberately delayed consumer. Record offered frames, receive results, socket counter observations and application-queue drops separately.
Resume consumption and provide a subsequent observation opportunity. Do not end the test immediately after overload and assume the final ancillary counter was already delivered. Capture the actual evidence sequence and its timing limits.
Repeat with multiple sockets and with a slow downstream application stage. This distinguishes the measured queue from a bottleneck elsewhere. Do not flood an operating vehicle or machine, change shared system limits or claim physical bus results from a virtual interface.
Hypothetical false continuity
A fictional estimator integrates movement deltas from CAN frames. After a host scheduling stall, frames continue arriving and the estimator reports a smooth position. Its socket-loss observation has increased, so the apparent continuity is unsupported.
The corrected design marks the integrated state incomplete and uses the product’s documented absolute-state recovery path. It does not subtract an assumed number of missing deltas from the counter because their payload values are unknown.
7. Keep an evidence-quality receipt
Save the socket generation, enabled metadata, control-buffer policy, counter observations, source-sequence evidence and state-quality transitions. A useful receiver reports both data and whether its observation history can support the result being computed.
