CAN Bus-Off Recovery: Give One Layer Ownership of Restarting the Controller
Choose one restart owner per CAN interface and keep controller recovery separate from application readiness. Either the configured kernel timer owns automatic bus-off restart, or one supervisory component requests it after diagnosis. Competing scripts and application retries make the history harder to interpret without repairing the underlying fault.
This guide pins Linux v6.12’s common CAN-device recovery helpers. The selected controller driver must actually use the relevant path. It does not specify electrical recovery for an unnamed controller or authorize fault injection on an operating machine. No CAN hardware or restart test was executed.
1. Establish the configured owner
The SocketCAN guide describes automatic recovery through a nonzero restart-ms setting and application-managed restart as an alternative. Bus-off prevents normal communication; the recovery policy must account for the resulting unavailable interval.
Read the effective interface settings and save the kernel, driver, controller and firmware identities. Check boot configuration, network management, service scripts and applications for every component that could change the interface or request recovery. A saved configuration file is not proof of the current owner.
| Policy | Owner’s responsibility | Important boundary |
|---|---|---|
| Automatic timer | Kernel performs the configured restart attempt | Delay is not a diagnosis or a guaranteed stable return |
| Supervised restart | One coordinator evaluates evidence and requests recovery | Coordinator must handle absence, failure and concurrent state change |
| Hold for service | Authorized service procedure controls further action | Applications must expose unavailable data and unresolved commands |
Select the policy from the product’s availability and fault-response requirements. Do not choose the shortest interval merely because it makes the interface appear online more often.
2. Respect the manual restart gate
In can_restart_now(), automatic restart enabled yields -EINVAL; a state other than bus-off yields -EBUSY. Only the eligible path invokes the common restart helper.
Handle these outcomes as state/policy observations, not permission to repeatedly reconfigure the interface until a command succeeds. Reconcile the effective owner and current state. A supervisor acting on an old event may legitimately find that another approved transition has already occurred.
Give each incident an identity tied to the interface instance and observed bus-off transition. Prevent delayed recovery work from an earlier incident from modifying a newly configured or replaced interface.
3. Do not overread the restart notification
The common restart helper attempts to emit CAN_ERR_RESTARTED before calling the driver’s start operation. Callback failure turns carrier off; callback success increments the restart counter. Notification allocation can also fail.
Therefore a restart event alone is not evidence that the driver successfully restarted, and absence of the event is not conclusive evidence that no attempt occurred. Correlate available state, counters, diagnostic output and later valid traffic.
Likewise, the manual helper’s zero return is not a separately propagated success result from that driver callback. Keep request acceptance, attempted restart, controller state and useful application exchange as distinct observations in the supervisor.
4. Preserve evidence before another attempt
Capture the first bus-off indication, recent controller-state changes, available error counters, interface configuration and relevant application deadlines. Record unavailable diagnostics explicitly. A driver or adapter may expose less than the generic API permits.
Use monotonic event ordering and a bounded log. Do not clear the only useful evidence by repeatedly cycling the interface. Retain a before/after snapshot for each authorized attempt, including the recurrence interval rather than only the final state.
Error notifications require the appropriate receive subscription. A data-only consumer that never requested error events cannot use its empty error log as proof that recovery was uneventful.
5. Define a bounded recurrence response
Create an original supervisor policy with an observation window, a recurrence threshold, an escalation destination and a permitted recovery mode. The actual values must come from product requirements and qualification; there is no universal safe restart budget.
If using automatic restart, recognize that the timer itself is not a bounded recurrence counter. Any escalation or hold behavior needs an explicitly designed, authorized integration. Do not describe that additional policy as an upstream feature.
| Observation | Next decision |
|---|---|
| One attempt followed by stable valid communication | Evaluate the application’s resynchronization requirements |
| Restart notification followed by callback failure | Remain unavailable; preserve the failure and investigate |
| Repeated bus-off shortly after restart | Escalate under the bounded recurrence policy |
| Controller active but application state stale | Keep service degraded until required fresh state is acquired |
| Conflicting recovery owners | Reconcile configuration before interpreting repeated attempts |
6. Qualify recovery without replaying uncertain commands
Use a controller model or a recoverable isolated bench with inert application traffic. Test automatic mode, supervised mode, callback failure, repeated faults, missing notifications and a delayed supervisor action after the state changes.
Do not induce wiring faults on production actuators or use an unspecified controller reset recipe. Physical tests need exact controller/transceiver documentation, a controlled harness and an approved restoration procedure.
After communication returns, reacquire required current state and resolve outstanding operations through the application protocol. Restarting the controller does not establish whether a previously transmitted command executed. Do not replay such commands solely because the bus is active again.
Hypothetical double owner
A fictional gateway has automatic recovery enabled while a watchdog script also requests manual restart after every logged bus-off event. The script receives an eligibility error and repeatedly retries, creating noise that obscures the original fault.
The corrected design selects one owner and records separate attempt, controller and application states. Engineers can then distinguish failed recovery, recurring network faults and slow application resynchronization.
7. Release the ownership contract
Retain the effective policy, responsible component, exact driver path, evidence availability, recurrence response and resynchronization criteria. A recovery result should say which boundary has been established and which remains open. No timer value alone proves a healthy network.
