Hi all.
I just ran into some curious behaviour with the vcan driver in regards
to CAN-FD and the DLC.
If I send a CAN-FD frame with a length, which is not directly
representable by the DLC field, the vcan driver conserves this value.
E.g. a Length of 11 is sent and received in userspace, even though there
is no DLC representation for 11.
I talked to a colleague about this and we could not think of a case, in
which this behaviour presents a problem. It is just a small discrepancy
from how a real CAN would behave.
cansend from the can-utils package actually makes sure not to use a data
length, which is not directly representable. This is the output of a
candump oagainst a patched version, which does not "fix" the length.
$ candump any & ./patched-cansend vcan0 123##011223344556677889900AA
vcan0 123 [11] 11 22 33 44 55 66 77 88 99 00 AA
Does anyone have a real case, which would warrant a patch to the vcan
driver to change this? Or should the CAN stack even return EINVAL on a
data length, that is not representable?
Regards
Andre