CAN Bus Packet Frame | Can Bus Packet Layout – Explained


There are two types of CAN packets: extended and standard. Extended packages are like standard ones but with a larger area (BITS) to hold IDs.
Standard Packets
Each CAN bus packet contains four key elements:
Arbitration ID The arbitration ID is a broadcast message that identifies the ID of the device trying to communicate, though any one device can send multiple arbitration IDs. If two CAN packets are sent along the bus at the same time, the one with the lower arbitration ID wins. Identifier extension (IDE) This bit is always 0 for standard CAN.
Data length code (DLC) This is the size of the data, which ranges from 0 to 8 bytes.
Data This is the data itself. The maximum size of the data carried by a standard CAN bus packet can be up to 8  bytes, but some systems force 8 bytes by padding out the packet.

can protocol

Because CAN bus packets are broadcast, all controllers on the same electronic network to see every packet, kind of like UDP on Ethernet networks. The packages don’t carry information about which controller (or attacker) sent what.

 Because any device can see and transfer packets, it’s trivial for any device on the bus to reproduce any other device.

 Extended Packets

 Extended packets are like standard ones, except that they can be chained together to create longer IDs. Extended packets are designed to fit inside standard CAN formatting to maintain backward compatibility.

 So if a sensor doesn’t have support for extended packets, it won’t break if another packet transmits extended CAN packets on the same network.

 Standard packets also differ from extended ones in their use of flags.

 When looking at extended packets in a network dump, you’ll see that, unlike standard packets, extended packets use substitute remote request (SRR) in place of the remote transmission request (RTR) with SSR set down to 1. They’ll also have the IDE set down to 1, and their packets will have an 18-bit identifier, which is the second part of the standard 11-bit identifier. There are additional CAN-style protocols that are specific to some manufacturers, and they’re likewise backward compatible with standard CAN in much the same way as extended CAN.

OCSALY