[Ovmsdev] PCAP CAN bus dump

[Mark Webb-Johnson]

Tom,

In wireshark, if you right-click on the Controller Area Network decoder, Protocol Preferences, you get the option to ‘byte-swap the can id …’. It seems the decoder doesn’t pick it up from the headers properly, and requires you to manually define it.

Regards, Mark.

> On 27 Apr 2018, at 4:35 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Tom,
> 
> Perfect. Thanks.
> 
> https://wiki.wireshark.org/Development/LibpcapFileFormat <https://wiki.wireshark.org/Development/LibpcapFileFormat>
> 
> magic_number: used to detect the file format itself and the byte ordering. The writing application writes 0xa1b2c3d4 with it's native byte ordering format into this field. The reading application will read either 0xa1b2c3d4 (identical) or 0xd4c3b2a1 (swapped). If the reading application reads the swapped 0xd4c3b2a1 value, it knows that all the following fields will have to be swapped too. For nanosecond-resolution files, the writing application writes 0xa1b23c4d, with the two nibbles of the two lower-order bytes swapped, and the reading application will read either 0xa1b23c4d (identical) or 0x4d3cb2a1 (swapped).
> 
> For your samples:
> 
> $ file *.pcap
> 2016-24kWh-ev-on-drive-park-off.pcap:                                      tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)
> 2016-24kWh-ev-plug-in-charge-timer-causes-sleep.pcap:                      tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)
> 2016-24kWh-ev-plugged-in-charge-timer-override-pressed-charge-unplug.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)
> 
> $ hexdump -C <2016-24kWh-ev-on-drive-park-off.pcap|head -6
> 00000000  d4 c3 b2 a1 02 00 04 00  00 00 00 00 00 00 00 00  |................|
> 00000010  00 00 04 00 e3 00 00 00  97 a3 2f 5a 0c 86 09 00  |........../Z....|
> 00000020  10 00 00 00 10 00 00 00  00 00 06 05 01 ff ff ff  |................|
> 00000030  00 00 00 00 00 00 00 00  97 a3 2f 5a 22 86 09 00  |........../Z"...|
> 00000040  10 00 00 00 10 00 00 00  00 00 06 79 01 ff ff ff  |...........y....|
> 00000050  00 00 00 00 00 00 00 00  97 a3 2f 5a 37 86 09 00  |........../Z7...|
> 
> Given that the first CAN message is ID 0x605, that seems wrong. Little endian it should be 05 06 00 00, not 00 00 06 05. So your utility swapped just the data packet headers little -> big.
> 
> Maybe the wireshark can bus decoder doesn’t support little endian? I think for safety, I’ll output in big endian for everything.
> 
> Regards, Mark.
> 
>> On 27 Apr 2018, at 1:58 PM, Tom Parker <tom at carrott.org <mailto:tom at carrott.org>> wrote:
>> 
>> https://carrott.org/pcaps/ <https://carrott.org/pcaps/>
>> 
>> These were captured with tcpdump and an USB can interface with slcan driver. I post processed them to byte swap the can ID with https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian-swap.py
>> 
>> I don't know why tcpdump and wireshark disagree on the byte order of the can id.
>> On Apr 27, 2018 5:24 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>> 
>>> 
>>> Has anybody got an example of a PCAP format canbus dump file? Some dump from a car in a suitable format for loading into wireshark (pcap not pcapng).
>>> 
>>> If so, please eMail to me (mark at webb-johnson.net) or give me a link to where I can download from.
>>> 
>>> I need it to verify that OVMS can read/write to that format.
>>> 
>>> Thanks, Mark.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180427/32bf559f/attachment.htm>