What Is Bus-Off on a Car Network? CAN Bus-Off Faults Explained
Bus-off is a protective state built into the Controller Area Network (CAN), the data network that lets many of a car's electronic modules share information. When a module finds that its own transmissions keep failing, it eventually stops sending entirely so it cannot disrupt the rest of the network. Knowing what bus-off means on a car network, why a CAN bus-off fault happens, and how technicians trace it helps explain many confusing warning lights and communication codes.
Communication error: how a CAN module reaches bus-off
On a CAN network, modules (often called nodes) broadcast messages over a shared pair of wires, usually labeled CAN high and CAN low. Every node listens to every message and checks it for problems. The protocol includes several built-in error checks, such as monitoring that each transmitted bit appears on the bus as intended, verifying a checksum, confirming the message structure, and confirming that at least one other node acknowledged the message. When any node detects a violation, it sends an error frame that cancels the message so it can be sent again. This prevents corrupted data from being used, but the network also needs a way to stop one faulty node from flooding the bus with errors indefinitely.
That mechanism is called fault confinement. Each CAN controller keeps two counters: a transmit error counter and a receive error counter. Errors raise these counters faster than successful messages lower them. Under the CAN specification, a transmit error typically adds eight to the transmit counter, while a successful transmission subtracts one. While both counters stay below 128, the node is error-active and participates normally. Once either counter reaches 128, the node becomes error-passive: it still communicates, but it signals errors in a way that does not disturb other traffic and it must pause briefly between its own transmissions. If the transmit error counter climbs past 255, the node enters the bus-off state.
Because bus-off is driven by transmit errors, it identifies a node that keeps failing when it tries to send. The cause may be inside that module, such as a damaged transceiver, but it can just as easily be wiring, connector, or power problems that corrupt everything the module transmits. In other words, bus-off is the result of persistent communication errors, not a diagnosis by itself.
Module isolation: what happens when a module goes bus-off
In the bus-off state, the CAN controller stops transmitting and no longer acknowledges messages from other nodes. The module may still be physically connected to the wires, but it is logically silent. This self-isolation is the point of the design: if one module has a hardware fault or is disturbing the bus, removing it from active communication gives the remaining modules a chance to keep exchanging data. It is a key reason a CAN network can often tolerate a single misbehaving node without every connected system failing at once.
Leaving bus-off is not instant. The CAN protocol requires the controller to observe 128 occurrences of 11 consecutive recessive bits, which indicates that the bus has been idle and healthy, before it resets its counters and rejoins as an error-active node. When that recovery process is allowed to start is decided by the module's software. Some designs attempt recovery automatically after a short delay, some use progressively longer delays after repeated bus-off events, and others may stay silent until a later reset such as an ignition cycle. These strategies are chosen by the vehicle and module manufacturer, so behavior varies between vehicles.
The rest of the vehicle notices the silence. Many modules expect certain messages to arrive at regular intervals, and when they stop, receiving modules may use default values, disable functions that depend on the missing data, and store lost-communication codes. A driver might therefore see warning lamps, inactive gauges, or disabled features in systems that are working perfectly well themselves. A short across the entire bus is a different situation: it can disrupt communication for many modules simultaneously rather than isolating just one.
Diagnosis: tracing a CAN bus-off fault
Diagnosis usually starts with a full scan of every module using a scan tool capable of reaching the vehicle's networks. Network-related trouble codes generally begin with the letter U. Some manufacturers use codes that refer directly to a bus-off condition, while others report lost communication with a particular module. The pattern across modules matters more than any single code. If several modules report losing contact with the same module, that module, its power and ground supply, or its branch of wiring becomes the main suspect. If a module stores its own bus-off events, it indicates that it struggled to transmit. Occurrence counts and stored conditions, where available, help show whether the fault is ongoing or intermittent.
Physical checks follow. Many communication faults come down to basics: low supply voltage, poor grounds, corroded or loose connectors, chafed wiring, or water intrusion. Many high-speed CAN networks use two 120-ohm termination resistors at the ends of the bus, so with the battery disconnected, resistance between CAN high and CAN low at an accessible point such as the diagnostic connector often reads about 60 ohms. A reading near 120 ohms can point to a missing termination or an open circuit, while a very low reading can point to a short. Termination layout and expected values are vehicle-specific, so the service information should confirm them. An oscilloscope shows distorted, noisy, or stuck signals that a multimeter cannot reveal.
Isolation testing is often the final step: disconnecting modules or inline connectors one at a time while monitoring the bus to see whether the errors stop. Aftermarket devices connected to the diagnostic port or spliced into vehicle wiring deserve early attention, because a device transmitting at the wrong speed or with a faulty transceiver can generate errors on the network. Following the manufacturer's procedure matters here, since unplugging some modules can set additional codes or require relearn steps afterward.
Practical implications and limits
For owners, the most useful takeaway is that a bus-off related code describes communication health rather than proving a module has failed. Replacing the module named in a code without first checking its power, ground, and wiring can cost money without fixing anything. Clearing codes may make warnings disappear for a while, but if the underlying condition remains, the module is likely to return to bus-off once errors accumulate again. Intermittent faults linked to vibration, temperature, moisture, or low voltage during engine cranking can be hard to reproduce, so noting when symptoms appeared gives a technician valuable clues.
Bus-off is specifically a CAN concept. Modern vehicles may also use other networks, such as LIN, FlexRay, or automotive Ethernet, which handle errors in their own ways, so the term does not apply to them in the same sense. Many vehicles also divide CAN into separate segments joined by a gateway module, which can keep a problem on one segment from directly affecting the others. Recovery timing, code names, gateway routing, and which features shut down all depend on the specific vehicle design, so this general explanation is a starting point, while an actual repair should rely on the manufacturer's service information.
Finally, the impact of a bus-off condition depends on which module is affected. A silent convenience module may only disable a minor feature, while lost communication involving braking, steering, or powertrain systems can trigger multiple warnings and reduced functionality. When warnings involve safety-related systems, having the vehicle inspected before continuing to drive is the sensible course.