The Commanded Address message contains the 8 byte NAME and the new
source address. The received length was not checked, so the new source
address was taken from stale or uninitialized content of the receive
buffer for short messages. Also the idle and global addresses were
passed to claim_address() which terminates the daemon when bind() fails.
Check for the complete message length and only accept unicast addresses.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The Change Current Directory and Volume Status requests used the path
and volume name length from the request without checking it against
the received message length. Short messages with a big name length made
the server process stale content of the receive buffer as path or
volume name.
Check the name length against the message length, use le16toh() for the
CCD name length and fix the debug output of the volume name.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The Read File response buffer was allocated for the response header and
the requested data only. Short responses (e.g. count = 0) are extended to
ISOBUSFS_MIN_TRANSFER_LENGH which read beyond the allocated buffer and
sent heap content to the client.
Allocate at least ISOBUSFS_MIN_TRANSFER_LENGH bytes and fill the unused
bytes with 0xff.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Read File and Seek File requests only checked the handle index to be
within the handles array. Unused or closed handle slots are zeroed
(fd = 0, dir = NULL), so a read request on such a handle read from the
server's stdin and sent the content to the client. Additionally every
client was able to read and seek handles opened by other clients.
Add isobusfs_srv_get_client_handle() which only returns handles that
are in use and have been opened by the requesting client.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Fix directory operations to comply with ISO 11783-13:2021 (sections
C.3.4.2 and C.3.5.2), which specifies that directory operations differ
significantly from standard file operations:
- The Count parameter in a Read File request represents the number of
directory entries to read, not the number of bytes.
- The Offset parameter in a Seek File request represents the logical
entry index, not a byte offset.
The previous implementation treated directories strictly as files,
using byte-based offsets and counts. This resulted in incorrect seeking
behavior and protocol violations when listing directories.
Align the implementation with the standard by:
1. Server side:
- Introduce isobusfs_srv_dir_entry_visible() to consistently
filter out invalid (unreadable, hidden, oversized) entries. This
ensures that entry indices remain stable.
- Implement isobusfs_srv_dir_skip_entries() to advance the
directory stream by logical visible entries rather than bytes.
- Update the Read File handler to interpret count as the
maximum number of entries and return the number of entries read
in the response header.
- Update the Seek File handler to seek by entry index.
2. Client side:
- Calculate the request count based on the number of minimal-size
entries that fit into the maximum data length.
- Interpret the response count as the number of entries received
rather than the byte length of the payload.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
The cmd_exit() function used -EINTR to signal a clean exit from the
interactive mode. This is semantically incorrect because EINTR is an
errno value meant for system call interruptions, not application-level
control flow.
Stop using -EINTR for cmd_exit(). Introduce ISOBUSFS_CLI_RET_EXIT (a
positive return code) to distinguish control flow from actual errors.
Map this to exit code 0 in main(), keeping negative errno values for
real errors. This makes the exit path explicit and prevents confusion
with actual interrupted system calls.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Add expected_size field to test patterns to properly validate cases
where the requested read size exceeds the actual file size. This allows
testing the server's behavior when clients request more data than is
available.
When a read request is larger than the file, the server correctly
returns data up to EOF. The test framework now distinguishes between
this expected scenario and genuine read failures.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
[socketcan: addressed review comments from PR #629:
- keep uint32_t instead of size_t for offset/read_size/expected_size:
ISO 11783-13 limits the file offset (Seek File) and the file size
(directory entry) to 32 bit, so uint32_t matches the protocol. The
sum offset + read_size can exceed 32 bit (see UINT32_MAX pattern)
and is therefore calculated in int64_t. size_t would not help here
as it is only 32 bit wide on 32 bit targets.
- remaining_size is a signed int64_t: the signed type is needed to
detect the 'remaining_size < 0' case (server returned more data than
requested) and int64_t holds the 33 bit sum on all platforms.
- fix printf format for the uint32_t read_offset (%zu -> %u)]
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
pty2can() detected complete SLCAN messages by looking for the '\r'
termination but did not use this message length for parsing. The
content was read at fixed positions and the start of the following
message was derived from the parsed content.
Too short messages (e.g. 'T1\r') read the DLC and data from stale
buffer content and sent a phantom CAN frame. Following commands got
lost after short messages, unknown commands or frames with timestamp.
Terminate the current message at its '\r' position, check that the
CAN ID fits into the message and always continue with the next message
behind the '\r'.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
parse_mod() and parse_fdmod() did not check the return value of
strchr() when looking for the ':' delimiters. A modification definition
without ':' (e.g. '-m AND') led to a segmentation fault.
Add the missing NULL pointer checks.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
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 RempelandOliver Hartkopp
Marc Kleine-BuddeandGitHub
Samantaz Fox
Takuya Wakazono
Darcy Phipps