Re: [Question] Sending CAN error frames

[Vincent MAILHOL <mailhol.vincent@wanadoo.fr>]

Hi Oliver,

On Sun. 31 Jan 2021 at 21:59, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hi Vincent,
>
> On 31.01.21 07:22, Vincent MAILHOL wrote:
> > Hello,
> >
> > The socket CAN API handles the CAN errors (as reported by the
> > microcontroller) by emitting some RX CAN frames with the
> > CAN_ERR_FLAG set.
>
> Yes. This is the only intention.
>
> > My question concerns the transmission path: I would like to
> > understand how drivers should handle *TX* CAN frames which have
> > the CAN_ERR_FLAG set.
> >
> > The socket API allows sending such frames. For example doing:
> >      cansend can0 20000123#0011223344556677
> > will generate such frames and it will reach the xmit() function of
> > the driver.
>
> The reason to pass the frame as-is to the driver layer (including
> CAN_ERR_FLAG) is the possibility to test the correct behavior on the RX
> path, e.g. when you use the vcan driver.

ACK. I was not thinking of the virtual interfaces. This is a valid use case.

> On the sending path the CAN_ERR_FLAG has no functionality so far - at
> least it was not defined by the community.
>
> > However, contrary to the other flags (EFF, RTR, FDF, BRS), the
> > ERR flag is not present on the data link layer. Instead, the data
> > link layer is responsible for detecting errors and signaling those
> > as soon as they occur (thus interrupting the transmission).
> >
> > While the ISO standard does not explicitly forbid having upper
> > layers generating such frames, it is not documented. Also, I am
> > not aware of CAN controllers allowing to generate error frames on
> > demand.
>
> There are specialized CAN testers, e.g. IIRC Vector CANstress that can
> generate error frames on specific conditions (e.g. when detecting a
> specific CAN ID).

Thanks for the references!

> But I heave not seen CAN controllers that provide such functionality.
>
> > My initial expectation is that those error frames only make
> > sense in the RX path and that we should drop such TX frames in,
> > for example, can_dropped_invalid_skb().
>
> No. As written above the bit is defined to be valid in the RX path only
> and it makes sense for testing.

ACK. My follow-up question would be: how should the driver handle
such frames? Drop them or ignore them?
From what you just explained, I now think that ignoring it is the
best solution (e.g. mask the CAN ID with either CAN_EFF_MASK or
CAN_SFF_MASK and send it as a normal frame).
Does that make sense?

> > However, after looking at the code of other drivers, it appears
> > that one (and only one) of them: the Kvaser hydra, does actually
> > check this CAN_ERR_FLAG flag in the TX path:
> > https://elixir.bootlin.com/linux/v5.11-rc5/source/drivers/net/can/usb/kvaser_usb/kvaser_usb_hydra.c#L1421
> >
> > I would be thankful if anyone knowledgeable about the Kvaser hydra
> > could explain to me how the device handles those error frames.
>
> o_O - Yes, would be interested too!!
>
> > Also, please comment if you are aware of any use cases for TX
> > error frames.
>
> Done.

And thanks for that!

> Best regards,
> Oliver