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
[off-list ref] wrote:

quoted

On Wed, 03 Feb 2021 17:26:11 +0900, Vincent MAILHOL wrote:

quoted

On Wed. 3 Feb 2021 at 15:42, Jimmy Assarsson [off-list ref] wrote:

quoted

quoted

Of course we might also provide some pump gun mode which just sends an error flag at some (any) time.

As above.

quoted

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.

[...]

quoted

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