Replay

The raw recorder can run backwards: given a capture file, it puts the frames back onto a CAN interface, spaced by the timestamps in the file. It is how a fault recorded on a boat gets reproduced on a bench, in front of the screens and daemons that misbehaved.

It is the only mode in this package that transmits. Everything else here only listens. Read the next section before using it.

Safety

Replaying a capture on a boat's live bus injects real frames that real devices act on. The recorded frames are indistinguishable from live ones: a recorded command frame commands, a recorded state frame contradicts the device that is actually sending that state.

• Never replay onto the boat's own bus. Use a bench bus, a spare interface, or a virtual one.

• A virtual interface is the safe default and needs no hardware:

  sudo modprobe vcan
  sudo ip link add dev vcan0 type vcan
  sudo ip link set up vcan0

• Replay is a hand-run mode. Neither systemd unit passes --replay, and neither should: a unit with Restart=always would restart the replay every time it reached the end of the file.

Running it

muxen-can-datalogger --interface vcan0 --replay /path/to/can0.3.log

In another terminal:

candump vcan0

-r is the short form and is the one to prefer:

muxen-can-datalogger -i vcan0 -r /path/to/can0.3.log

The process reads the file from the beginning, publishes each frame, waits the difference between consecutive timestamps, and exits when it runs out of lines. There is no loop option and no speed control.

Compressed captures have to be expanded first — the replay reader does not decompress:

gunzip -k /var/lib/muxen/datalogger/can0.3.log.gz
muxen-can-datalogger -i vcan0 -r /var/lib/muxen/datalogger/can0.3.log

Replay does not record

Passing --replay switches reception off. The process does not open a capture file, does not touch the log folder and writes nothing. So a replay session cannot be captured by the same process — run a second recorder, on the replay interface, if you want the replayed traffic on disk:

mkdir -p /tmp/replay-capture
muxen-can-datalogger -i vcan0 -l /tmp/replay-capture &
muxen-can-datalogger -i vcan0 -r ./can0.3.log

What replay reproduces, and what it does not

Replay is a proof of concept — that is the wording CHANGELOG.md uses when it introduces the mode in 2.1.0. It is useful for "does this sequence of identifiers at this rate make the screen do the wrong thing". It is not a faithful reproduction of a capture.

What it does reproduce:

• The identifiers, read as hexadecimal from the 0x… field.
• The frame lengths.
• The timing, to a millisecond, from the differences between consecutive timestamps. A gap in the capture is a gap in the replay.

What it does not reproduce:

• The data bytes. The reader parses them with a base-detecting conversion, and the file writes them as bare hexadecimal — 0D, B7, 1F. Anything containing a letter converts to zero, and a value like 16 converts to decimal sixteen rather than the 0x16 the capture recorded. Only bytes that happen to be plain decimal digits survive intact.
• Remote-transmission frames. The recorder writes them as xr, and the reader sets the extended flag for anything beginning with x without restoring the RTR flag. The source carries an unresolved question on that line.
• The final frame of the file, which is read and then never published — the reader publishes each frame on the following step, and the loop ends on the read that fails.
• Direction and channel. Everything replays as a transmission on the interface given to --interface.

Because of the data-byte limitation, treat replay as a traffic-shape tool rather than a data tool. If you need the payloads back, read the capture with zgrep, awk or a script against File formats, and send them yourself with cansend.

Reading the file

Replay accepts the format the raw recorder writes, and by extension files written by BUSMASTER itself. Concretely:

• Lines beginning with * are skipped, which covers the whole header and footer.
• A data line must have at least six space-separated fields. The first line with fewer ends the replay silently, so a truncated capture — one left open by a power cut, for instance — replays up to the truncation and then stops.
• Trailing fields beyond the declared length are ignored.

When nothing happens

A replay that produces no traffic at all and never exits is almost always a path problem. The startup check for the replay file cannot fire — the condition it tests is never true — so a missing or unreadable file is not reported. The failure to open it afterwards is not checked either, and the process ends up running with nothing to read and no reason to stop.

ls -l /path/to/capture.log      # does it exist, is it readable
head -3 /path/to/capture.log    # is it the expected format

Also confirm the target interface is up (ip link show vcan0) and that candump on it is running before the replay starts — the beginning of a file goes past quickly.