The DLC and data length values were read into signed integers with
%x and %d. Negative values (e.g. '-1' or 'ffffffff') passed the range
checks and led to len values of 255 or 65535. Via the union cfu
these classic CAN frames were then printed as CAN XL frames.
Use unsigned int for dlc/dlen and %u for the data length so that
negative values are caught by the existing range checks.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The data parsing loops in the CANFD/CANXL evaluation functions jumped
three characters forward after each hex byte without checking the
separator. When a line ended directly after a hex byte (e.g. last line
without newline or a line split by fgets()) the pointer skipped the
string termination and continued parsing stale content from previous
lines - or in the worst case read beyond the input buffer.
Factor out the four identical loops into get_hex_data() which requires
a whitespace separator behind each hex byte.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The ASC file provides an information whether the CAN frame is sent (Tx)
or received (Rx) on the local CAN node.
With the new '-d' option the generation of this information is disabled
for the log file generation to simplify the comparision of log files.
E.g. log1 -> asc -> log2 always created the T/R information in the log2
file which is then hard to compare to the log1 file which might not
have the T/R information at all.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Since using the %n feature the tmp1 buffer is only used for the handling
of the CAN identifier. So this buffer can be shrinked for that use case.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
TxRq messages are internal measurement messages that document the time of
a transmission request (to the CAN driver) to be checked against the real
transmission time, when the CAN message has been sent.
There is no such feature in the SocketCAN log format, so we detect this
tag but skip TxRq messages in the ASC log files.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Make sure the library functions to convert CAN frames into ASCII
represenation do not exceed the given buffer size. This also applies
to the long CAN frame output library function.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Move the curly brackets to the start of the next line to follow the
common coding style in can-utils.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Replace maxdlen parameter and use CANFD_FDF flags instead.
Since the CANFD_FDF flag has been introduced in can.h the struct canfd_frame
can be used for CAN CC and CAN FD frames as a dual-use data structure.
Remove the extra maxdlen parameter in library calls and only use the
CANFD_FDF flag to differentiate the two CAN CC/FD frames.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In commit 6799180bd0 ("log asc converter: support len8_dlc for Classical
CAN frames") the len8_dlc support was accidentally only implemented for
the new CANFD asc format. This patch adds len8_dlc support for the 'old'
Classical CAN asc format which in fact always supported len8_dlc.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
We need to check for different sscanf() failures and the number of read
items in the data frames. So move the simple check to the beginning.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The helper functions can_len2dlc and can_dlc2len are only relevant for
CAN FD data length code (DLC) conversion.
Update to latest in-kernel naming scheme:
can_dlc2len -> can_fd_dlc2len to get the payload length from the DLC
can_len2dlc -> can_fd_len2dlc to get the DLC from the payload length
Suggested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CANFD format in asc logfiles can be used to describe Classical CAN
frame content too. As this CANFD format has two different elements to
transport the payload length and the 'raw data length code' the new
len8_dlc option now allows to support the full qualified conversion.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch adds a fourth string field in the can logfile format.
This new field contains the rx/tx direction information R/T as the
first entry (only one character separated from the CAN frame by space).
To generate the logfile format with this extra field candump has to be
called with the '-x' option for extra message infos,
e.g. 'candump -x -l can0' or 'candump -x -L can0'
log2asc and asc2log are extended to support the direction information
but still support the previous format without direction information.
The format extension does not affect legacy tools, e.g. the existing
canplayer ignores this extra information and does not need to be changed.
Therefore the existing logfiles remain valid and usable.
The extra message infos will be colon separated when there's need for
additional content beyond the rx/tx direction information, e.g. R:xx:yyy
Suggested-by: Pallavi Revanna https://github.com/brpallu
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
While strptime() does not support fractions of seconds in the date/time
string some new asc files support the milliseconds resolution.
When detecting this new format the msecs are retrieved by a separate
sscanf() invocation and added to the timeval's tv_usec element.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Add some more sanity checks and increase readability for the sscanf()
procedure to read a CANFD tagged line.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
strptime() does not support milliseconds but the latest ASC logfile
also provides a fraction of seconds, e.g.
date Fri May 8 08:49:04.052 pm 2020
Read the value into the year variable before parsing the real year.
We will therefore omit the milliseconds resolution for now.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
outfile is closed as well, so do this symmetrically for infile.
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Oliver Hartkopp
vuquangtrongandGitHub
TyK
weichslgartner
Simon TegelidandOliver Hartkopp
Rosen PenevandOliver Hartkopp
Alexander GerasiovandAlexander Gerasiov
Yegor Yefremov
Marc Kleine-Budde
Robert SchwebelandMarc Kleine-Budde