Re: [Question] Sending CAN error frames

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2252 bytes --]

On 2/2/21 9:23 AM, Kurt Van Dijck wrote:
>>>> Right, it would be nice to sort this out. I prefer to keep the
>>>> functionality, since we got customers using it.
>>>
>>> Basically, I would see this as an expert function: add a
>>> CAN_CTRLMODE_TX_ERR and have the user explicitly enable the
>>> feature through netlink when configuring the interface. The
>>> rationale is to prevent by default an unprivileged application
>>> from messing with the bus.
>>
>> The CAN_CTRLMODE_TX_ERR would be a per device option. Another option might be a
>> sockopt, where you have to enable the TX_ERR explicitly. I'm not sure, which
>> option is the best here.
> 
> a sockopt is only correct if it can detect that the device underneath
> has CAN_CTRLMODE_TX_ERR capability.

ACK

The user space use case would be:

- fd = socket()
- bind(fd, "can0")
- setsockopt(fd, SOCKOPT_TX_ERR)

The raw_setsockopt() in the kernel can check the CAN devices supported ctrl modes.

> So I'd think we start with adding the CAN_CTRLMODE_TX_ERR to the driver
> level.

ACK

> It would allow to see if a driver will behave properly with CAN_ERR_FLAG 
> can_frames in the tx path.

ACK

>>> If CAN_CTRLMODE_TX_ERR is on the device generates an error
>>> flag. Else, the CAN_ERR_FLAG is simply ignored (masked out).
>>> The CAN ID, DLC and payload of the TX error frames are
>>> ignored (i.e. reserved for future).
> 
> IMO, can_frames in the tx path with CAN_ERR_FLAG should be dropped
> if the driver can't handle them. vcan in this regard is capable of
> handling those, as does the kvaser usb.

Makes sense. The implementation steps could be:
- convert can_dropped_invalid_skb() from static inline to
  regular function
- add check for CAN_ERR_FLAG and enabled CAN_CTRLMODE_TX_ERR
  to can_dropped_invalid_skb()

> I think it's wrong that CAN_ERR_FLAG messages would appear as regular
> frame on CAN, as happens today if I understood well.

ACK

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]