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@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 03 Feb 2021 17:26:11 +0900, Vincent MAILHOL wrote: > > > On Wed. 3 Feb 2021 at 15:42, Jimmy Assarsson <jimmyassarsson@xxxxxxxxx> 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
