OBD-II and ELM327 (5), what happened if CAN bus had something bad

In previous article, I've described how to use Pi-WIRE to do MITM attack. In this article, let's talk about the pitfall I encountered during making these tools -> analyzing what happened if bad electronics attach to CAN bus. With the story, you can judge whether attaching OBD2 dongles (ELM327, HUD) to the car is OK or NOT; or what to notice

To build the tool, I bought several CANBUS modules from China. To save money, I bought cheap electronics to torture myself:
  • WaveShare RS485 CAN HAT * 2
  • Niren MCP2515 CAN Module * 2
    • CHEAP_SUCK_MODULE


Using verified modules (ELM327) to validate unverified tool (Pi-CAR) is important techniques. As the raspberry Pi connecting to CHEAP_SUCK_MODULE, I encountered trouble immediately
  • ELM327 sends 0902 by 8 bytes, 09 02 00 00 00 00 00 00
    • With CHEAP_SUCK_MODULE, I can't receive long packet definitely
  • I can use "ATCAF0" to avoid ELM327 sending 8bytes, which becomes short packet
    • 09 02
  • However, short packet reception with CHEAP_SUCK_MODULE is not guaranteed to survive
    • Sometimes it's OK
    • Sometimes it will re-transmit
    • Sometimes it's just dead

I checked the problem with scope by checking CAN-H with inverse enabled. The picture below includes the 1st transmission, error frame and the 2nd transmission

  • In the 1st transmission, ELM327 sends 0902
    • In reality, it sends 0x7E8 [2] 0x09 0x02
    • 0x7E8 is industrial standard, ISO15765. If you wanna talk to ECU, this is the start point
    • CANBUS supports bit-stuffing to achieve synchronization among modules
      • Bit stuffing: One bit-1 is inserted after 5x continuous bit-0; one bit-0 is inserted after 5x continuous bit-1
  • Error frame, CHEAP_SUCK_MODULE felt something wrong, it asked bus to wait
    • As the picture shown, the CANBUS stopped 40us !!
  • ELM327 does re-transmission after error frame. Finally CHEAP_SUCK_MODULE responded , and completed transmission

What's wrong with CHEAP_SUCK_MODULE? It turned out that the 8M crystal oscillator is not precise as marked (7.77M). What the fuck! I bought some development tool to repair. Well, I replaced it with 16Mhz crystal to repair CHEAP_SUCK_MODULE, and boost the performance a bit



Anyway, toggling error frame and re-transmission is also learning
  • Every node on CANBUS shall monitor every packet. Receive it if cares, or just drops
  • CHEAP_SUCK_MODULE does not feel good because it had wrong clock. So it sends error frame to halt the bus\
    • All CANBUS loses 40us
    • If CHEAP_SUCK_MODULE complains every time, then CANBUS will stop working

There're probably many factors to make CANBUS fail to work. The vendor typically picks up parts carefully. However, it ages ultimately. For example, high temperature causes frequency drift. Car owner knows the "service required" appearing on dashboard, but it requires effort to locate the problem

CANBUS re-transmission can hide errors. Something (for example HUD) seems working (showing speed/RPM correctly). However, if it throws error frame, it might cause CANBUS fail. Therefore, attaching items to CANBUS means take risk. Pay more to buy high quality hardware avoids potential troubles



The picture above showed the CANBUS status in Linux. It had some statistics: RX/TX packets, error number. Maybe this can be some meaningful metric to measure CANBUS quality

Comments

Popular posts from this blog

OBD-II and ELM327 (1)

OBD-II and ELM327 (3), try to decode CAN package recorded by ELM327

OBD-II and ELM327 (2), the underlying interface of ELM327