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>
In commit https://github.com/linux-can/can-utils/commit/b153fe3f3591
("clang-tidy: sort includes alphabetically") the position of the "lib.h"
include has been moved in a way that struct canfd_frame has not been
defined anymore and lead to a warning when compiling cangen.c
This patch reverts that specific move and unifies the location of local
includes at the end of the include list.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
With the new flag 'CAN_ISOTP_WAIT_TX_DONE' the send()/write() syscall returns
when the PDU is completely passed to the CAN netdevice queue. Depending on
STmin and other settings for the tx-queue-len this does not necessarily mean
that the PDU has been completely sent on the CAN interface at that time.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch adds a fourth string field in the can logfile format.
This new field contains the rx/tx direction information R/T as the
first entry (only one character separated from the CAN frame by space).
To generate the logfile format with this extra field candump has to be
called with the '-x' option for extra message infos,
e.g. 'candump -x -l can0' or 'candump -x -L can0'
log2asc and asc2log are extended to support the direction information
but still support the previous format without direction information.
The format extension does not affect legacy tools, e.g. the existing
canplayer ignores this extra information and does not need to be changed.
Therefore the existing logfiles remain valid and usable.
The extra message infos will be colon separated when there's need for
additional content beyond the rx/tx direction information, e.g. R:xx:yyy
Suggested-by: Pallavi Revanna https://github.com/brpallu
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Fix missing (recently introduced) j1939 files that have not been fixed
in commit 43610bd621 ("Fix arithmetic on a pointer warning") from
Gary Bisson.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Fix missing (recently introduced) j1939 files that have not been fixed
in commit 46895a41c5 ("Fix comparison type mismatch warnings") from
Gary Bisson.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
open_socket() has a parameter to provide a network device name which
is properly assigned by its callers to s.intf in main().
Instead of using the callers value open_socket() directly accesses the
global s.intf which generates an unused variable warning with clang.
Fix this by using the provided parameter (no functional change).
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
While strptime() does not support fractions of seconds in the date/time
string some new asc files support the milliseconds resolution.
When detecting this new format the msecs are retrieved by a separate
sscanf() invocation and added to the timeval's tv_usec element.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Detailed change log:
log2asc:
- support CAN FD tags and Classic CAN frames
- support RTR frames including DLC values
- new option '-r' disable the RTR DLC value for potential compatibility reasons
- new option '-f' to use the CANFD format for Classic CAN too
asc2log:
- support CAN FD tags and Classic CAN frames
- be robust against fractions of seconds in date/time string
- fix reading of RTR frames including DLC values in Classic CAN parsing
- fix date/time string detection
cangen:
- new option '-E' to support ESI bit for CAN FD frame generation
(was needed for reference log file generation)
The CAN FD frames support BTR and ESI as special flags. While BTR could
be generated by cangen the ESI bit could not be generated so far.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
RTR frames contain a valid DLC value which has not been exposed in the
ASC file format since v8.5 of the tools.
So log2asc will expose this DLC value by default which can be changed
by applying the '-r' option to create the former format.
It can be assumed that the tools pre v8.5 will ignore the value but
if not this switch will make sure to create the old format.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CANFD tagged format also supports the encapsulation of Classic CAN
frames which is selected when logging on CAN FD capable CAN interfaces.
With a new option '-f' this CANFD format is selected.
Although this representation is even more inefficient it is seems to be
the common way and increases the readability for mixed CAN/CANFD logs.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Add some more sanity checks and increase readability for the sscanf()
procedure to read a CANFD tagged line.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CANFD asc format adds information about the CAN controllers bitrate
settings, CRCs and message length (in bits) and its duration.
The plan is to provide static values for these attributes that we can not
get from the log file anyway and stay on the 'old style' format for
classic CAN frames - which has been successfully tested on the latest tools.
The remaining drawback is that the 'old style' format is not able to
provide a DLC information for RTR frames.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
strptime() does not support milliseconds but the latest ASC logfile
also provides a fraction of seconds, e.g.
date Fri May 8 08:49:04.052 pm 2020
Read the value into the year variable before parsing the real year.
We will therefore omit the milliseconds resolution for now.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
cansniffer: support EFF frames with 29 bit CAN IDs
Convert cansniffer from CAN_BCM to CAN_RAW sockets and handle the
content filter in user space. Conversion CAN_RAW including slot
concept and sorting contributed by @coryjfowler.
Functional changes visible to users:
- New format for settings file (using 'r' and 'w' interactive commands)
- New command '8' to switch in a compact binary view for 80 columns view
- New head line layout
- The gap time between CAN frames is displayed in milli seconds (ms)
- The interactive filters support 29 bit CAN IDs
- New interactive command to clear/redraw the screen (<SPACE><ENTER>)
- New interactive commands to enable/disable SFF/EFF frames
a<ENTER> - enable 'a'll SFF CAN-IDs to sniff
n<ENTER> - enable 'n'one SFF CAN-IDs to sniff
A<ENTER> - enable 'A'll EFF CAN-IDs to sniff
N<ENTER> - enable 'N'one EFF CAN-IDs to sniff
- Fixes in bit change colorization and gap calculation detected at rework
Some unification of code formatting and rename of a variable in
print_snifline() which does not represent a CAN ID anymore.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
With the new commands
a<ENTER> - enable 'a'll SFF CAN-IDs to sniff
n<ENTER> - enable 'n'one SFF CAN-IDs to sniff
A<ENTER> - enable 'A'll EFF CAN-IDs to sniff
N<ENTER> - enable 'N'one EFF CAN-IDs to sniff
the EFF/SFF frames can be added/removed with a single command.
Of course this could be done with the '+' and '-' filters too.
But 'N' is much easier to type then '-0000000000000000' ...
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
For efficiency reasons on slow embedded machines cansniffer usually
does not clear the screen but only writes updates on required lines.
Sometimes the written lines exceed the terminal lines and people
resize the window which is not detected by cansniffer.
With entering <SPACE><ENTER> in interactive mode the screen can be
forced to redraw after resizing the terminal window.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Convert cansniffer from CAN_BCM to CAN_RAW sockets and handle the
content filter in user space. Conversion CAN_RAW including slot
concept and sorting contributed by coryjfowler.
Functional changes visible to users:
- New format for settings file
- New command '8' to switch in a compact binary view for 80 columns view
- New head line layout
- The gap time between CAN frames is displayed in milli seconds (ms)
- The interactive filters support 29 bit CAN IDs
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Clean up readsettings() and terminate when the settings file
'sniffset.*' is not found when given on commandline.
The readsettings() status output could not be read anyway due to
instant redraw from CAN frames.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Remove functionalities that are not supported resp. can not be implemented
after the CAN_BCM to CAN_RAW conversion of cansnifffer.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The basename() function needs libgen.h to be included as otherwise this
will fail to compile in some environments.
Reported-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When notching marked (and colored) bits with the interactive '#' command
the binary output omits colored bits - as intended.
But when switching back to the hex and ASCII output the bytes with
notched bits remained uncolored even when some bits inside the hex bytes
would have needed to be colored.
The check for the colored output was a logical AND operation which is
fine for the binary representation but needed to be a bit-wise operation
in the hex/ASCII byte mode case.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The gap between two consecutive frames of a specific has been calculated in
handle_timeo() instead of handle_bcm() which lead to values that where
at minimum the loop time of the display refresh.
The effect can be seen when displaying a 10ms gap CAN frame with a 200ms
display refresh (option -l 20 => default) in opposite to a 10ms display
refresh (option -l 1).
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In commit da33f96edf ("isotpsniffer: Add support for llopts") the
setsockopt() syscall for the link layer options CAN_ISOTP_LL_OPTS
has been added.
Unfortunately the syscall has been invoked even if there were no values
given on the command line and 'zero values' have been passed to the
kernel which correctly answered with -EINVAL.
And a missing check for a mandatory non-zero value for the MTU.
Fixes: da33f96edf ("isotpsniffer: Add support for llopts")
Reported by: https://github.com/ikuyas
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In commit da33f96edf ("isotpsniffer: Add support for llopts") the setsockopt
call has been executed twice. (copy & paste issue?)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The tool 'candump' is used to dump CAN traffic to stdout or logfile.
In early days where the in-kernel CAN gateway (can-gw) with the cangw tool was
not yet implemented the bridging functionality allowed to send received (and
filtered) CAN frames to another outgoing CAN interface.
As we now have can-gw and sending CAN frames from a 'reading tool' seems wrong
especially from the Unix philosophy "Write programs that do one thing and do
it well." this patch removes the obsolete functionality from candump.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When -Wformat-overflow= is enabled the gcc notes ...
"‘sprintf’ output between 30 and 82 bytes into a destination of size xx"
Increasing the buffer for the file name to 83 bytes removes the warning.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In 'classic' CAN 2.0 the RTR frames contain a length information in the
can_dlc field of a CAN frame control section. This length can be passed
to 'cansend' which has not been documented in the help text so far.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The documentation stated that the CAN ID is assumed to be an extended CAN
identifier (29 bit ID / EFF) when "can_id and can_mask are both 8 digits".
The check for the CAN ID length to be 8 is common in other CAN utils
(e.g. cansend) but it has never been implemented in candump.
This patch adds that check for EFF CAN IDs and clarifies the documentation.
Thanks to Nick for pointing out this inconsistency!
Reported-by: Nick Elmschig <nick@ikerobotics.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
With commit 33a9249571 ("slcand: daemonise only once setup is complete")
the daemonize syscall is moved behind serial tty setup.
This patch moves the missing assignment of the loop variable slcand_running
to get it into the code context of the while() loop.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Hardware timestamps have been introduced in Linux 2.6.30. Check for the
availability of SO_TIMESTAMPING and print an appropriate error message if
missing. Additionally fix some style issues and define the proper length
of ctrlmsg[].
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
GitHub user 'crossband' raised an issue regarding the strict-aliasing compiler
warning in his specific setup: https://github.com/linux-can/can-utils/issues/42
In fact memcpy() and memset() are a better solution than the former pointer
magics, so remove the issues and the compiler warning flag too.
Reported-by: crossband (https://github.com/crossband)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Alan sent a pull request to update the README.md with some markdown tweaks
and a SocketCAN logo. Good idea!
After creating a SocketCAN logo PNG in the can-logos repository we can
reference the PNG inside the linux-can organization.
A license file needs to be added too - but this has to be discussed on the
mailing list first.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The cmdlinename[i] output contains the filter definitions e.g.
'can0,300:700' but you want to see only 'can0' when printing on stderr.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
listen-only option (-l) has been added to slcan-attach in oct 2015.
It is now replicated in slcand
Signed-off-by: interlocuteur <gallard@mmic.net>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Upstream commit ba61a8d9d780980e8284355a0be750897e7af212
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=ba61a8d9d780980e8284355a0be750897e7af212
The can subsystem communicates with user space using a bcm_msg_head
header, which contains two timestamps. This is problematic for
multiple reasons:
a) The structure layout is currently incompatible between 64-bit
user space and 32-bit user space, and cannot work in compat
mode (other than x32).
b) The timeval structure layout will change in 32-bit user
space when we fix the y2038 overflow problem by redefining
time_t to 64-bit, making new 32-bit user space incompatible
with the current kernel interface.
Cars last a long time and often use old kernels, so the actual
users of this code are the most likely ones to migrate to y2038
safe user space.
This tries to work around part of the problem by changing the
publicly visible user interface in the header, but not the binary
interface. Fortunately, the values passed around in the structure
are relative times and do not actually suffer from the y2038
overflow, so 32-bit is enough here.
We replace the use of 'struct timeval' with a newly defined
'struct bcm_timeval' that uses the exact same binary layout
as before and that still suffers from problem a) but not problem
b).
The downside of this approach is that any user space program
that currently assigns a timeval structure to these members
rather than writing the tv_sec/tv_usec portions individually
will suffer a compile-time error when built with an updated
kernel header. Fixing this error makes it work fine with old
and new headers though.
We could address problem a) by using '__u32' or 'int' members
rather than 'long', but that would have a more significant
downside in also breaking support for all existing 64-bit user
binaries that might be using this interface, which is likely
not acceptable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org
Cc: linux-api@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Similar to referencing iptables rules by their line number this UID allows to
reference created routing jobs, e.g. to alter configured data modifications.
The UID is an optional non-zero value which can be provided at routing job
creation time. When the UID is set the UID replaces the data modification
configuration as job identification attribute e.g. at job removal time.
The UID option is provided by mainline Linux 4.2+
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CAN_RAW socket can set multiple CAN identifier specific filters that lead
to multiple filters in the af_can.c filter processing. These filters are
indenpendent from each other which leads to logical OR'ed filters when applied.
This socket option joines the given CAN filters in the way that only CAN frames
are passed to user space that matched *all* given CAN filters. The semantic for
the applied filters is therefore changed to a logical AND.
This is useful especially when the filterset is a combination of filters where
the CAN_INV_FILTER flag is set in order to notch single CAN IDs or CAN ID
ranges from the incoming traffic.
Example:
candump can0,100~7FF,200~7FF,400~7FF (logical OR'ed filters)
candump can0,100~7FF,200~7FF,400~7FF,J (logical AND'ed filters)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Oliver Hartkopp
