Custom Packet Sniffer Is A Great Way To Learn CAN

Whilst swapping out the stereo in his car for a more modern Android based solution, [Aaron] noticed that it only utilised a single CAN differential pair to communicate with the car as opposed to a whole bundle of wires employing analogue signalling. This is no surprise, as modern cars invariably use the CAN bus to establish communication between various peripherals and sensors.

In a series of videos, [Aaron] details how he used this opportunity to explore some of the nitty-gritty of CAN communication. In Part 1 he designs a cheap, custom CAN bus sniffer using an Arduino, a MCP2515 CAN controller and a CAN bus driver IC, demonstrating how this relatively simple hardware arrangement could be used along with open source software to decode some real CAN bus traffic. Part 2 of his series revolves around duping his Android stereo into various operational modes by sending the correct CAN packets.

These videos are a great way to learn some of the basic considerations associated with the various abstraction layers typically attributed to CAN. Once you’ve covered these, you can do some pretty interesting stuff, such as these dubious devices pulling a man-in-the-middle attack on your odometer! In the meantime, we would love to see a Part 3 on CAN hardware message filtering and masks [Aaron]!

16 thoughts on “Custom Packet Sniffer Is A Great Way To Learn CAN

  1. Learning CAN in the automotive context is sort of like learning the Latin alphabet. Every manufacturer has their own language built on top of it. Furthermore there are regional dialects layered on top of that for many distinct vehicle models and car families. FCA vs Ford maybe like Italian vs English – both Latin alphabets. Mustang vs F150 is more like modern Australian slang vs 16th century Shakespearean English.. And most vehicles have a half-dozen isolated CAN busses – all with a different data dictionary.

    Then there is Flex CAN, single-wire GM-LAN, and other variations. And CAN is quickly being replaced by MOST (EU) and Ethernet AVB (NA) for higher bandwidth transport needs in the vehicle.

    1. CAN will be around for a long time, whether in cars or elsewhere (it is an industry standard that is widely used) – the electrical robustness and relative simplicity are hard to beat. MOST and Ethernet AVB are mostly targeting multimedia streaming (e.g. camera image, audio, video distribution within the vehicle) but the control connections for things like the engine ECU, dashboard buttons and gauges, etc. are still CAN and going to remain CAN (or some similar protocol).

  2. I’ve been hunting for info I’ve the last week to do exactly what he is doing with that same radio into the same car for my daughter!

    Intermittently the radio stopes the car from going to sleep and drains the battery- I’m off to dissect his video and work and hopefully solve my problem as well …

    1. Yes good point. I think the external chip has very good Arduino libraries and support so that helps because configuring CAN using standard ARM libraries is not super easy. Infact, sparkfun used to make a CAN shield for the Arduino with that hardware so I suspect a lot of code already exists.

  3. I have been using Teensy 4.0 with two TJA1055 Low speed faut tolerant CAN transcievers to make can gateway and being able to sniff, what is control unit behind sending.

  4. I went thru the same journey when trying to integrate a similar chinese android radio into my older 2010 Chrysler T&C with dual rear video system. Built a CanHacker compatible arduino+mcp2515 sniffer.
    You need to know the “canbox” (the dark grey dongle hanging from the dvd unit) is a device that translates the can bus to a serial command set understood by the android dvd’s “mcu” (yes the android system has a mcu that controls the mux and majority of the low level functionality of the dvd system which then talks to android, alot of things are not done in android).
    This allows the dvd unit makers to sell the same (almost) dvd unit for many different cars by simply shipping a different “canbox”.

    I sniffed the data coming from the oem entertainment system and the car and eventually figured out most of the control packets for the video and other things.
    I also sniffed the data from the canbox to the car.

    Finally I ended up building a can interceptor/mitm device based on the esp32 (it has 1 built in can bus, making it easier to do mitm at the speeds needed by my car)
    This allowed me to change the packets from the canbox to the car and vice versa.

    In my case the canbox was sending a packet that would force my entertainment system to turn off, so I modified the packet.
    But why stop there?
    I used the Bluetooth capability of the esp32 to then make an android app that can configure the esp32 settings of my program to control fade of the vans built in amp (its controlled via can bus), control what video goes to which rear screen, and a few other things the car does – oh and to also read some pid’s the car is sending and present it on the android screen.

    A byproduct is also I was able to get the oem dvd player running on my bench and unlocked some features that you normally need a $200 3rd party dongle to do.

    Ive been meaning to do a few blog entries on the above but its always so time consuming to make proper articles compared to just writing code and tinkering.
    If anyone has any questions or wants some pictures reply/email and I will try and send what I have.

    PS I also replaced the (ugly to me) analog clock on the T&C to a digital unit and looks oh so nice.

    1. Oops, this was meant to be a reply to the first post.

      As a more general remark. I find it strange Sigrok / Pulseview is not mentioned here. This FOSS Logic Analyser software can be bundled with EUR7 hardware to sniff CAN and more then 100 other protocols.
      I’m getting more and more convinced that most hobbyists do not recognize the power of logic analysers for debugging microcontroller stuff.

      It’s sort of “printf( )” on steroids. If you’ve got some unused serial interface on your microcontroller you can easily put out a byte on for example each function entry (sort of like assert) and on entry of ISR routines, to check if they are triggered and if they are triggered in the right time. This way you line up this debug trace with for example what happens on the CAN bus, and you can look back in history what happened in what order.

      Sigrok / Pulseview together with a Saleaeae of UsBEE clone should be part of each “arduino” beginners kit.
      There is no “intellectual property” conflict, as the CY7C68013A has no flash of it’s own, always has to download firmware from USB, and Sigrok comes with fx3lafw which is completeley rewritten for SDCC.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.