Linux CAN总线无限制重传问题咨询（基于SJA1000芯片）
首先明确：你观察到的无限制自动重传行为，本质是SJA1000芯片的硬件特性，而非Linux CAN内核的默认逻辑，但内核驱动的默认配置放大了这个行为，咱们一步步拆解：
1. 为什么会无限重传？
CAN协议本身设计了「自动重传机制」：当发送节点未收到总线其他节点的ACK应答时，会持续重传报文直到成功。而Philips SJA1000芯片默认开启了硬件层面的自动重传功能，Linux 4.14.48版本的sja1000驱动在初始化时没有修改这个默认配置。
当总线没有任何其他设备时，发送的报文永远得不到ACK，SJA1000就会一直重复发送——这个过程是由芯片硬件独立完成的，和用户进程是否存活无关。
2. 为什么进程关闭后重传还在继续？
当你调用write()发送CAN报文时，内核只是把报文提交到SJA1000的发送缓冲区，之后就返回给进程了。一旦报文进入硬件缓冲区，重传的控制权就完全交给了SJA1000芯片，即使用户进程退出，硬件也会继续执行重传逻辑，直到收到ACK或被手动干预。
3. 如何解决这个问题？
你的担忧非常合理：如果设备故障导致总线仅自身存在，持续重传会占满总线带宽，后续其他节点恢复时可能被干扰。可以通过以下方式处理：
修改硬件重传配置：
SJA1000的控制寄存器中有一个「自动重传禁止（AR）」位，将其设置为1即可关闭硬件自动重传。你可以修改sja1000驱动代码，在芯片初始化阶段设置该位；如果你的驱动版本支持模块参数，也可以通过加载驱动时传递no_auto_retry=1之类的参数（具体参数名可查看驱动源码的module_param定义）。应用层辅助处理：
由于CAN协议的ACK是硬件透明的，应用层无法直接感知报文是否发送成功。你可以在发送报文后，通过监听总线的回环报文（如果开启了回环模式）或者设置超时逻辑，若一定时间内未收到预期反馈，则认为发送失败并做相应处理。不过这种方式只能辅助判断，无法直接终止硬件重传，还是建议优先修改硬件配置。
4. 这属于正常行为吗？
从CAN协议规范和SJA1000芯片的默认设计来说，这是「符合规范的行为」，但显然不符合你的业务预期。Linux CAN内核本身没有强制限制重传次数，因为CAN协议的重传逻辑是由硬件实现的，内核只是做硬件适配——所以默认情况下会遵循芯片的出厂配置。
内容的提问来源于stack exchange，提问作者avl_sweden
