[Ovmsdev] ODB CAN message decoder?

[Tom Parker]

On 08/02/17 19:05, HONDA S-2000 wrote:
> 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.

Maybe I misdiagnosed the problem. The problem is that Wireshark decodes 
the CAN bus header using one endianness and tcpdump records it using the 
other. I'm not sure which is more correct.

The Linux SocketCAN system exposes the CAN bus to user space as a 
datagram socket. This way you can use tcpdump and Wireshark. The CAN bus 
frames are not passed over TCP.

Here is a frame with identifier 0x1d4 captured from my leaf with tcpdump 
and displayed in wireshark. The first line is as captured, the second is 
after byte swapping the header.

0000   d4 01 00 00 08 ff ff ff a0 6d 00 00 42 06 40 60 .........m..B.@`

0000   00 00 01 d4 08 ff ff ff a0 6d 00 00 42 06 40 60 .........m..B.@`

Wireshark thinks the un-swapped frame has the extended and remote 
transmission flags set because the first two bits are set. It thinks the 
id is 0x14010000 because it interprets the first 3 bits as flags, and 
the the rest as the identifier. The 0x08 is the length, followed by 
three padding bytes and then the actual payload data.

I use 
https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian-swap.py 
to fix these. I haven't tried to work out why I have this problem or how 
to fix it properly.

The SocketCAN candump utility has always given me correct results. Greg, 
does candump agree with wireshark on your system?