According to ISO 11783-13:2021 (sections C.3.4.2 and C.3.5.2), 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.
Previously, the implementation treated directories strictly as files,
using byte-based offsets and counts. This resulted in incorrect seeking
behavior and protocol violations when listing directories.
This patch aligns the implementation with the standard by:
1. Server side:
- Introducing `isobusfs_srv_dir_entry_visible()` to consistently
filter out invalid (unreadable, hidden, oversized) entries. This
ensures that entry indices remain stable.
- Implementing `isobusfs_srv_dir_skip_entries()` to advance the
directory stream by logical visible entries rather than bytes.
- Updating the "Read File" handler to interpret `count` as the
maximum number of entries and return the number of entries read
in the response header.
- Updating the "Seek File" handler to seek by entry index.
2. Client side:
- Calculating the request count based on the number of minimal-size
entries that fit into the maximum data length.
- Interpreting 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>
Stop using -EINTR for cmd_exit(). Introduce ISOBUSFS_CLI_RET_EXIT and
map it to exit code 0 in main(), keeping errno values for real errors.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Previously, the `canlogserver` could get stuck in infinite loops when
receiving a signal (e.g., SIGINT via Ctrl-C) in two scenarios:
1. Inside the `bind()` retry loop: If the port was busy (e.g., in
TIME_WAIT), the loop retried indefinitely using `nanosleep` without
checking the `running` flag set by the signal handler.
2. Inside the `accept()` loop: The loop was unconditional (`while(1)`).
If `accept()` was interrupted by a signal, it returned with `EINTR`,
but the loop immediately restarted, effectively ignoring the shutdown
request.
This patch adds checks for the `running` flag in both loops to ensure
the server terminates correctly upon receiving a signal. It also ensures
the socket is closed properly and the correct exit code (128 + signal
number) is returned.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
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>
On some systems SIOCGIFNAME may fail with ENOTTY, but the actual
slcanX interface gets properly configured. Instead of crashing hard on
such case, let's gracefuly degrade and just not display the interface
name.
This should at least fix the `No rule to make target` error:
```
cc -O2 -Wall -Wno-parentheses -Wsign-compare -I. -Iinclude -DAF_CAN=PF_CAN -DPF_CAN=29 -DSO_RXQ_OVFL=40 -DSCM_TIMESTAMPING_OPT_STATS=54 -DCLOCK_TAI=11 -DSO_TXTIME=61 -DSCM_TXTIME=SO_TXTIME -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -c -o j1939_vehicle_position/j1939_vehicle_position_srv.o j1939_vehicle_position/j1939_vehicle_position_srv.c
j1939_vehicle_position/j1939_vehicle_position_srv.c:7:10: fatal error: gps.h: No such file or directory
7 | #include <gps.h>
| ^~~~~~~
compilation terminated.
make: *** [<builtin>: j1939_vehicle_position/j1939_vehicle_position_srv.o] Error 1
make: *** No rule to make target 'cc', needed by 'j1939-vehicle-position-srv'.
make: *** No rule to make target '-lgps', needed by 'j1939-vehicle-position-srv'.
make: *** No rule to make target '-o', needed by 'j1939-vehicle-position-srv'.
```
Link: 71b2aec834 (commitcomment-153191516)
Fixes: 71b2aec834 ("j1939-vehicle-position-srv: Introduce J1939 and NMEA 2000 Vehicle Position Server")