The logfile format which is generated with '-l' and '-L' consists of an
absolute epoch timestamp. In some use cases (e.g. for documentation) a
zero relative timestamp can be useful which was only configurable with
the '-tz' option for the classic output.
'-tz' and '-ta' are now valid options for the logfile format.
Signed-off-by: Richard Young <code@richyoung.ca>
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>
Using epoll_wait() instead of select() gives higher
performance for listening on multiple interfaces.
Additionally, the read order has a higher chance
to resemble the true temporal order.
select() gives implicit priority to the lower index socket.
Signed-off-by: Jörg Hohensohn <joerg.hohensohn@gmx.de>
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>
This patch fixes the following warning:
cansequence.c:232:3: warning: expression result unused [-Wunused-value]
(unsigned char)frame.data[0]++;
^ ~~~~~~~~~~~~~~~
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Otherwise throwing the following error:
build/make/core/base_rules.mk:325: error: external/can-utils:
MODULE.TARGET.EXECUTABLES.cansequence already defined by
external/can-utils.
Fixes: a726c2a ("Merge branch 'cansequence' of
github.com:marckleinebudde/can-utils into master")
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
The PTX flavour canutils have a useful utility for generating a sequence of CAN
frames with an incrementing payload and checking such a sequence for missed and
reordered frames.
Recently, it has helped finding a regression in the kernel pfifo_fast qdisc,
which led to reordered frames.
To bring the utility to a greater audience, import the current state, including
its history, into the linux-can set of utilities.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch fixes the indention, which was broken while renaming the j1939
tools.
Fixes: 8106214b55 ("Rename j* to j1939\1")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Without this, the extended identifier flag was not important when
filtering on CAN frames. Add this to mask to only receive the frame type
we want to recieve.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>