| isotpdump.c: In function ‘print_uds_message’:
| isotpdump.c:94:29: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
| } else if (service >= 0x10 && service <= 0x3E ||
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
| isotpdump.c:96:22: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
| service >= 0xBA && service <= 0xBE)
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The J1939 errqueue is a feedback interface to notify userspace
applications about actual transfer status. For now we can get
information about amount of data already send to the peer and errors
if session was aborted.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Make poller to be a main part of the send loop. It should make
application more understandable.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
No information from recvfrom() is currently used. So, it is enough to
use plain recv().
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
with latest UAPI version we should set this flag to be allowed to send
broadcast frames with broadcast destination address. Even if on CAN
every thing is a broadcast...
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Accordint to the new UAPI version, bind() with PGN set, should not be used
for destination PGN.
This change should work with new and old version of UAPI.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
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>
Currently if we send lots of bytes, test1939 output will get unreadable.
Make it easier to read by splitting output dump.
New format will looks as following example:
root@DistroKit:~ testj1939 can0:0x90 -r
80 12300: 01 23 45 67 89 ab cd ef
00008 01 23 45 67 89 ab cd ef
00010 01 23 45 67 89 ab cd ef
00018 01 23 45 67 89 ab cd ef
00020 01 23 45 67 89 ab cd ef
00028 01 23 45 67 89 ab cd ef
00030 01 23 45 67 89 ab cd ef
00038 01 23 45 67 89 ab cd ef
00040 01 23 45 67 89 ab cd ef
00048 01 23 45 67 89 ab cd ef
00050 01 23 45 67 89 ab cd ef
00058 01 23 45 67 89 ab cd ef
00060 01 23 45 67 89 ab cd ef
00068 01 23 45 67 89 ab cd ef
00070 01 23 45 67 89 ab cd ef
00078 01 23 45 67 89 ab cd ef
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Currently if we set size which is more then 128 byte
will silently ignore provided value and send only maximal
supported size.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
This is a warning coming up on Android (ARM) platform.
Clang 4.x creates a false positive here: the can_id is the first
(and aligned) value in the packed struct modattr, so it's always
aligned if the struct itself is aligned.
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>
Marc Kleine-Budde
Oliver Hartkopp
tr1core
Oleksij Rempel
Marc Kleine-Budde
Oleksij Rempel
Tomasz Wasilczyk
Nick Elmschig