<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Tom,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 27 Apr 2018, at 4:35 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Tom,<div class=""><br class=""></div><div class="">Perfect. Thanks.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><a href="https://wiki.wireshark.org/Development/LibpcapFileFormat" class="">https://wiki.wireshark.org/Development/LibpcapFileFormat</a></div><div class=""><br class=""></div><div class=""><div class="">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).</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">For your samples:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">$ file *.pcap</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">2016-24kWh-ev-on-drive-park-off.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">2016-24kWh-ev-plug-in-charge-timer-causes-sleep.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">2016-24kWh-ev-plugged-in-charge-timer-override-pressed-charge-unplug.pcap: tcpdump capture file (little-endian) - version 2.4 (SocketCAN, capture length 262144)</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">$ hexdump -C <2016-24kWh-ev-on-drive-park-off.pcap|head -6<br class="">00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|<br class="">00000010 00 00 04 00 e3 00 00 00 97 a3 2f 5a 0c 86 09 00 |........../Z....|<br class="">00000020 10 00 00 00 10 00 00 00 00 00 06 05 01 ff ff ff |................|<br class="">00000030 00 00 00 00 00 00 00 00 97 a3 2f 5a 22 86 09 00 |........../Z"...|<br class="">00000040 10 00 00 00 10 00 00 00 00 00 06 79 01 ff ff ff |...........y....|<br class="">00000050 00 00 00 00 00 00 00 00 97 a3 2f 5a 37 86 09 00 |........../Z7...|</span></font></div></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Maybe the wireshark can bus decoder doesn’t support little endian? I think for safety, I’ll output in big endian for everything.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 27 Apr 2018, at 1:58 PM, Tom Parker <<a href="mailto:tom@carrott.org" class="">tom@carrott.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><a href="https://carrott.org/pcaps/" class="">https://carrott.org/pcaps/</a><br class=""><br class="">These were captured with tcpdump and an USB can interface with slcan driver. I post processed them to byte swap the can ID with <a href="https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian-swap.py" class="">https://carrott.org/git/leaf-can-dissector.git/blob/HEAD:/pcap-canid-endian-swap.py</a><br class=""><br class="">I don't know why tcpdump and wireshark disagree on the byte order of the can id.<br class="">On Apr 27, 2018 5:24 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class="">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).<br class=""><br class="">If so, please eMail to me (<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>) or give me a link to where I can download from.<br class=""><br class="">I need it to verify that OVMS can read/write to that format.<br class=""><br class="">Thanks, Mark.<br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>