I'm writing a CAN driver and want to set up some tests for it. I have a simple echo program (accepts a can frame and echoes it back). I'm using can-utils for this and would use cangen to generate random data, log it, then make sure the frames were received and echoed back.
Everything seems to be working but there is some annoying behavior from candump. When sending non-FD frames, it does not print a leading zero for the DLC. See here (messages are sent, and then the echoed message - yes I'm aware it shouldn't use the same node id to echo back this is just for testing purposes):
candump can0
#can FD frames (11 and 29 bit ids)
can0 033FABCD [04] DE AD BE EF #sent
can0 033FABCD [04] DE AD BE EF #echoed
can0 277 [04] DE AD BE EF
can0 277 [04] DE AD BE EF
#non-FD frames sent (11 and 29 bit ids)
can0 277 [4] DE AD BE EF #sent
can0 277 [04] DE AD BE EF #echoed
can0 077AFFFF [4] DE AD BE EF
can0 077AFFFF [04] DE AD BE EF
Both FD and non-FD frames have a 4 bit DLC so I'm not sure why it'd be printed differently. We are only sending FD so the echoed frame is in FD format and gets a leading zero printed.
Obviously I can work around this but the behavior is kind of annoying. Does anyone know what might be wrong here?
No this is intentional to distinguish Classic CAN [x] from CAN FD [xx] frames in the human readable output. It is not the question whether the DLC (4 bit on the physical layer) to be the same, as we always operate with the real length information and not with the DLC on socket level. And when both are 5 bytes you wont be able to distinguish them.
Btw. your CAN driver seems to have an issue, when the echo'ed frame is always a CAN FD type - no matter what has been sent (Classic CAN / CAN FD) ...