Open rahagal opened 6 months ago
Your patch has a bug regarding the message length calculation. You need to perform the len function on the msg.data and not data. because data is a padded buffer with length 64 or 8 and not the actual length of the original message. I'm planning to attach my fix which is much like yours in a pull request.
Is your feature request related to a problem? Please describe.
SocketCAN allows for passing an optional DLC element in its
can_frame
structure in addition to the length element, this allow accessing the raw DLC value that can be 0-15 (with 9-15 interpreted as 8 in classic CAN). This feature is good for testing compliance with the ISO. To enable this some changes are implemented in the Linux kernel and in can-utils. You can see the change being introduced to can-utils in here: https://github.com/linux-can/can-utils/commit/c398e56afb9b60441232736e05fdfb5a525363caDescribe the solution you'd like
I would like to suggest an adaptation to the way CAN_FRAME_HEADER_STRUCT is being defined and un/packed.
Describe alternatives you've considered
I did not find a way to achieve this with the current implementation.
Additional context
See a patch used in a fork I've created that allowed me to achieve this capability. socktcan_over8_dlc.patch