Request for j1939dump and j1939player

[josemic]

This is a request for discussion for a j1939player, similar to canplayer, which can replay j1939 message.

For now it is assumed that the output of j1939dump is similar to j1939spy. With additionally the option to assemble j1939 TP and ETP messages as requested by this linux-can issue: Add russport to not interactively reassamble (E)TP messages #6
Additionally timestamps are needed, in order to keep the timing during replay.

I'd like to see a j1939player, which can replay messages based upon the J1939-NAME(s), optionally filtered by PGN(s). This would allow to test j1939 application message decoders e.g. of Isobus messages.

[marckleinebudde]

First we need a way to save complete (E)TP messages in user space. I see two options:

1. Extend the kernel's j1939 socket to receive (E)TP into user space without actively taking part in the communication.
2. Re-assemble (E)TP from a can-dump in user space.

[josemic]

Perhaps we have a third option (or is that the same as 2.?):

3. Have tool that postprocesses log files and reassembles (E)TP messages
   E.g.:

   j1939spy -P -b 4193977 vcan0 > myj1939dump.log
   cat myj1939dump.log | ETPandTPpostprocessor > myj1939dump_postprocessed.log
   j1939player -NAME 1122334455667788 myj1939dump_postprocessed.log

[marckleinebudde]

ACK, this is what I meant with 2.

[josemic]

One difference is that 1. is working for realtime tracing with tools too. E.g. a (to be written) wireshark j1939 decoder. While 2. will never work with realtime trace tools.
The benefit of 2 is, that it keeps the complexity out of the kernel.

[marckleinebudde]

If the kernel can re-assemble RAW CAN frames into j1939 (E)TP, this should also be possible in user space, too. Maybe it doesn't fit into the programming model of wireshark. On the other hand wireshark can decode TCP, which spans over sevel IP packages....

[josemic]

I think a j1939player needs to replay besides messages accoding to its name, all messages to global address (DA=0xFF) too.