Размышления на тему блокировки CAN bus Опции

[_3m]

Реализую драйвер линукс Can, в процессе возникли мысли о том что шина в ряде ситуаций может быть завешена наглухо. Хотелось бы понять как минимизировать вред от таких ситуаций.

Рассмотрим случай 1: ретрансмисии + bus-off
Есть узлы 1 и 2, они обмениваются пакетами в обе стороны, т.е
1<---->2. Других узлов нет.
Теперь внешним воздействием (придурки!) во время работы кабель разрывается, причем так что шина на стороне 1 оказывается оборвана и на стороне 2 закорочена, т.е так:
1----X |----2.
На узле 1 возникает No ack error, которая приведит к ретрансмиссии.
Узел 2 преходит в Bus-off.
В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.
Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность.
Теперь 1 флудит ретрансмиссиями а 2 пытается выполнить процедуру bus-off recovery для которой требуется 128*11 рецессивных бит. Очевидно что 2 никогда не выйдет из bus-off а 1 никогда не получит ack. Глухой завис. А теперь представим что узел 1 физически или организационно недоступен. Все, можно стреляться.

Случай 2: проблема приоритетов
При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю.
Использовать режим обработки передающих мэйлбоксов с учетом приоритета id в общем случае невозможно потому что протокол высокого уровня ожидает поступление пакетов в определенном порядке и драйвер физики менять этот порядок не имеет права.