How CAN Bus Quietly Networks Every Modern Car

Every time you turn a key or press a start button, somewhere between thirty and a hundred small computers wake up and begin talking to each other. You don't know their names. You've never configured them. There's no router under the hood, no switch in the firewall, no administrator issuing IP addresses. There are two wires, a handful of rules, and a networking protocol that Bosch introduced publicly in 1986 and that the industry has trusted ever since.

That protocol is CAN — Controller Area Network — and a recent episode of Dave's Garage on YouTube makes a persuasive case that it deserves more attention than it typically gets from people who think about networks for a living.

Dave, who goes by davepl1968 on X and runs the channel with a hands-on, bench-first pedagogy, built a live demonstration using two ESP32 microcontrollers, a pair of CAN transceivers, and an engine control module pulled from a 2015 Corvette Z06 he sold years ago. The ECM sat on the workbench, powered up and connected to nothing but those two wires, "saying whatever a Corvette engine computer says when it wakes up alone on a workbench and discovers that everybody else has gone home without it." It's a good image. It's also a precise description of how the protocol behaves.

Two wires, no master

The first thing worth understanding about CAN is what it deliberately omits. There is no central controller arbitrating who speaks. There are no MAC address tables, no routing decisions, no acknowledgment from a specific destination. Every frame is broadcast onto the bus. Every controller receives every frame. Each one individually decides whether that frame is relevant to it.

This sounds inefficient until you consider the alternative. Ethernet in its original incarnation used the same shared-wire broadcast model, and when two devices transmitted simultaneously, the result was what the specification charmingly called a collision — combined signal garbage that forced everyone to stop, wait a randomized delay, and try again. The randomization mattered because two machines waiting the same fixed interval would simply collide again on schedule, "spend the afternoon politely headbutting one another," as Dave puts it.

CAN rejects this model entirely. Instead of resolving contention after the fact, it resolves it in real time, in the wire itself, without destroying either transmission.

The physics of priority

The mechanism is called non-destructive bitwise arbitration, and it rests on one electrical rule: a dominant bit (logical zero) always wins over a recessive bit (logical one). When a transmitter drives a dominant zero, it pulls CAN High up and CAN Low down, creating a voltage differential the receiver can't miss. When it sends a recessive one, it simply releases the bus and lets both wires settle toward their common-mode voltage. If any other controller is simultaneously driving a dominant zero, the bus shows zero regardless.

Every CAN message begins with an identifier — 11 bits in standard CAN, 29 in extended — that describes the message type rather than the sender. Engine speed gets one ID. Coolant temperature gets another. Brake status gets a third. Lower numerical identifiers carry higher priority. When two controllers begin transmitting at the same instant, they both put their identifiers onto the bus starting from the most significant bit. As long as they're sending identical bits, neither knows there's competition. The moment they diverge, the controller that sent a recessive one reads back a dominant zero from the bus and immediately knows it has lost. It stops transmitting and waits.

"The network does not merely discover which message is higher priority," Dave explains. "The wires actually calculated it."

That distinction is worth sitting with. No software arbitration. No interrupt handler deciding who goes first. The comparison happens in the physics of the shared wire, in real time, at the speed of the signal itself. The winning frame continues without interruption, without retransmission, without having been corrupted at all.

The practical consequence is deterministic scheduling. Brake status will always outrun climate control status. Wheel speed will always outrun seat position. In a car traveling at highway speed, this ordering is not merely convenient — it's the kind of property that safety engineers require in writing before a system goes into production.

What CAN doesn't know

Here's where the architecture introduces a complication that the protocol itself cannot solve.

CAN specifies exactly how a frame reaches the wire, how arbitration resolves contention, how errors get flagged, and how faulty controllers get progressively demoted and eventually silenced. What it does not specify is what the bytes inside a frame actually mean. That knowledge lives in higher-layer protocols or, in most production vehicles, in manufacturer-private databases.

