Based on kernel version 6.11
. Page generated on 2024-09-24 08:21 EST
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 | .. SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) ==================== ISO 15765-2 (ISO-TP) ==================== Overview ======== ISO 15765-2, also known as ISO-TP, is a transport protocol specifically defined for diagnostic communication on CAN. It is widely used in the automotive industry, for example as the transport protocol for UDSonCAN (ISO 14229-3) or emission-related diagnostic services (ISO 15031-5). ISO-TP can be used both on CAN CC (aka Classical CAN) and CAN FD (CAN with Flexible Datarate) based networks. It is also designed to be compatible with a CAN network using SAE J1939 as data link layer (however, this is not a requirement). Specifications used ------------------- * ISO 15765-2:2024 : Road vehicles - Diagnostic communication over Controller Area Network (DoCAN). Part 2: Transport protocol and network layer services. Addressing ---------- In its simplest form, ISO-TP is based on two kinds of addressing modes for the nodes connected to the same network: * physical addressing is implemented by two node-specific addresses and is used in 1-to-1 communication. * functional addressing is implemented by one node-specific address and is used in 1-to-N communication. Three different addressing formats can be employed: * "normal" : each address is represented simply by a CAN ID. * "extended": each address is represented by a CAN ID plus the first byte of the CAN payload; both the CAN ID and the byte inside the payload shall be different between two addresses. * "mixed": each address is represented by a CAN ID plus the first byte of the CAN payload; the CAN ID is different between two addresses, but the additional byte is the same. Transport protocol and associated frame types --------------------------------------------- When transmitting data using the ISO-TP protocol, the payload can either fit inside one single CAN message or not, also considering the overhead the protocol is generating and the optional extended addressing. In the first case, the data is transmitted at once using a so-called Single Frame (SF). In the second case, ISO-TP defines a multi-frame protocol, in which the sender provides (through a First Frame - FF) the PDU length which is to be transmitted and also asks for a Flow Control (FC) frame, which provides the maximum supported size of a macro data block (``blocksize``) and the minimum time between the single CAN messages composing such block (``stmin``). Once this information has been received, the sender starts to send frames containing fragments of the data payload (called Consecutive Frames - CF), stopping after every ``blocksize``-sized block to wait confirmation from the receiver which should then send another Flow Control frame to inform the sender about its availability to receive more data. How to Use ISO-TP ================= As with others CAN protocols, the ISO-TP stack support is built into the Linux network subsystem for the CAN bus, aka. Linux-CAN or SocketCAN, and thus follows the same socket API. Creation and basic usage of an ISO-TP socket -------------------------------------------- To use the ISO-TP stack, ``#include <linux/can/isotp.h>`` shall be used. A socket can then be created using the ``PF_CAN`` protocol family, the ``SOCK_DGRAM`` type (as the underlying protocol is datagram-based by design) and the ``CAN_ISOTP`` protocol: .. code-block:: C s = socket(PF_CAN, SOCK_DGRAM, CAN_ISOTP); After the socket has been successfully created, ``bind(2)`` shall be called to bind the socket to the desired CAN interface; to do so: * a TX CAN ID shall be specified as part of the sockaddr supplied to the call itself. * a RX CAN ID shall also be specified, unless broadcast flags have been set through socket option (explained below). Once bound to an interface, the socket can be read from and written to using the usual ``read(2)`` and ``write(2)`` system calls, as well as ``send(2)``, ``sendmsg(2)``, ``recv(2)`` and ``recvmsg(2)``. Unlike the CAN_RAW socket API, only the ISO-TP data field (the actual payload) is sent and received by the userspace application using these calls. The address information and the protocol information are automatically filled by the ISO-TP stack using the configuration supplied during socket creation. In the same way, the stack will use the transport mechanism when required (i.e., when the size of the data payload exceeds the MTU of the underlying CAN bus). The sockaddr structure used for SocketCAN has extensions for use with ISO-TP, as specified below: .. code-block:: C struct sockaddr_can { sa_family_t can_family; int can_ifindex; union { struct { canid_t rx_id, tx_id; } tp; ... } can_addr; } * ``can_family`` and ``can_ifindex`` serve the same purpose as for other SocketCAN sockets. * ``can_addr.tp.rx_id`` specifies the receive (RX) CAN ID and will be used as a RX filter. * ``can_addr.tp.tx_id`` specifies the transmit (TX) CAN ID ISO-TP socket options --------------------- When creating an ISO-TP socket, reasonable defaults are set. Some options can be modified with ``setsockopt(2)`` and/or read back with ``getsockopt(2)``. General options ~~~~~~~~~~~~~~~ General socket options can be passed using the ``CAN_ISOTP_OPTS`` optname: .. code-block:: C struct can_isotp_options opts; ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_OPTS, &opts, sizeof(opts)) where the ``can_isotp_options`` structure has the following contents: .. code-block:: C struct can_isotp_options { u32 flags; u32 frame_txtime; u8 ext_address; u8 txpad_content; u8 rxpad_content; u8 rx_ext_address; }; * ``flags``: modifiers to be applied to the default behaviour of the ISO-TP stack. Following flags are available: * ``CAN_ISOTP_LISTEN_MODE``: listen only (do not send FC frames); normally used as a testing feature. * ``CAN_ISOTP_EXTEND_ADDR``: use the byte specified in ``ext_address`` as an additional address component. This enables the "mixed" addressing format if used alone, or the "extended" addressing format if used in conjunction with ``CAN_ISOTP_RX_EXT_ADDR``. * ``CAN_ISOTP_TX_PADDING``: enable padding for transmitted frames, using ``txpad_content`` as value for the padding bytes. * ``CAN_ISOTP_RX_PADDING``: enable padding for the received frames, using ``rxpad_content`` as value for the padding bytes. * ``CAN_ISOTP_CHK_PAD_LEN``: check for correct padding length on the received frames. * ``CAN_ISOTP_CHK_PAD_DATA``: check padding bytes on the received frames against ``rxpad_content``; if ``CAN_ISOTP_RX_PADDING`` is not specified, this flag is ignored. * ``CAN_ISOTP_HALF_DUPLEX``: force ISO-TP socket in half duplex mode (that is, transport mechanism can only be incoming or outgoing at the same time, not both). * ``CAN_ISOTP_FORCE_TXSTMIN``: ignore stmin from received FC; normally used as a testing feature. * ``CAN_ISOTP_FORCE_RXSTMIN``: ignore CFs depending on rx stmin; normally used as a testing feature. * ``CAN_ISOTP_RX_EXT_ADDR``: use ``rx_ext_address`` instead of ``ext_address`` as extended addressing byte on the reception path. If used in conjunction with ``CAN_ISOTP_EXTEND_ADDR``, this flag effectively enables the "extended" addressing format. * ``CAN_ISOTP_WAIT_TX_DONE``: wait until the frame is sent before returning from ``write(2)`` and ``send(2)`` calls (i.e., blocking write operations). * ``CAN_ISOTP_SF_BROADCAST``: use 1-to-N functional addressing (cannot be specified alongside ``CAN_ISOTP_CF_BROADCAST``). * ``CAN_ISOTP_CF_BROADCAST``: use 1-to-N transmission without flow control (cannot be specified alongside ``CAN_ISOTP_SF_BROADCAST``). NOTE: this is not covered by the ISO 15765-2 standard. * ``CAN_ISOTP_DYN_FC_PARMS``: enable dynamic update of flow control parameters. * ``frame_txtime``: frame transmission time (defined as N_As/N_Ar inside the ISO standard); if ``0``, the default (or the last set value) is used. To set the transmission time to ``0``, the ``CAN_ISOTP_FRAME_TXTIME_ZERO`` macro (equal to 0xFFFFFFFF) shall be used. * ``ext_address``: extended addressing byte, used if the ``CAN_ISOTP_EXTEND_ADDR`` flag is specified. * ``txpad_content``: byte used as padding value for transmitted frames. * ``rxpad_content``: byte used as padding value for received frames. * ``rx_ext_address``: extended addressing byte for the reception path, used if the ``CAN_ISOTP_RX_EXT_ADDR`` flag is specified. Flow Control options ~~~~~~~~~~~~~~~~~~~~ Flow Control (FC) options can be passed using the ``CAN_ISOTP_RECV_FC`` optname to provide the communication parameters for receiving ISO-TP PDUs. .. code-block:: C struct can_isotp_fc_options fc_opts; ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_RECV_FC, &fc_opts, sizeof(fc_opts)); where the ``can_isotp_fc_options`` structure has the following contents: .. code-block:: C struct can_isotp_options { u8 bs; u8 stmin; u8 wftmax; }; * ``bs``: blocksize provided in flow control frames. * ``stmin``: minimum separation time provided in flow control frames; can have the following values (others are reserved): * 0x00 - 0x7F : 0 - 127 ms * 0xF1 - 0xF9 : 100 us - 900 us * ``wftmax``: maximum number of wait frames provided in flow control frames. Link Layer options ~~~~~~~~~~~~~~~~~~ Link Layer (LL) options can be passed using the ``CAN_ISOTP_LL_OPTS`` optname: .. code-block:: C struct can_isotp_ll_options ll_opts; ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_LL_OPTS, &ll_opts, sizeof(ll_opts)); where the ``can_isotp_ll_options`` structure has the following contents: .. code-block:: C struct can_isotp_ll_options { u8 mtu; u8 tx_dl; u8 tx_flags; }; * ``mtu``: generated and accepted CAN frame type, can be equal to ``CAN_MTU`` for classical CAN frames or ``CANFD_MTU`` for CAN FD frames. * ``tx_dl``: maximum payload length for transmitted frames, can have one value among: 8, 12, 16, 20, 24, 32, 48, 64. Values above 8 only apply to CAN FD traffic (i.e.: ``mtu = CANFD_MTU``). * ``tx_flags``: flags set into ``struct canfd_frame.flags`` at frame creation. Only applies to CAN FD traffic (i.e.: ``mtu = CANFD_MTU``). Transmission stmin ~~~~~~~~~~~~~~~~~~ The transmission minimum separation time (stmin) can be forced using the ``CAN_ISOTP_TX_STMIN`` optname and providing an stmin value in microseconds as a 32bit unsigned integer; this will overwrite the value sent by the receiver in flow control frames: .. code-block:: C uint32_t stmin; ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_TX_STMIN, &stmin, sizeof(stmin)); Reception stmin ~~~~~~~~~~~~~~~ The reception minimum separation time (stmin) can be forced using the ``CAN_ISOTP_RX_STMIN`` optname and providing an stmin value in microseconds as a 32bit unsigned integer; received Consecutive Frames (CF) which timestamps differ less than this value will be ignored: .. code-block:: C uint32_t stmin; ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_RX_STMIN, &stmin, sizeof(stmin)); Multi-frame transport support ----------------------------- The ISO-TP stack contained inside the Linux kernel supports the multi-frame transport mechanism defined by the standard, with the following constraints: * the maximum size of a PDU is defined by a module parameter, with an hard limit imposed at build time. * when a transmission is in progress, subsequent calls to ``write(2)`` will block, while calls to ``send(2)`` will either block or fail depending on the presence of the ``MSG_DONTWAIT`` flag. * no support is present for sending "wait frames": whether a PDU can be fully received or not is decided when the First Frame is received. Errors ------ Following errors are reported to userspace: RX path errors ~~~~~~~~~~~~~~ ============ =============================================================== -ETIMEDOUT timeout of data reception -EILSEQ sequence number mismatch during a multi-frame reception -EBADMSG data reception with wrong padding ============ =============================================================== TX path errors ~~~~~~~~~~~~~~ ========== ================================================================= -ECOMM flow control reception timeout -EMSGSIZE flow control reception overflow -EBADMSG flow control reception with wrong layout/padding ========== ================================================================= Examples ======== Basic node example ------------------ Following example implements a node using "normal" physical addressing, with RX ID equal to 0x18DAF142 and a TX ID equal to 0x18DA42F1. All options are left to their default. .. code-block:: C int s; struct sockaddr_can addr; int ret; s = socket(PF_CAN, SOCK_DGRAM, CAN_ISOTP); if (s < 0) exit(1); addr.can_family = AF_CAN; addr.can_ifindex = if_nametoindex("can0"); addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; ret = bind(s, (struct sockaddr *)&addr, sizeof(addr)); if (ret < 0) exit(1); /* Data can now be received using read(s, ...) and sent using write(s, ...) */ Additional examples ------------------- More complete (and complex) examples can be found inside the ``isotp*`` userland tools, distributed as part of the ``can-utils`` utilities at: https://github.com/linux-can/can-utils |