Usually the ISO 15765-2 protocol is a point-to-point protocol to transfer
segmented PDUs to a dedicated receiver. This receiver sends a flow control
message to specify protocol options and timings (e.g. block size / STmin).
The so called functional addressing communication allows a 1:N
communication but is limited to a single frame length.
The new CAN_ISOTP_CF_BROADCAST flag introduced in Linux 5.19 allows an
unconfirmed 1:N communication with PDU lengths that would not fit into a
single frame. This feature is not covered by the ISO 15765-2 standard.
The isotpsend tool gets a new option '-C' to enable this unconfirmed 1:N
communication by setting the CAN_ISOTP_CF_BROADCAST flag.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
- update isotp.h include file
- update maximum PDU (buffer) size to 64kByte buffer
- support setting of N_As (frame_txtime) to zero
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
if_nametoindex() returns zero and a specific errno in the case the network
interface does not exist. The missing check leads to the use of the 'any'
CAN device but leaves the user alone as the user gets no error message.
Reported-by: Lothar Rubusch <lotophagon@protonmail.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the
CAN_ISOTP socket is switched into functional addressing mode, where
only single frame (SF) protocol data units can be send on the specified
CAN interface and the given tp.tx_id after bind().
In opposite to normal and extended addressing this socket does not
register a CAN-ID for reception which would be needed for a 1-to-1
ISOTP connection with a segmented bi-directional data transfer.
The new option '-S' sets the CAN_ISOTP_SF_BROADCAST to test the option
with different length settings, e.g. link layer data lengths.
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>
replaced strcpy(if_name, argv[x]) + ioctl by if_idx = if_nametoindex(argv[x])
to avoid overflows caused by long user input.
Signed-off-by: Sven Schmitt <sven.schmitt@gmx.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Allow to specify the TX and RX padding content separately.
Due to the optional values it is possible to provide either TX or RX values
which enables and set the given values.
-p 55:AA => TX padding 0x55, RX padding 0xAA
-p 55 => TX padding 0x55
-p 55: => TX padding 0x55
-p :AA => RX padding 0xAA
Additionally the comment for the -P <mode> option was updated to point out the
checking mode of the padding in the received PDUs (rx padding).
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Enable to pass the optional second extended address with the '-x' option and
do not pollute the command line options with just another '-X' option.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As requested by Laurent Vaudoit the extended address can be different in the
tx and he rx path:
(..) how can i have a segmented transfer like this:
0x6a7 0x55 0x10 0x08 ........
0x687 0xAA 0x30 0x00 0x00
0x6a7 0x55 0x21 .....
The connection i need is between two ECU, using IDs 0x6a7/687 and one has
adress extension 0x55, the other 0xAA (this adressing method is used on some
FIAT ECUs for example).
http://marc.info/?l=linux-can&m=140354647413513&w=2
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Allow PDU sizes greater than 4095 to be able to check the correct
implementation of the kernel socket API error handlings.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
misbehave for regression tests.
CAN_ISOTP_TX_STMIN:
Set a value in nano secs that's used as minimum CF gap by the sender.
This value is used instead of the value provided by the receiver inside the FC.
CAN_ISOTP_RX_STMIN:
Ignores received CF frames which timestamps differ less than this value in nano
secs. This is used to test the receivers misbehaviour when the receiver
provides a lower stmin value that he's able to cope with. Received CF frames
are silently dropped when they come faster than specified by this value.
Oliver Hartkopp
Rosen Penev
Alexander Gerasiov
Yegor Yefremov
Sven Schmitt
Marc Kleine-Budde