Hi Tom, Fixed! Thanks for your reply. Did some more digging into the packets, and got even more convinced that what I'm seeing was not real. That gave me a clue to look elsewhere, and in doing so, discovered that the CAN bus on the bench wasn't properly terminated (a missing jumper). Once I fixed that, I started seeing packets with an ID of 0x7DF, which IS listed in the documentation. YEA! Data portion is 02 01 00 00 00 00 00 00, which I decode as length = 2 bytes, 1 = "Show Current Data", which makes perfect sense. I guess the length includes the itself. I also see packets that I don't see info on, ID = 0x18DB33F1 and others, so there may still be work to do, but at least I now have some sense of sanity. They all have the same data (02 01), so apparently a different version (manufacturer?) of the same request. {shrug} Going to ignore them for now. Next step is to craft some sort of reply to the data request, and see what happens. BTW, Wireshark and candump do agree on the Identity portion of the CAN traffic, so it appears that I'm was not seeing an endian issue. Great try, however; never thought of that. Add terminators to your mental troubleshooting list. Thanks again for the help. Progress! Greg. Tom Parker wrote:
On 06/02/17 12:16, Greg D. wrote:
I currently have a Raspberry Pi with a PiCAN-2 board on top, lashed to either an OBDwiz module or a T-Mobile "SyncUp Drive" Wi-Fi hotspot. Wireshark running on the Pi captures the initial messages that the modules transmit (500kbps assumed). I need to find a table of what these messages translate to, so I can create a small program to provide suitable answers.
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-... 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-... 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.
You might capture without your obd module plugged in, and then capture again with it plugged in and look at what new messages are present by diffing the output of pcap-state.py on each capture.
I'm also working on a MitM for exploring how the Nissan Leaf car authenticates it's battery. I'm using can4python and I really like the kayak file format to describe the frames (much easier to understand than the wireshark dissector I made), see https://carrott.org/git/leaf-can-utils.git
Unfortunately Can4python doesn't support remote request frames, but maybe your RTR frames are actually regular frames misinterpreted due to the endianess bug? _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev