The Remote Request Substitution bit is a dominant bit ("0") in the CAN XL
frame. As some CAN XL controllers support to access this bit a new
CANXL_RRS value has been defined for the canxl_frame.flags element.
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>
With the introduction of CAN FD the bitrate has not been printed
correcty. Fix the CAN FD bitrate output and try to shrink the
bitrates by using kilo or Mega suffixes: 500000 -> 500k
Fixes: 6382765bf6 ("canbusload: count databitrate seperately")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Rework to use a single CAN socket for the received CAN traffic.
This allows to shutdown and restart various CAN interfaces without
terminating the application.
Additionally an auto detection has been implemented with the 'any' CAN
interface. E.g. with any@500000,2000000 CAN interfaces that have not
been defined before are assigned with the given 'any' bitrates when a
CAN frame from this CAN interface has been received.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CAN interface description can now have two bitrates.
Extend the length check to handle the CAN FD data bitrate correctly.
Fixes: 6382765bf6 ("canbusload: count databitrate seperately")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
With 'cansend' and other tools the reserved elements are set to zero.
Fix this missing initialization in 'cangen'.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
can-utils: support CAN XL
This patch set adds support for CAN XL including VCIDs (Linux v6.9+)
Tools that completely support CAN XL:
candump
cangen
canlogserver
canplayer
cansend
log2long
CC/FD-only tools that have been adapted to the lib.[ch] changes:
log2asc
asc2log
Main changes:
lib/cangen: add documentation for CAN XL ASCII representation
lib: remove separate maxdlen parameter as every needed info is part of the CAN frame now
lib: remove fprint functions and only support sprint
lib: rework for static single buffer to contain a complete ASCII CAN XL frame
lib: introduce a CAN frame unit type to contain CAN CC/FD/XL frames in one union
canplayer/log2asc/log2long: make sscanf() buffer length aware
cangen: fix views for some features for long CAN frame output
general cleanups and buffer overflow safety measures
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>
The 'long' CAN frame representation does not really fit for CAN XL content.
Therefore just a cropped output is provided to be able to see the CAN XL
header information and up to 64 byte of data (without binary or swap
formating options). To get the full qualified CAN XL content use the log
file format.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Build the CAN frame ASCII output inside a single (big) buffer as
preparation for CAN XL support.
This unifies different output modes (fprintf/sprintf/printf) at
the time of the CAN frame text generation.
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>
slcanpty.c: In function ‘pty2can’:
slcanpty.c:105:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
105 | buf[nbytes] = 0;
| ~~~~~~~~~~~~^~~
slcanpty.c:58:21: note: at offset [-2147483647, -1] into destination object ‘buf’ of size 200
58 | static char buf[200];
| ^~~
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As the tx_dl and flags struct elements are not relevant for listen-only
sockets, simplify the CAN FD command line option switch.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When sniffing CAN FD isotp traffic both listen-only sockets have to be
switched to process CAN FD frames.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The check has only been applied after the first CAN frame has been read
and evaluated. This lead to an unintended sending of a single handcrafted
frame with a following (intended) failure at the second frame.
Apply the check also for the very first CAN frame that is processed.
Fixes: ee0233505b ("canplayer: ensure 6 decimal places in timestamp")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The ASC file banner, e.g.
date Thu Jan 1 01:00:00 1970
base hex timestamps absolute
no internal events logged
should be printed when the first timestamp from the logfile has been
processed. But for logfiles starting with zero (e.g. candump -tz option)
this banner is printed every time the timestamps seconds equals zero.
As it was obviously not a good idea to stick the condition for printing
the banner based on some assumption about the timestamp a new variable
'print_banner' has been introduced.
Reported-by: https://github.com/CaSchmidt
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The check for CAN FD capable interfaces only checked for CANFD_MTU to
enable the generation of CAN FD frame content. As CAN XL capable CAN
interfaces are able to handle CAN FD frames too the check has to be
extended for CANXL_MTU interfaces.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The check for CAN FD capable interfaces only checked for CANFD_MTU to
enable the generation of CAN FD frame content. As CAN XL capable CAN
interfaces are able to handle CAN FD frames too the check has to be
extended for CANXL_MTU interfaces.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Update includes to support CAN XL and latest CAN netlink features.
Upstream commits:
(1a3e3034c049) "can: canxl: introduce CAN XL data structure"
(061834624c87) "can: set CANFD_FDF flag in all CAN FD frame structures"
(94dfc73e7cf4) "treewide: uapi: Replace zero-length arrays with flexible-array members"
(383f0993fc77) "can: netlink: report the CAN controller mode supported flags"
(d99755f71a80) "can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)"
(63dfe0709643) "can: bittiming: allow TDC{V,O} to be zero and add can_tdc_const::tdc{v,o,f}_min"
(626332696d75) "can: raw: add CAN XL support"
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Usually the ISO 15765-2 protocol is a point-to-point protocol to transfer
segmented PDUs to a dedicated receiver. This receiver sends a flow control
message to specify protocol options and timings (e.g. block size / STmin).
The so called functional addressing communication allows a 1:N
communication but is limited to a single frame length.
The new CAN_ISOTP_CF_BROADCAST flag introduced in Linux 5.19 allows an
unconfirmed 1:N communication with PDU lengths that would not fit into a
single frame. This feature is not covered by the ISO 15765-2 standard.
The isotpsend tool gets a new option '-C' to enable this unconfirmed 1:N
communication by setting the CAN_ISOTP_CF_BROADCAST flag.
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>
Since commit ad250a68dc ("candump: add option to define individual
filename for logfile") the option "-f <fname>" allows to define an
individual filename for a logfile.
Usually the "-" is used as filename to represent stdout or stdin on
Linux/Posix systems to be able to concatenate several applications via
pipes. This patch handles this special case by detecting the filename
"-" to print the logfile format on stdout instead of creating a logfile
with the name "-".
Fixes: ad250a68dc ("candump: add option to define individual filename for logfile")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
- update isotp.h include file
- update maximum PDU (buffer) size to 64kByte buffer
- support setting of N_As (frame_txtime) to zero
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
With the option '-T <msecs>' candump terminates after getting no CAN traffic
for a specific time. With the introduction of epoll_wait() this feature
has been accidentally disabled.
This patch adds an extra check to detect the timeout again.
Fixes: 639498bc80 ("candump: use epoll_wait() instead of select()")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In CAN FD mode the length of the output line becomes very long.
Therefore disable the ASCII output in CAN FD mode by default but
make it switchable with a new '@' command in interactive input mode.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Analogue to the '-n <count>' option to limit the number of processed CAN
frames in candump and cangen this option makes sense in canplayer too.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
if_nametoindex() returns zero and a specific errno in the case the network
interface does not exist. The missing check leads to the use of the 'any'
CAN device but leaves the user alone as the user gets no error message.
Reported-by: Lothar Rubusch <lotophagon@protonmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 8 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
Fixes: cc155d2f63 ("j1939cat: make use of new RX UAPI")
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Wait for ENTER key to process next CAN frame from the log file.
As the new line is printed each time this approach doesn't win a
design price. But this feature is very uncommon and setting the
terminal into some raw mode to get the raw keyboard hits would
introduce a big code overhead to handle e.g. CTRL-C signals which
is a vital functionality for canplayer.
Link: https://github.com/linux-can/can-utils/issues/280
Suggested-by: https://github.com/nico0481
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Commit 9c2de072a0 ("asc2log: Correct usec overflow handling") fixed the
usec overflow handling which is contained in a similar code snippet in
canplayer too.
Cc: Simon Tegelid <simon.tegelid@niradynamics.se>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the
CAN_ISOTP socket is switched into functional addressing mode, where
only single frame (SF) protocol data units can be send on the specified
CAN interface and the given tp.tx_id after bind().
In opposite to normal and extended addressing this socket does not
register a CAN-ID for reception which would be needed for a 1-to-1
ISOTP connection with a segmented bi-directional data transfer.
The new option '-S' sets the CAN_ISOTP_SF_BROADCAST to test the option
with different length settings, e.g. link layer data lengths.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the
CAN_ISOTP socket is switched into functional addressing mode, where
only single frame (SF) protocol data units can be send on the specified
CAN interface and the given tp.tx_id after bind().
Add the CAN_ISOTP_SF_BROADCAST define from Linux UAPI includes.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Due to a wrong test to check for existing CAN-IDs in the snifftab
it was not possible to have the CAN-ID '0' in the list and displayed.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The can_dlc value that is passed to the kernel is not sanitized in cangw
therefore we only update the help text and some comments in gw.h.
In the case that the CAN interface supports len8_dlc by setting
CAN_CTRLMODE_CC_LEN8_DLC the can-gw module can modify the full DLC value
range (0 .. 15) for Classic CAN frames.
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>
The display of Classical CAN raw DLC values is an expert feature which is
not enabled by default to not break toolchains that use the candump
standard output for further processing. (N.B. using the log file format and
the functions from lib.h/lib.c provide convenient CAN frame conversions)
After enabling the raw DLC for Classical CAN with the '-8' option the raw
DLC value is printed in 'unusual' curly braces {}.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
A new option '-8' has been added to generate Classical CAN frames with
DLC codes from 0 .. 15.
Fixed and random mode implemented by Oliver Hartkopp.
Incremental DLC mode 'cangen -8 -Li can0' implemented by Vincent Mailhol.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
ISO 11898-1 Chapter 8.4.2.3 defines a 4 bit data length code (DLC) table which
maps the DLC to the payload length of the CAN frame in bytes:
DLC -> payload length
0 .. 8 -> 0 .. 8
9 .. 15 -> 8
To access the raw DLC values 9 .. 15 the len8_dlc element is introduced, which
is only valid when the payload length 'len' is 8 and the DLC is greater than 8.
The extension for len8_dlc has been implemented for the Classic CAN frame
representation in the log file format and for the standard output for
candump where the raw DLC value is printed in 'unusual' curly braces {}.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
ISO 11898-1 Chapter 8.4.2.3 defines a 4 bit data length code (DLC) table which
maps the DLC to the payload length of the CAN frame in bytes:
DLC -> payload length
0 .. 8 -> 0 .. 8
9 .. 15 -> 8
Although the DLC values 8 .. 15 in Classical CAN always result in a payload
length of 8 bytes these DLC values are transparently transmitted on the CAN
bus. As the struct can_frame only provides a 'len' element (formerly 'can_dlc')
which contains the plain payload length ( 0 .. 8 ) of the CAN frame, the raw
DLC is not visible to the application programmer, e.g. for testing use-cases.
To access the raw DLC values 9 .. 15 the len8_dlc element is introduced, which
is only valid when the payload length 'len' is 8 and the DLC is greater than 8.
The len8_dlc element is filled by the CAN interface driver and used for CAN
frame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Reported-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Oliver Hartkopp
