On 02.02.21 09:41, Marc Kleine-Budde wrote:
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()
Which means the vcan has to support CAN_CTRLMODE_TX_ERR too.
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
What happens if you send a valid CAN frame with CAN_ERR_FLAG set?
I did not check it but I assume the frame is sent as normal frame and
the echo'ed CAN frame would *only* go through the error message filter
bank in af_can.c.
This is probably not what we want for 'real' CAN devices, so we might
have to take a look at this too.
Regards,
Oliver
