I recently came across a case where I initialized and sent a CANFD frame with a payload whose length is not a valid CANFD data length. I therefore digged a little deeper and discovered that CANFD frames are also being sent with an invalid data length. Here is the example code for creating and sending a CANFD frame with an invalid DataLength (DL=11):

let sock =CanFdSocket::open("vcan0").expect("open canfd socket0");let id =StandardId::new(0x123).expect("create CAN id");// invalid data length (DL=11)let data:&[u8] =&[0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99,0xAA,0xBB];let flags:FdFlags =FdFlags::all();let frame =CanFdFrame::with_flags(id, data, flags).expect("create CANFD frame");sock.write_frame(&frame).expect("send frame");

The candump output of the (via cangw connected) vcan1 interface looks like this:

vcan1  123  [11]  11 22 33 44 55 66 77 88 99 AA BB

As you can see a invalid CANFD frame with a data length of 11 ist being transmittet.
In comparison, when sending the same frame using the following cansend command

cansend vcan0 123##F112233445566778899AABB

the data is being correctly padded with 0 to the next valid data length (in this case 12).

vcan1  123  [12]  11 22 33 44 55 66 77 88 99 AA BB 00

I therefore updated theCanFdFrame::init andCanFdFrame::set_data functions in the last commit to correctly add padding to the data when needed.

Oh, BTW, on a closer 2nd look, I realized you don't need to manually add zero padding to the FD frame (along with the added allocation/deallocation). The creation of the underlying C variable zeros out the whole struct already, including the data field:

let mut frame = canfd_frame_default();

So all you need to do is copy in the user data, even if it's not a valid length, andthen set the length to a valid value.