On Wed. 3 Feb 2021 at 15:42, Jimmy Assarsson <jimmyassarsson@xxxxxxxxx> wrote: > > On 2021-02-02 20:19, Oliver Hartkopp wrote: > > On 02.02.21 12:12, Vincent MAILHOL wrote: > > > >>> The CAN_ERR_FLAG has been renamed in the documentation to indicate > >>> "error messages" from the CAN controller, as an error frame is something > >>> completely different. > >>> > >>> Now as we are talking about having CAN_ERR_FLAG in the TX path besides > >>> the vcan testing stuff, we should think about an API for the really > >>> outgoing frames. > >>> > >>> We could not only think about "create an error frame right now" but also > >>> think about a more intelligent CAN node, which also offers to destroy > >>> one or more specific CAN ID(s) at a specific bit position after > >>> detecting that CAN ID. > >> > >> My original idea was to leave it unspecified until a device was > >> actually capable of doing such a thing. But I am not against > >> defining the API now :) We might just have to wait a long time > >> for someone to actually implement it. > >> > >>> We could use the CAN_RTR_FLAG and the data[] section of the outgoing > >>> error CAN frames for such an API. > >> > >> We are not limited to the CAN_RTR_FLAG and the data[] > >> > >> First, we have to list the use cases. > >> > >> As I wrote before, there are only two forms for the error flag: > >> - The active error flag: 6 consecutive dominant bits > >> - The passive error flag: 6 consecutive recessive bits > > > > IMO this passive error flag stuff is pointless. > > The passive error does not have any effect on the bus. Nobody sees it. It's just a measure to continue counting error counters inside the CAN controller. IMO it's a read-only feature about the controller internal status. > > I agree. Passive error flags will have effect if initiated by the transmitter. It will break the bitsuffing rule and other nodes will notice. Passive error flags initiated by the receivers shall indeed have no effects. This is admitelly an edge case. It really depends how much we want to cover with our API. > >> The device can either inject the flag either during: > >> - bus idle > > > > Is an error flag defined at bus idle? > > > > Error flags are intended to destroy *other CAN controllers* transmissions when detecting protocol violations. There can not be a protocol violation at idle time, right? > > This is what the Kvaser CAN controller does. It will wait for the bus to become idle, before an active error flag is transmitted. To add to Jimmy's comment, the ISO standard does not differentiate this. In section 10.4.4.2 "Error flag", it states that "An error-active node detecting an error condition shall signal this by sending an active error flag." If you try to shortcut the CAN High and CAN low wires or connect those to the ground while the bus is idle, you would probably get some errors. > >> - while it is transmitting a frame > > > > What's the use-case for destroying your own transmission? For active error flags: I admit that there is no benefit. You could emulate this easily if you have two nodes under your control: you send the frame on the first node and inject the error on the second one. The only use case is for the passive error flag just because the transmission is the only way to do it. So it just brings us back to the above discussion: how much do we want to cover. > >> - while it is receiving a frame > > > > This makes sense, especially when you can destroy specific CAN ID frames at a specific bit position. > > Or for any CAN ID at a specific bit position. > > Or for any CAN ID at an undefined bit position. > > I agree. > > >> The error flag can occur at any time. > > > > Sure? (see above) > > > > 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. Yours sincerely, Vincent
