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>
As seen in https://github.com/linux-can/can-utils/issues/150 the logfile
format switch ignores the silent mode switch.
Fix this by checking the silent mode when using logfile format on stdout.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As remarked by Victor in https://github.com/linux-can/can-utils/issues/150
the output in the case of silent mode has puzzled line feeds.
Reported-by: Victor Cushman <VictorSCushman@gmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When using the -b/-B option to send received CAN frames to the brigde interface
the sending failed when processing CAN FD frames. This patch enables CAN FD on
the socket for the bridging interface.
https://github.com/linux-can/can-utils/issues/104
Reported-by: https://github.com/jm3lee
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>
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>
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>
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>
Calculations using unsigned integer types are done modulo U*INT_MAX+1,
so you get the correct difference of two values by simply subtracting.
No special handling for overflow is neccessary.
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The creation of the logfile format was using fprint_canframe() and two other
fprintf() calls to produce a single logfile format line. Instead of using
fprint_canframe() use sprint_canframe() directly and reduce the printf() calls
from three to one.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Added -x option to print extra message infos per frame:
RX/TX : Indicates whether the frame was sent or received from the local host
BRS : bit rate setting enabled (CAN FD only)
ESI : error state indicator (CAN FD only)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Added new view CANLIB_VIEW_INDENT_SFF flags to fix the sloppy output of
fprint_long_canframe() when mixing EFF & SFF CAN identifiers.
candump: Once an EFF frame is detected the indention is enabled.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This is a major upgrade of the basic tools to handle CAN FD frames.
The library to parse and print CAN frames and logfiles has been extended.
In detail:
asc2log.c | 5 +
candump.c | 24 ++++---
cangen.c | 172 +++++++++++++++++++++++++++++++++------------------
canlogserver.c | 28 +++++---
canplayer.c | 25 ++++---
cansend.c | 55 ++++++++++++----
lib.c | 189 ++++++++++++++++++++++++++++++++++++++-------------------
lib.h | 109 ++++++++++++++++++++++++--------
log2asc.c | 8 +-
log2long.c | 26 ++++++-
10 files changed, 440 insertions(+), 201 deletions(-)
asc2log.c / log2asc.c
- updates for new lib functions
- still can only handle CAN2.0 frames (no new info about ASC file layout)
log2long.c / canlogserver.c / canplayer.c
- updates for new lib functions to handle CAN FD
lib.h / lib.c
- reworked lib functions to handle CAN FD
- parse_canframe() now returns CAN_MTU and CANFD_MTU on success, 0 at failure
- added can_dlc2len() and can_len2dlc() helpers
- moved hexstring2candata to hexstring2data to support simple byte buffers
- in the long CAN frame representation use %03X/%08X instead of %3X/%8X
- introduced unified buffer size definitions for ASCII CAN frames
- updated documentation
cangen.c
- support CAN FD frames (added -f option to create CAN FD frames)
- added -m option ('mix') to create random extended / RTR / CAN FD frames
- fixed the 'fixed data' option which was zero'ing the payload by the time
- updated help text
candump.c
- support CAN FD frames (print, bridge, log)
- distinguish frame types by length info: [0] = CAN2.0 [00] = CAN FD frame
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
If "candump" is called with the option "-e", the error messages are
dumped in human readable format:
# candump -e any,0:0,#FFFFFFFF
...
can0 20000088 [8] 00 00 80 19 00 00 00 00 ERRORFRAME
protocol-violation{{error-on-tx}{acknowledge-slot}}
bus-error
error-counter{tx{128}rx{97}}
...
can0 2000008C [8] 00 08 80 19 00 00 00 00 ERRORFRAME
controller-problem{tx-error-warning}
protocol-violation{{error-on-tx}{acknowledge-slot}}
bus-error
error-counter{tx{128}rx{97}}
"candump" actually calles a library function snprintf_can_error_frame()
to do the formatting. It could be used for other purposes as well.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
On 64bit systems a 'long' is a 64bit value but the target values of scanf()
are always 32bit in the affected code - which means just an 'unsigned int'.
Unsigned int is fine on 32 and 64 bit systems.
Thanks to Andre Naujoks for reporting this issue.
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=3b885787ea4112eaa80945999ea0901bf742707f
This is done by using recvmsg() instead of recvfrom() to allow the timestamp
and the dropcounter to be received within one syscall.
When the application (here 'candump') ist not fast enough to process the
incomming CAN frames the frames are dropped in the socket receive queue.
When this happens and '-d' is set, we get this info now:
DROPCOUNT: dropped 1 CAN frame on 'xxx' socket (total drops 1)
Due to a wrong safety check in af_can.c it was not possible to filter
for SFF frames with a specific CAN identifier without getting the
same selected CAN identifier from a received EFF frame also.
This fix has a minimum impact on the CAN filter API as the 'sloppy'
handling is still a correct (and possibly wanted?) use-case.
Please update the can-utils (especially candump) whose filter definition
on the commandline made assumptions to correct the user input that are
probably unwanted now.
Thanks to Kurt van Dijck for pointing at this issue!
Signed-Off-by: Oliver Hartkopp <oliver@hartkopp.net>
Most SocketCAN userspace tools (like cansend) recognize the EFF by the
stringlength of the given CAN-ID: 3 -> SFF , 8 -> EFF.
This was missing in the candump filter definition and therefore the
values had to be specified with the CAN_EFF_FLAG set in the value, e.g.
92345678 for the extended CAN-ID 12345678 - this was not really nice.
Now the filtersets for extended frames can be specified as expected:
12345678:1FFFFFFF to filter for only 12345678 extended CAN-ID
000000AA:1FFFFFFF to filter for only AA extended CAN-ID.
Gary Bisson
Oliver Hartkopp
Alexander GQ Gerasiov
Yegor Yefremov
Nick Elmschig
Fabián Inostroza
ajneu
Urs Thuermann
Uwe Kleine-König
Alexander Stein
Marc Kleine-Budde
Wolfgang Grandegger