Attach a CAN analyzer to an unfamiliar vehicle and you'll see a beautifully structured stream of hexadecimal frames arriving in perfect order. You can watch a byte change value as someone presses the accelerator. You cannot necessarily know which byte it is, what the scaling factor is, or which bits to ignore. Dave's description of this is accurate: "You know the language's alphabet and grammar but you don't yet have its dictionary."

This opacity cuts both ways. It's part of why reverse-engineering vehicle behavior for diagnostics or modification requires significant effort — the Right to Repair debate in automotive contexts is partly a fight over who gets access to those private databases. It's also part of why CAN's security model is structurally limited.

The trusted-network assumption

Traditional CAN has no authentication. A controller that knows the correct identifier and payload format can impersonate any legitimate module on the network. Other controllers see a valid identifier, a valid CRC, and a correctly structured frame. They have no mechanism to verify the source.

Dave acknowledges this directly and without apology. CAN's designers in the 1980s were building a physically enclosed, trusted network for a small number of known components designed by one manufacturer to cooperate with each other. That assumption was entirely reasonable for the problem they were solving. As he notes, the security picture changed when those closed networks acquired diagnostic ports, wireless infotainment systems, cellular modems, and aftermarket OBD dongles: "CAN is simple because it knows where its universe ends. Security problems begin when we quietly move that boundary."

This is not a hypothetical concern. Researchers Charlie Miller and Chris Valasek demonstrated in 2015 — reported extensively at the time by Wired — that they could remotely control a Jeep Cherokee's brakes and steering through its cellular connection, ultimately reaching the CAN bus. The vulnerability wasn't in CAN itself. It was in the assumption that a network designed for trusted components would remain isolated from untrusted networks. Once that isolation broke down, CAN's lack of authentication became consequential.

The auto industry has responded with CAN FD (Flexible Data-rate), which supports higher bandwidth, and with gateway modules that police traffic between network segments. Automotive Ethernet is appearing in higher-bandwidth applications. But the original CAN bus, and the trust model it assumes, remains the backbone of most production vehicles on the road today.

Error handling that banishes bad actors

One aspect of CAN that rarely gets enough attention is its fault confinement mechanism. Any controller can detect a malformed frame and broadcast an error flag that invalidates it for everyone. This sounds like it could be exploited — a single broken controller objecting to everything and freezing the bus. CAN addresses this by maintaining error counters for each node. Repeated error transmissions escalate a controller from error-active to error-passive and ultimately to bus-off, where it's excluded from transmission entirely. The network effectively banishes the troublemaker without human intervention.

Dave's summary of this is compact: "It's a tiny distributed society with arbitration, proofreading, public rejections, and eventually banishment — all without a central authority."

The limitation is that this mechanism handles electrical faults and protocol violations. A controller transmitting valid, correctly formatted frames with a high-priority identifier is not misbehaving from CAN's perspective, even if it's flooding the bus and starving lower-priority nodes. The protocol assumes good faith in a way that maps cleanly onto a factory-controlled hardware environment and less cleanly onto a world where aftermarket hardware plugs into the diagnostic connector.

Why it's worth understanding

Most people who own modern vehicles interact with CAN every time they drive. The dashboard isn't a collection of gauges connected to sensors — it's a display node subscribed to a broadcast network. The check engine light isn't a wire from the engine; it's a message with an identifier and a payload. The reason a scan tool plugged into the OBD-II port can read fault codes is that the diagnostic connector bridges directly onto the CAN bus.

Understanding the architecture changes what you can do with a malfunction. It also changes what you should think about when someone offers to plug an inexpensive aftermarket dongle into that port for insurance monitoring or remote diagnostics. That port is, as Dave's demonstration makes clear, a direct electrical connection to every safety-critical system in the vehicle.

CAN turns 40 this year by the measure of its public introduction. It still networks your brakes. The question of how well we've thought through what else it's connected to is one the industry continues to answer, imperfectly, in real time.

---

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG