Re: [Question] Sending CAN error frames

[Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>]

On Thu, 04 Feb 2021 13:13:18 +0900, Vincent MAILHOL wrote:
> Hi Kurt,
> 
> On Tues 4 Feb. 2021 at 05:06, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
> > On Wed, 03 Feb 2021 17:26:11 +0900, Vincent MAILHOL wrote:
> > > On Wed. 3 Feb 2021 at 15:42, Jimmy Assarsson <jimmyassarsson@gmail.com> wrote:
> > > > >
> > > > > Of course we might also provide some pump gun mode which just sends an error flag at some (any) time.
> > > >
> > > > As above.
> > > >
> > > > > But for what reason?
> > > >
> > > > Testing purpose, e.g if you develop software where you want to keep track of bus errors, this makes it possible to test such software in a controlled way.
> > > > We also use this ourselves when testing the transitions ERROR_ACTIVE <-> ERROR_WARNING <-> ERROR_PASSIVE, for Rx.
> > >
> > > I think that there are two axes in this discussion: the attacker
> > > point of view and the functional testing point of view.
> > >
> > > From the attacker point of view, you are mostly interested in
> > > destroying the transmitter frames.
> > >
> > > For the functional testing, it is about covering the all the
> > > aspects of the standard: make sure that all the TX and RX counters
> > > are correctly incremented, test the transitions between the
> > > different states and that for all offsets. And to confirm all
> > > aspects, you might want to inject both the active and the passive
> > > error flags and do it at all possible positions.
> > >
> > > That said, my vision on functional testing is an uneducated
> > > guess. I never worked on that and my personal focus is more the
> > > attacker point of view.
> >
> > Looking back to it, my first interest would be to fire N error frames,
> > so to control other nodes' rx error counters.
> 
> It is slightly more complex.
> 
> Let's consider three nodes all on the same bus.
> 
> A: Test node, sends error flags
> B: Normal node, send normal frames
> C: Normal node, only receiving
> 
>    ___            ___            ___
>   | _ |          | _ |          | _ |
>   ||A||          ||B||          ||C||
>   |___|          |___|          |___|
>     |              |              |
>     | Sends        | Sends        | Only
>     | error           | normal       | receives
>     | flags        | frames       |
>     |              |              |
>   --------------------------------------- CAN bus
> 
> A waits for B to start sending its frame and trigger the error
> flag. This error flag will eventually overwrite one of B's recessive
> bit into a dominant one and thus B has his TX error count increased.t
> 
> C who is a spectator will just have its RX error count increased.

Right, I understand. I was too quick with my conclusion.
Thanks for explaining.

[...]

> > The attacker point of view indeed could require a more elaborate API,
> > but I still doubt we can deliver what is required for attacking.
> 
> This is interesting because we have an opposite view of the attacker
> and functional testing approaches.
> 
> For the attacker, I am thinking of:
> https://youtu.be/oajtDFw_t3Q
> In a nutshell, it is an elaborate technique in which you first DoS the
> target node by increasing its TX counter until it gets in bus-off
> state. Once done, the attacker can send messages in place of
> the genuine node. This way, contrary to an simple injection attack
> on which the bus contains both the genuine and the attacker frames,
> here, only the attacker speaks on the bus.
> This attack does not really care when the error flag occurs as long as
> the error counter increases.

Yep, I see.

I tend to program the nodes to recover from bus-off in 10msec
magnitude. The scenario you describe, if I understand well, is hard to
implement you need to repeat it every 10msec.

Am I mistaken?
Or is 10msec order rather stupid to recover and does everyone apply much
longer delays before recovery?

> 
> My vision of the functional testing is more: does the controller
> react correctly in all situations? You could imagine an implementation
> issue that would cause the error count to not correctly behave only on
> a specific field. How would you test for such implementation issues
> other than injecting the error flag at each offset of the frame?

ok

> 
> 
> Yours sincerely,
> Vincent