[Ovmsdev] ODB CAN message decoder?

[Greg D.]

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-swap.py
> 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-binary.py
> 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 at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev