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-... 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@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@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.
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@carrott.org> wrote:
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-...
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@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@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.
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@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@carrott.org <mailto:tom@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-...
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@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@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.
Tom, PCAP support is now in (for RE). OVMS# re start OVMS# re serve format cap OVMS# re serve mode simulate # Capture over Wifi to pcap $ nc OVMS.local 3000 >my.pcap # Replay pcap over Wifi $ nc OVMS.local 3000 <my.pcap >/dev/null Seems to work ok, but I only support big endian micro-second resolution pcaps (at the moment). You’d need to fix byte ordering in the pcap header record to be able to replay your existing pcaps into it. I’ve tested some simulated captures, into Wireshark, and it seems fine for me. Will try in a real car tomorrow. Thanks for your help with the captures. Very helpful to see what is going on with a real example. Regards, Mark.
On 27 Apr 2018, at 1:58 PM, Tom Parker <tom@carrott.org> wrote:
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-...
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@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@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.
Greg, All good now. I wanted to support another format (binary) in the hopes that speed could improve (CRTD involves a lot of conversion), but really not impressed with the PCAP format - takes 24 bytes to store 1 CAN frame (which is almost the same as CRTD in a textually readable format. Haven’t done any speed tests yet. Are there any other standard CAN dump/log formats in popular use out there? I seem to remember some Nissan Leaf dumps out in the wild in some binary format, but never found out how to read them. Is this can-do? http://www.mynissanleaf.com/viewtopic.php?t=6088 But it seems a weirdly over-complex format, with no support for extended IDs (or at least as documented there)? Regards, Mark
On 28 Apr 2018, at 1:02 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
Sorry, I missed last night's request for this. I have a number of Wireshark traces during my development of the OBDII ECU code, taken on a Raspberry Pi with a PICAN-2 interface attached. They're saved in PCAPNG format, but I can load and resave them as needed, or take new ones if there's something in particular to capture.
Any need at this point?
Greg
Mark Webb-Johnson wrote:
Tom,
PCAP support is now in (for RE).
OVMS# re start OVMS# re serve format cap OVMS# re serve mode simulate
# Capture over Wifi to pcap $ nc OVMS.local 3000 >my.pcap
# Replay pcap over Wifi $ nc OVMS.local 3000 <my.pcap >/dev/null
Seems to work ok, but I only support big endian micro-second resolution pcaps (at the moment). You’d need to fix byte ordering in the pcap header record to be able to replay your existing pcaps into it.
I’ve tested some simulated captures, into Wireshark, and it seems fine for me. Will try in a real car tomorrow. Thanks for your help with the captures. Very helpful to see what is going on with a real example.
Regards, Mark.
On 27 Apr 2018, at 1:58 PM, Tom Parker <tom@carrott.org <mailto:tom@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-... <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@webb-johnson.net> <mailto:mark@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@webb-johnson.net <mailto:mark@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.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (3)
-
Greg D. -
Mark Webb-Johnson -
Tom Parker