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.
Oliver Hartkopp
Fabián Inostroza
ajneu
Urs Thuermann
Uwe Kleine-König
Alexander Stein
Yegor Yefremov
Marc Kleine-Budde
Wolfgang Grandegger