Troubleshoot Missing CAN Frames

When CAN frames appear to be missing, preserve the original capture and move through the physical layer, controller state, host path and application filters in that order.

1. Define the expected frame

“I cannot see the message” is not yet a fault statement. Record the expected CAN identifier, standard or extended format, expected period or trigger, Classical CAN or CAN FD, nominal bitrate, data-phase bitrate where applicable, and the source that proves the expectation.

Also record whether the frame is absent from the raw capture or only absent after filtering or DBC decoding. A stale DBC, wrong extended-ID flag or display filter can hide a frame that is present on the wire.

2. Prove the physical layer first

1. Power down and verify CANH, CANL, ground and any power pins against a pin-numbered drawing.
2. Check that termination belongs at the two ends of the trunk. A healthy, unpowered two-terminator network often measures near 60 Ω between CANH and CANL, but topology and connected electronics can affect the reading.
3. Confirm the intended nominal bitrate from controlled documentation, not from a guess based on industry.
4. Inspect branch length, connector continuity, polarity and intermittent cable movement.
5. Stop after unexpected voltage, heat, error storms or repeated resets.

Do not “fix” silence by adding termination blindly. A third 120 Ω resistor changes the parallel resistance and can make a previously marginal bus worse.

3. Inspect the SocketCAN state and counters

ip -details -statistics link show can0
candump -L -e can0
canbusload can0@500000

The Linux CAN network interface reports controller state and statistics through the networking stack. Record the output before bringing the interface down or resetting it. Look for:

• ERROR-ACTIVE, ERROR-WARNING, ERROR-PASSIVE or BUS-OFF state;
• RX/TX dropped counts or queue growth;
• bitrate and sample-point configuration;
• error frames, when the driver and controller report them;
• unexpected automatic restart behavior.

A bus-off recovery command may hide the original failure if used before evidence is saved. Preserve state and timestamps, then reset under a written test step.

4. Separate adapter loss from source absence

Use a controlled traffic generator or a second qualified interface on a bench. Do not infer adapter loss by comparing two displays with different filters and timestamp origins.

On a narrow screen, scroll the comparison horizontally.

For SLCAN, record the serial device, UART setting, daemon command and adapter firmware. For gs_usb, record the USB ID, driver, kernel and firmware. A test that changes the adapter, firmware, cable and capture application at once cannot isolate the fault.

5. Remove application assumptions

• Capture all IDs before applying an acceptance filter.
• Keep standard and extended identifiers distinct.
• Save raw frames before DBC, J1939 or CANopen decoding.
• Check whether the decoder expects little-endian or big-endian signal layout.
• Confirm that CAN FD frames are not being sent to a Classical CAN-only interface.
• Compare monotonic timestamps only after naming their source and resolution.

6. Publish a reproducible loss report

A useful report includes the expected frame count, observed raw count and loss-detection method. Add the hardware revision, firmware hash, host OS, kernel, driver, bitrate, topology, termination, traffic generator, bus load, duration, commands and raw log. State every filter and every reset.

Report “no loss observed under these conditions,” not “loss-free.” The next customer may use a different bus load, USB controller, kernel or frame distribution.

Bring evidence, not a screenshot

Start with the termination guide and host-path comparison. If you can share a non-confidential reproduction, submit it to the MallMars pilot.

Primary references

• Linux Kernel: SocketCAN — Controller Area Network
• linux-can/can-utils: candump, canbusload and related tools
• Kvaser: CAN protocol tutorial and error confinement