[Ovmsdev] ODB CAN message decoder?

[HONDA S-2000]

I might be on the wrong wavelength, but I don't understand how you expect Wireshark or tcpdump to know the endianness of the data in the packets.

My understanding is that these tools work with network traffic which is, by definition, transferred in network order. Network order is big endian. However, that only refers to multibyte values that are part of the networking headers, not the content of the data itself.

If you send little-endian data over the network, then Wireshark and tcpdump will show the data in little-endian order. That's because the packet contents can be a byte stream, and the network API have no way of knowing where the multibyte boundaries are so that the byte order could be changed.

In other words, a CAN bus is a serial byte stream. If that data is sent over TCP/IP, there's no defined order for the bytes other than the order that they appear on the CAN bus itself. Wireshark and tcpdump cannot swap bytes in words without a definition of the word boundaries. The TCP/IP link should be transparent with regard to the order of the bytes in any byte stream transferred over the ethernet.

It looks like CAN is a big-endian bit stream, but the various word lengths are not always multiples of 8 bits. There're 11-bit, 4-bit, 8-bit, and 15-bit fields.

There might be plugins for Wireshark that could decode these packets, but I'm not familiar with any.

Brian


On Feb 6, 2017, at 3:16 AM, Tom Parker <tom at carrott.org> wrote:
> I'm using an slcan device with socket can on linux and I've found that wireshark and tcpdump record the CAN frame id with the wrong endianess. Does the output of candump agree with what you are seeing in wireshark?
> 
> I wrote some simple tools for manipulating pcaps.
> 
> https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian-swap.py fixes the endian bug I'm seeing (only tested on 11 bit identifiers).
> https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-histogram.py promises a histogram but disappoints by giving a table. Also it filters by a hard coded nissan leaf frame id.
> https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-state.py prints the last frame seen for each frame id, this is good for looking at two captures and finding which frames are new
> https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-to-canplayer-binary.py converts a pcap into the semi-binary format that canplayer uses. Useful to play back a pcap file.
> 
> Most of these tools operate on stdin and stdout. None of them are documented, sorry.
> […]
> Unfortunately Can4python doesn't support remote request frames, but maybe your RTR frames are actually regular frames misinterpreted due to the endianess bug?