The helper functions for the error frame content added the return
values of snprintf() to the buffer offset without checking for
truncation. With a too small buffer the following 'len - n' calculation
wrapped around (size_t) and subsequent snprintf() calls could write
beyond the end of the buffer.
As the maximum output length is known, introduce CANERR_BUFFSZ in lib.h
with a description how the required buffer size is calculated and
return an empty string if the provided buffer is smaller. The only user
candump provides a buffer of more than 6000 bytes for this function.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
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>
As Alex J pointed out in comment
https://github.com/linux-can/can-utils/issues/632#issuecomment-5746692502
the delimiters to detect CAN CC/FD/XL frames were read from the input
data without checking the length of that input data. This could lead
to an out-of-bounds read and to unintended detection of incorrect content.
Add a length check before reading those delimiters and also add/change
some comments to clarify the reasons for some assignments.
Reported-by: Alex J <jipaionut@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Fix infinite loops that prevent graceful termination when the server
receives SIGINT or SIGTERM signals. Without this fix, Ctrl-C and kill
commands are ignored, making it impossible to stop the server cleanly.
Two scenarios cause the infinite loops:
1) The bind() retry loop: When the port is busy, the loop retries
indefinitely without checking the running flag set by the signal
handler.
2) The accept() loop: The loop is unconditional, so when accept() is
interrupted by a signal and returns EINTR, the loop immediately
restarts, ignoring the shutdown request.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
When the call to localtime_r() fails (by returning NULL, as per the POSIX specification), make sure to fill the hour/minute offsets with the fallback values as specified in the J1939DA supporting information.
The `file_path` of `strchr(file_path, '/')` is a `const char *`. In this
case the `strchr()` in debian experimental returns a `const char *`,
leading to this error message:
```
mcp251xfd/mcp251xfd-regmap.c:75:13: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
75 | tmp = strchr(file_path, '/');
| ^
```
Fix the error by using the return value from `strchr()` directly in the
`if()`.
Link: https://github.com/linux-can/can-utils/actions/runs/22649777324/job/65679726209?pr=619
This project does not rely on any behavior from CMake <3.10, and
compatibility with CMake <3.10 is expected to be removed in future
releases.
https://cmake.org/cmake/help/v4.0/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-10
```
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.10 will be removed from a future version of
CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
```
There are explicit #defines for SCM_TIMESTAMP and SCM_TIMESTAMPING. They
currently happen to have the same value as SO_TIMESTAMP and
SO_TIMESTAMPING but the former should be used when checking cmsg_type in
case one day they do not.
The mixed mode is able to automatically detect the potential supported
CAN frame types CAN CC/FD/XL by checking the CAN device MTU at startup.
Usually the MTU shows which CAN frame types can be sent but in the case of
CAN XL in CANXL-only mode CC and FD frames can not be sent on the CAN_RAW
socket.
Since this patch [1] the CAN_RAW socket rejects unsupported CAN frames and
returns -EINVAL as error code. With this change in cangen the CC and FD
frame generation can be disabled in mixed mode at runtime.
[1] https://lore.kernel.org/linux-can/20251125123859.3924-17-socketcan@hartkopp.net/T/#u
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Automatically create FD/XL content in mixed mode when the CAN interface
is capable to deal with it.
Suggested-by: Vincent Mailhol <mailhol@kernel.org>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The extra message infos BRS and ESI have been printed when enabled with
the '-x' option. Since CAN XL has similar flags (SEC and RRS) those flags
have been wrongly printed as CAN FD flags.
This patch introduces separate flags for the CAN XL frames and prints them
when a CAN XL frame is processed.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The extension of the timestamp size is missing in log2asc.c and canplayer.c
Fixes: 987bc8aac2 ("Optional nanosecond timestamp logging")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Oliver Hartkopp
Oleksij RempelandGitHub
Marc Kleine-BuddeandGitHub
Samantaz Fox
Takuya Wakazono
Darcy Phipps
Rikus WesselsandOliver Hartkopp
