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>
This option is needed for j1939 socket functionality test.
Connects wihout bind should not work.
Signed-off-by: Bastian Stender <bst@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
This option is needed for j1939 socket functionality test.
Binding to a socket and rebinding to the socket with e.g. a different SA
should work.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Bastian Stender <bst@pengutronix.de>
In some cases we can get local TX echo after remote response
for same TXed message was already received.
For applications which relay on proper order of TXed and RXed
message this will be fatal.
With this patch the package generating side will test if TX and RX are
properly ordered.
Currently with following commands, this issue can be easily
reproducible:
canfdtest -g can0 &
while(true); do chrt 40 dd if=/dev/zero of=/dev/null count=10000; done
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Scripts can be configured to handle different SIGnals and
return codes in different ways. In this case it is better
to forward received signal, instead of converting it to return 0.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Oleksij Rempel
Oleksij Rempel
Marc Kleine-Budde
Marc Kleine-Budde
Oliver Hartkopp
Tomasz Wasilczyk
Nick Elmschig
Bastian Stender
Yegor Yefremov
Joel Winarske