linux-can ISOTP module

linux-can ISOTP module

[laurent vaudoit]

Hi all, 
i'm using isotp module for some work purpose,
on a imx25 board, with kernel 3.10.

I have integrated the module isotp and the correct header file in my
kernel.

I'm able to use isotpsend adn isotprecv functions but i have some questions:

Comming from automotiv diagnostic, we are used to configure a lots of 
parameters in our baremetal Iso15765 protocol firmware (stmin, 
bs,n_cs,n_bs...)
I have not seen anything to parameter timings such as n_cs, n_bs.
Is their something i missed?

For extended adressing method, it seems that both rx and tx frame must have 
the same first byte in can frame (the one set by ext_address field of the 
structure). This is correct for mixed addressing method (see Iso15765-2), 
but for extended adressing method, we should be able to specify different 
Target and source adress. I have not seen anything like this.

Last point, if i want to send a 255 bytes frame, with bs=0 and stmin=0 
(requested by the receiver), transfer start well SN 0x01 to SN 0x0B) but 
after i have a frame with SN 0x03 instead of SN = 0x0C and everything stop.

Does anyone encountered this kind of problem?

I will search for this problem as it is a big problem if we want to make 
some download through isotp.

Thanks in advance for your answer

Best regards

Laurent

Re: linux-can ISOTP module

[Oliver Hartkopp]

Hi Laurent,

On 04.06.2014 14:55, laurent vaudoit wrote:

> i'm using isotp module for some work purpose,
> on a imx25 board, with kernel 3.10.
> 
> I have integrated the module isotp and the correct header file in my
> kernel.
> 
> I'm able to use isotpsend adn isotprecv functions but i have some questions:
> 
> Comming from automotiv diagnostic, we are used to configure a lots of 
> parameters in our baremetal Iso15765 protocol firmware (stmin, 
> bs,n_cs,n_bs...)
> I have not seen anything to parameter timings such as n_cs, n_bs.
> Is their something i missed?

Definitely :-)

See the help text from isotprecv:

---

Usage: isotprecv [options] <CAN interface>
Options: -s <can_id>  (source can_id. Use 8 digits for extended IDs)
         -d <can_id>  (destination can_id. Use 8 digits for extended IDs)
         -x <addr>    (extended addressing mode.)
         -p <byte>    (set and enable padding byte)
         -P <mode>    (check padding in SF/CF. (l)ength (c)ontent (a)ll)
         -b <bs>      (blocksize. 0 = off)
         -m <val>     (STmin in ms/ns. See spec.)
         -f <time ns> (force rx stmin value in nanosecs)
         -w <num>     (max. wait frame transmissions.)
         -l           (loop: do not exit after pdu receiption.)

CAN IDs and addresses are given and expected in hexadecimal values.
The pdu data is written on STDOUT in space separated ASCII hex values.

---

Please check out the isotprecv.c source code to see how these parameters are
to be set with setsockopt() syscall.

See isotp.h for all socketoptions and structures:
https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:include/socketcan/can/isotp.h

isotprecv.c and isotpsend.c make use of all possible options which can be
triggerd by commandline options.

> 
> For extended adressing method, it seems that both rx and tx frame must have 
> the same first byte in can frame (the one set by ext_address field of the 
> structure). This is correct for mixed addressing method (see Iso15765-2), 
> but for extended adressing method, we should be able to specify different 
> Target and source adress. I have not seen anything like this.

One socket represents one virtual 1:1 connection (defined by two CAN
identifiers and optional with one address extension) on the CAN bus.

If you want to receive from different sources just create different sockets
(and e.g. use select() to listen to many open socket file descriptors).

The protocol engine has always to answer with the correct address information.

> 
> Last point, if i want to send a 255 bytes frame, with bs=0 and stmin=0 
> (requested by the receiver), transfer start well SN 0x01 to SN 0x0B) but 
> after i have a frame with SN 0x03 instead of SN = 0x0C and everything stop.
> 
> Does anyone encountered this kind of problem?
> 

No.

Using the isotpsend from my canfd4isotp-can-utils git repository (which
supports the -D <num> option to create a PDU with the given length:

$ ./isotpsend vcan0 -s 123 -d 321 -D 255

On another terminal it looks like this then:

$ isotprecv vcan0 -s 321 -d 123
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68
69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82
83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C
9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6
B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0
D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA
EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF

with candump:

$ candump vcan0
  vcan0  123   [8]  10 FF 01 02 03 04 05 06
  vcan0  321   [3]  30 00 00
  vcan0  123   [8]  21 07 08 09 0A 0B 0C 0D
  vcan0  123   [8]  22 0E 0F 10 11 12 13 14
  vcan0  123   [8]  23 15 16 17 18 19 1A 1B
  vcan0  123   [8]  24 1C 1D 1E 1F 20 21 22
  vcan0  123   [8]  25 23 24 25 26 27 28 29
  vcan0  123   [8]  26 2A 2B 2C 2D 2E 2F 30
  vcan0  123   [8]  27 31 32 33 34 35 36 37
  vcan0  123   [8]  28 38 39 3A 3B 3C 3D 3E
  vcan0  123   [8]  29 3F 40 41 42 43 44 45
  vcan0  123   [8]  2A 46 47 48 49 4A 4B 4C
  vcan0  123   [8]  2B 4D 4E 4F 50 51 52 53
  vcan0  123   [8]  2C 54 55 56 57 58 59 5A
  vcan0  123   [8]  2D 5B 5C 5D 5E 5F 60 61
  vcan0  123   [8]  2E 62 63 64 65 66 67 68
  vcan0  123   [8]  2F 69 6A 6B 6C 6D 6E 6F
  vcan0  123   [8]  20 70 71 72 73 74 75 76
  vcan0  123   [8]  21 77 78 79 7A 7B 7C 7D
  vcan0  123   [8]  22 7E 7F 80 81 82 83 84
  vcan0  123   [8]  23 85 86 87 88 89 8A 8B
  vcan0  123   [8]  24 8C 8D 8E 8F 90 91 92
  vcan0  123   [8]  25 93 94 95 96 97 98 99
  vcan0  123   [8]  26 9A 9B 9C 9D 9E 9F A0
  vcan0  123   [8]  27 A1 A2 A3 A4 A5 A6 A7
  vcan0  123   [8]  28 A8 A9 AA AB AC AD AE
  vcan0  123   [8]  29 AF B0 B1 B2 B3 B4 B5
  vcan0  123   [8]  2A B6 B7 B8 B9 BA BB BC
  vcan0  123   [8]  2B BD BE BF C0 C1 C2 C3
  vcan0  123   [8]  2C C4 C5 C6 C7 C8 C9 CA
  vcan0  123   [8]  2D CB CC CD CE CF D0 D1
  vcan0  123   [8]  2E D2 D3 D4 D5 D6 D7 D8
  vcan0  123   [8]  2F D9 DA DB DC DD DE DF
  vcan0  123   [8]  20 E0 E1 E2 E3 E4 E5 E6
  vcan0  123   [8]  21 E7 E8 E9 EA EB EC ED
  vcan0  123   [8]  22 EE EF F0 F1 F2 F3 F4
  vcan0  123   [8]  23 F5 F6 F7 F8 F9 FA FB
  vcan0  123   [5]  24 FC FD FE FF

with isotpdump:

$ isotpdump -s 123 -d 321 vcan0
 vcan0  123  [8]  [FF] ln: 255  data: 01 02 03 04 05 06
 vcan0  321  [3]  [FC] FC: 0 = CTS # BS: 0 = off # STmin: 0x00 = 0 ms
 vcan0  123  [8]  [CF] sn: 1    data: 07 08 09 0A 0B 0C 0D
 vcan0  123  [8]  [CF] sn: 2    data: 0E 0F 10 11 12 13 14
 vcan0  123  [8]  [CF] sn: 3    data: 15 16 17 18 19 1A 1B
 vcan0  123  [8]  [CF] sn: 4    data: 1C 1D 1E 1F 20 21 22
 vcan0  123  [8]  [CF] sn: 5    data: 23 24 25 26 27 28 29
 vcan0  123  [8]  [CF] sn: 6    data: 2A 2B 2C 2D 2E 2F 30
 vcan0  123  [8]  [CF] sn: 7    data: 31 32 33 34 35 36 37
 vcan0  123  [8]  [CF] sn: 8    data: 38 39 3A 3B 3C 3D 3E
 vcan0  123  [8]  [CF] sn: 9    data: 3F 40 41 42 43 44 45
 vcan0  123  [8]  [CF] sn: A    data: 46 47 48 49 4A 4B 4C
 vcan0  123  [8]  [CF] sn: B    data: 4D 4E 4F 50 51 52 53
 vcan0  123  [8]  [CF] sn: C    data: 54 55 56 57 58 59 5A
 vcan0  123  [8]  [CF] sn: D    data: 5B 5C 5D 5E 5F 60 61
 vcan0  123  [8]  [CF] sn: E    data: 62 63 64 65 66 67 68
 vcan0  123  [8]  [CF] sn: F    data: 69 6A 6B 6C 6D 6E 6F
 vcan0  123  [8]  [CF] sn: 0    data: 70 71 72 73 74 75 76
 vcan0  123  [8]  [CF] sn: 1    data: 77 78 79 7A 7B 7C 7D
 vcan0  123  [8]  [CF] sn: 2    data: 7E 7F 80 81 82 83 84
 vcan0  123  [8]  [CF] sn: 3    data: 85 86 87 88 89 8A 8B
 vcan0  123  [8]  [CF] sn: 4    data: 8C 8D 8E 8F 90 91 92
 vcan0  123  [8]  [CF] sn: 5    data: 93 94 95 96 97 98 99
 vcan0  123  [8]  [CF] sn: 6    data: 9A 9B 9C 9D 9E 9F A0
 vcan0  123  [8]  [CF] sn: 7    data: A1 A2 A3 A4 A5 A6 A7
 vcan0  123  [8]  [CF] sn: 8    data: A8 A9 AA AB AC AD AE
 vcan0  123  [8]  [CF] sn: 9    data: AF B0 B1 B2 B3 B4 B5
 vcan0  123  [8]  [CF] sn: A    data: B6 B7 B8 B9 BA BB BC
 vcan0  123  [8]  [CF] sn: B    data: BD BE BF C0 C1 C2 C3
 vcan0  123  [8]  [CF] sn: C    data: C4 C5 C6 C7 C8 C9 CA
 vcan0  123  [8]  [CF] sn: D    data: CB CC CD CE CF D0 D1
 vcan0  123  [8]  [CF] sn: E    data: D2 D3 D4 D5 D6 D7 D8
 vcan0  123  [8]  [CF] sn: F    data: D9 DA DB DC DD DE DF
 vcan0  123  [8]  [CF] sn: 0    data: E0 E1 E2 E3 E4 E5 E6
 vcan0  123  [8]  [CF] sn: 1    data: E7 E8 E9 EA EB EC ED
 vcan0  123  [8]  [CF] sn: 2    data: EE EF F0 F1 F2 F3 F4
 vcan0  123  [8]  [CF] sn: 3    data: F5 F6 F7 F8 F9 FA FB
 vcan0  123  [5]  [CF] sn: 4    data: FC FD FE FF

Please check out the README.isotp:

https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:README.isotp

Did you probably run your test on a real CAN interface but did not increase
the tx queue length of the CAN netdevice accordingly??

> I will search for this problem as it is a big problem if we want to make 
> some download through isotp.

I flashed several instrument clusters and climate control ECUs with this
implementation :-)

Regards,
Oliver

Re: linux-can ISOTP module

[laurent vaudoit]

Hi Oliver,
thank you for your answer.
I'm sorry but there is still somethings i do not understand.


Ok, with isotp.h api, i understand that we can parameter block size, stmin,
wftmax, transmission time (n_ax), padding.
But how can i specify the timing n_CS (time between flow control reception
and first consecutive frame) and the timing n_BS (time between first frame
reception and flow control emission)? In the same way, is it possible to
specify according timeout (n_BR for flow control timeout reception, and n_CR
for consecutive frame timeout reception)?
>
> >
> > For extended adressing method, it seems that both rx and tx frame must have
> > the same first byte in can frame (the one set by ext_address field of the
> > structure). This is correct for mixed addressing method (see Iso15765-2),
> > but for extended adressing method, we should be able to specify different
> > Target and source adress. I have not seen anything like this.
>
> One socket represents one virtual 1:1 connection (defined by two CAN
> identifiers and optional with one address extension) on the CAN bus.
>
> If you want to receive from different sources just create different sockets
> (and e.g. use select() to listen to many open socket file descriptors).
>
> The protocol engine has always to answer with the correct address information.
>
With this method, 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), but i don't see how it can work using two socket.
just after posting and some debug, i found that the problem was the
txqueulen. By increasing this parameter through ifconfig tool, i'm able to
send 255 bytes frames with stmin=0.
>
>
> Regards,
> Oliver

Regards
Laurent

On Wed, Jun 4, 2014 at 8:40 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hi Laurent,
>
> On 04.06.2014 14:55, laurent vaudoit wrote:
>
>> i'm using isotp module for some work purpose,
>> on a imx25 board, with kernel 3.10.
>>
>> I have integrated the module isotp and the correct header file in my
>> kernel.
>>
>> I'm able to use isotpsend adn isotprecv functions but i have some questions:
>>
>> Comming from automotiv diagnostic, we are used to configure a lots of
>> parameters in our baremetal Iso15765 protocol firmware (stmin,
>> bs,n_cs,n_bs...)
>> I have not seen anything to parameter timings such as n_cs, n_bs.
>> Is their something i missed?
>
> Definitely :-)
>
> See the help text from isotprecv:
>
> ---
>
> Usage: isotprecv [options] <CAN interface>
> Options: -s <can_id>  (source can_id. Use 8 digits for extended IDs)
>          -d <can_id>  (destination can_id. Use 8 digits for extended IDs)
>          -x <addr>    (extended addressing mode.)
>          -p <byte>    (set and enable padding byte)
>          -P <mode>    (check padding in SF/CF. (l)ength (c)ontent (a)ll)
>          -b <bs>      (blocksize. 0 = off)
>          -m <val>     (STmin in ms/ns. See spec.)
>          -f <time ns> (force rx stmin value in nanosecs)
>          -w <num>     (max. wait frame transmissions.)
>          -l           (loop: do not exit after pdu receiption.)
>
> CAN IDs and addresses are given and expected in hexadecimal values.
> The pdu data is written on STDOUT in space separated ASCII hex values.
>
> ---
>
> Please check out the isotprecv.c source code to see how these parameters are
> to be set with setsockopt() syscall.
>
> See isotp.h for all socketoptions and structures:
> https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:include/socketcan/can/isotp.h
>
> isotprecv.c and isotpsend.c make use of all possible options which can be
> triggerd by commandline options.
>
>>
>> For extended adressing method, it seems that both rx and tx frame must have
>> the same first byte in can frame (the one set by ext_address field of the
>> structure). This is correct for mixed addressing method (see Iso15765-2),
>> but for extended adressing method, we should be able to specify different
>> Target and source adress. I have not seen anything like this.
>
> One socket represents one virtual 1:1 connection (defined by two CAN
> identifiers and optional with one address extension) on the CAN bus.
>
> If you want to receive from different sources just create different sockets
> (and e.g. use select() to listen to many open socket file descriptors).
>
> The protocol engine has always to answer with the correct address information.
>
>>
>> Last point, if i want to send a 255 bytes frame, with bs=0 and stmin=0
>> (requested by the receiver), transfer start well SN 0x01 to SN 0x0B) but
>> after i have a frame with SN 0x03 instead of SN = 0x0C and everything stop.
>>
>> Does anyone encountered this kind of problem?
>>
>
> No.
>
> Using the isotpsend from my canfd4isotp-can-utils git repository (which
> supports the -D <num> option to create a PDU with the given length:
>
> $ ./isotpsend vcan0 -s 123 -d 321 -D 255
>
> On another terminal it looks like this then:
>
> $ isotprecv vcan0 -s 321 -d 123
> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
> 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
> 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
> 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68
> 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82
> 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C
> 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6
> B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0
> D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA
> EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
>
> with candump:
>
> $ candump vcan0
>   vcan0  123   [8]  10 FF 01 02 03 04 05 06
>   vcan0  321   [3]  30 00 00
>   vcan0  123   [8]  21 07 08 09 0A 0B 0C 0D
>   vcan0  123   [8]  22 0E 0F 10 11 12 13 14
>   vcan0  123   [8]  23 15 16 17 18 19 1A 1B
>   vcan0  123   [8]  24 1C 1D 1E 1F 20 21 22
>   vcan0  123   [8]  25 23 24 25 26 27 28 29
>   vcan0  123   [8]  26 2A 2B 2C 2D 2E 2F 30
>   vcan0  123   [8]  27 31 32 33 34 35 36 37
>   vcan0  123   [8]  28 38 39 3A 3B 3C 3D 3E
>   vcan0  123   [8]  29 3F 40 41 42 43 44 45
>   vcan0  123   [8]  2A 46 47 48 49 4A 4B 4C
>   vcan0  123   [8]  2B 4D 4E 4F 50 51 52 53
>   vcan0  123   [8]  2C 54 55 56 57 58 59 5A
>   vcan0  123   [8]  2D 5B 5C 5D 5E 5F 60 61
>   vcan0  123   [8]  2E 62 63 64 65 66 67 68
>   vcan0  123   [8]  2F 69 6A 6B 6C 6D 6E 6F
>   vcan0  123   [8]  20 70 71 72 73 74 75 76
>   vcan0  123   [8]  21 77 78 79 7A 7B 7C 7D
>   vcan0  123   [8]  22 7E 7F 80 81 82 83 84
>   vcan0  123   [8]  23 85 86 87 88 89 8A 8B
>   vcan0  123   [8]  24 8C 8D 8E 8F 90 91 92
>   vcan0  123   [8]  25 93 94 95 96 97 98 99
>   vcan0  123   [8]  26 9A 9B 9C 9D 9E 9F A0
>   vcan0  123   [8]  27 A1 A2 A3 A4 A5 A6 A7
>   vcan0  123   [8]  28 A8 A9 AA AB AC AD AE
>   vcan0  123   [8]  29 AF B0 B1 B2 B3 B4 B5
>   vcan0  123   [8]  2A B6 B7 B8 B9 BA BB BC
>   vcan0  123   [8]  2B BD BE BF C0 C1 C2 C3
>   vcan0  123   [8]  2C C4 C5 C6 C7 C8 C9 CA
>   vcan0  123   [8]  2D CB CC CD CE CF D0 D1
>   vcan0  123   [8]  2E D2 D3 D4 D5 D6 D7 D8
>   vcan0  123   [8]  2F D9 DA DB DC DD DE DF
>   vcan0  123   [8]  20 E0 E1 E2 E3 E4 E5 E6
>   vcan0  123   [8]  21 E7 E8 E9 EA EB EC ED
>   vcan0  123   [8]  22 EE EF F0 F1 F2 F3 F4
>   vcan0  123   [8]  23 F5 F6 F7 F8 F9 FA FB
>   vcan0  123   [5]  24 FC FD FE FF
>
> with isotpdump:
>
> $ isotpdump -s 123 -d 321 vcan0
>  vcan0  123  [8]  [FF] ln: 255  data: 01 02 03 04 05 06
>  vcan0  321  [3]  [FC] FC: 0 = CTS # BS: 0 = off # STmin: 0x00 = 0 ms
>  vcan0  123  [8]  [CF] sn: 1    data: 07 08 09 0A 0B 0C 0D
>  vcan0  123  [8]  [CF] sn: 2    data: 0E 0F 10 11 12 13 14
>  vcan0  123  [8]  [CF] sn: 3    data: 15 16 17 18 19 1A 1B
>  vcan0  123  [8]  [CF] sn: 4    data: 1C 1D 1E 1F 20 21 22
>  vcan0  123  [8]  [CF] sn: 5    data: 23 24 25 26 27 28 29
>  vcan0  123  [8]  [CF] sn: 6    data: 2A 2B 2C 2D 2E 2F 30
>  vcan0  123  [8]  [CF] sn: 7    data: 31 32 33 34 35 36 37
>  vcan0  123  [8]  [CF] sn: 8    data: 38 39 3A 3B 3C 3D 3E
>  vcan0  123  [8]  [CF] sn: 9    data: 3F 40 41 42 43 44 45
>  vcan0  123  [8]  [CF] sn: A    data: 46 47 48 49 4A 4B 4C
>  vcan0  123  [8]  [CF] sn: B    data: 4D 4E 4F 50 51 52 53
>  vcan0  123  [8]  [CF] sn: C    data: 54 55 56 57 58 59 5A
>  vcan0  123  [8]  [CF] sn: D    data: 5B 5C 5D 5E 5F 60 61
>  vcan0  123  [8]  [CF] sn: E    data: 62 63 64 65 66 67 68
>  vcan0  123  [8]  [CF] sn: F    data: 69 6A 6B 6C 6D 6E 6F
>  vcan0  123  [8]  [CF] sn: 0    data: 70 71 72 73 74 75 76
>  vcan0  123  [8]  [CF] sn: 1    data: 77 78 79 7A 7B 7C 7D
>  vcan0  123  [8]  [CF] sn: 2    data: 7E 7F 80 81 82 83 84
>  vcan0  123  [8]  [CF] sn: 3    data: 85 86 87 88 89 8A 8B
>  vcan0  123  [8]  [CF] sn: 4    data: 8C 8D 8E 8F 90 91 92
>  vcan0  123  [8]  [CF] sn: 5    data: 93 94 95 96 97 98 99
>  vcan0  123  [8]  [CF] sn: 6    data: 9A 9B 9C 9D 9E 9F A0
>  vcan0  123  [8]  [CF] sn: 7    data: A1 A2 A3 A4 A5 A6 A7
>  vcan0  123  [8]  [CF] sn: 8    data: A8 A9 AA AB AC AD AE
>  vcan0  123  [8]  [CF] sn: 9    data: AF B0 B1 B2 B3 B4 B5
>  vcan0  123  [8]  [CF] sn: A    data: B6 B7 B8 B9 BA BB BC
>  vcan0  123  [8]  [CF] sn: B    data: BD BE BF C0 C1 C2 C3
>  vcan0  123  [8]  [CF] sn: C    data: C4 C5 C6 C7 C8 C9 CA
>  vcan0  123  [8]  [CF] sn: D    data: CB CC CD CE CF D0 D1
>  vcan0  123  [8]  [CF] sn: E    data: D2 D3 D4 D5 D6 D7 D8
>  vcan0  123  [8]  [CF] sn: F    data: D9 DA DB DC DD DE DF
>  vcan0  123  [8]  [CF] sn: 0    data: E0 E1 E2 E3 E4 E5 E6
>  vcan0  123  [8]  [CF] sn: 1    data: E7 E8 E9 EA EB EC ED
>  vcan0  123  [8]  [CF] sn: 2    data: EE EF F0 F1 F2 F3 F4
>  vcan0  123  [8]  [CF] sn: 3    data: F5 F6 F7 F8 F9 FA FB
>  vcan0  123  [5]  [CF] sn: 4    data: FC FD FE FF
>
> Please check out the README.isotp:
>
> https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:README.isotp
>
> Did you probably run your test on a real CAN interface but did not increase
> the tx queue length of the CAN netdevice accordingly??
>
>> I will search for this problem as it is a big problem if we want to make
>> some download through isotp.
>
> I flashed several instrument clusters and climate control ECUs with this
> implementation :-)
>
> Regards,
> Oliver
>

Re: linux-can ISOTP module

[Maxime Jayat]

Hi,

Le 05/06/2014 09:16, laurent vaudoit a écrit :
> Hi Oliver,
> thank you for your answer.
> I'm sorry but there is still somethings i do not understand.
> 
> 
> Ok, with isotp.h api, i understand that we can parameter block size, stmin,
> wftmax, transmission time (n_ax), padding.
> But how can i specify the timing n_CS (time between flow control reception
> and first consecutive frame) and the timing n_BS (time between first frame
> reception and flow control emission)? In the same way, is it possible to
> specify according timeout (n_BR for flow control timeout reception, and n_CR
> for consecutive frame timeout reception)?
>>
>>>
>>> For extended adressing method, it seems that both rx and tx frame must have
>>> the same first byte in can frame (the one set by ext_address field of the
>>> structure). This is correct for mixed addressing method (see Iso15765-2),
>>> but for extended adressing method, we should be able to specify different
>>> Target and source adress. I have not seen anything like this.
>>
>> One socket represents one virtual 1:1 connection (defined by two CAN
>> identifiers and optional with one address extension) on the CAN bus.
>>
>> If you want to receive from different sources just create different sockets
>> (and e.g. use select() to listen to many open socket file descriptors).
>>
>> The protocol engine has always to answer with the correct address information.
>>
> With this method, 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), but i don't see how it can work using two socket.
I confirm.
This is a problem that we also encountered on a BMW ECU with the current
implementation of ISOTP.
The use-case is real and not currently supported.
I had to hack isotp.c, adding a socket option to be able to choose an
address extension for the reception. Probably not the best solution but
it worked.

> just after posting and some debug, i found that the problem was the
> txqueulen. By increasing this parameter through ifconfig tool, i'm able to
> send 255 bytes frames with stmin=0.
>>
>>
>> Regards,
>> Oliver
> 
> Regards
> Laurent
> 
> On Wed, Jun 4, 2014 at 8:40 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> Hi Laurent,
>>
>> On 04.06.2014 14:55, laurent vaudoit wrote:
>>
>>> i'm using isotp module for some work purpose,
>>> on a imx25 board, with kernel 3.10.
>>>
>>> I have integrated the module isotp and the correct header file in my
>>> kernel.
>>>
>>> I'm able to use isotpsend adn isotprecv functions but i have some questions:
>>>
>>> Comming from automotiv diagnostic, we are used to configure a lots of
>>> parameters in our baremetal Iso15765 protocol firmware (stmin,
>>> bs,n_cs,n_bs...)
>>> I have not seen anything to parameter timings such as n_cs, n_bs.
>>> Is their something i missed?
>>
>> Definitely :-)
>>
>> See the help text from isotprecv:
>>
>> ---
>>
>> Usage: isotprecv [options] <CAN interface>
>> Options: -s <can_id>  (source can_id. Use 8 digits for extended IDs)
>>          -d <can_id>  (destination can_id. Use 8 digits for extended IDs)
>>          -x <addr>    (extended addressing mode.)
>>          -p <byte>    (set and enable padding byte)
>>          -P <mode>    (check padding in SF/CF. (l)ength (c)ontent (a)ll)
>>          -b <bs>      (blocksize. 0 = off)
>>          -m <val>     (STmin in ms/ns. See spec.)
>>          -f <time ns> (force rx stmin value in nanosecs)
>>          -w <num>     (max. wait frame transmissions.)
>>          -l           (loop: do not exit after pdu receiption.)
>>
>> CAN IDs and addresses are given and expected in hexadecimal values.
>> The pdu data is written on STDOUT in space separated ASCII hex values.
>>
>> ---
>>
>> Please check out the isotprecv.c source code to see how these parameters are
>> to be set with setsockopt() syscall.
>>
>> See isotp.h for all socketoptions and structures:
>> https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:include/socketcan/can/isotp.h
>>
>> isotprecv.c and isotpsend.c make use of all possible options which can be
>> triggerd by commandline options.
>>
>>>
>>> For extended adressing method, it seems that both rx and tx frame must have
>>> the same first byte in can frame (the one set by ext_address field of the
>>> structure). This is correct for mixed addressing method (see Iso15765-2),
>>> but for extended adressing method, we should be able to specify different
>>> Target and source adress. I have not seen anything like this.
>>
>> One socket represents one virtual 1:1 connection (defined by two CAN
>> identifiers and optional with one address extension) on the CAN bus.
>>
>> If you want to receive from different sources just create different sockets
>> (and e.g. use select() to listen to many open socket file descriptors).
>>
>> The protocol engine has always to answer with the correct address information.
>>
>>>
>>> Last point, if i want to send a 255 bytes frame, with bs=0 and stmin=0
>>> (requested by the receiver), transfer start well SN 0x01 to SN 0x0B) but
>>> after i have a frame with SN 0x03 instead of SN = 0x0C and everything stop.
>>>
>>> Does anyone encountered this kind of problem?
>>>
>>
>> No.
>>
>> Using the isotpsend from my canfd4isotp-can-utils git repository (which
>> supports the -D <num> option to create a PDU with the given length:
>>
>> $ ./isotpsend vcan0 -s 123 -d 321 -D 255
>>
>> On another terminal it looks like this then:
>>
>> $ isotprecv vcan0 -s 321 -d 123
>> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A
>> 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34
>> 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
>> 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68
>> 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82
>> 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C
>> 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6
>> B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0
>> D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA
>> EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
>>
>> with candump:
>>
>> $ candump vcan0
>>   vcan0  123   [8]  10 FF 01 02 03 04 05 06
>>   vcan0  321   [3]  30 00 00
>>   vcan0  123   [8]  21 07 08 09 0A 0B 0C 0D
>>   vcan0  123   [8]  22 0E 0F 10 11 12 13 14
>>   vcan0  123   [8]  23 15 16 17 18 19 1A 1B
>>   vcan0  123   [8]  24 1C 1D 1E 1F 20 21 22
>>   vcan0  123   [8]  25 23 24 25 26 27 28 29
>>   vcan0  123   [8]  26 2A 2B 2C 2D 2E 2F 30
>>   vcan0  123   [8]  27 31 32 33 34 35 36 37
>>   vcan0  123   [8]  28 38 39 3A 3B 3C 3D 3E
>>   vcan0  123   [8]  29 3F 40 41 42 43 44 45
>>   vcan0  123   [8]  2A 46 47 48 49 4A 4B 4C
>>   vcan0  123   [8]  2B 4D 4E 4F 50 51 52 53
>>   vcan0  123   [8]  2C 54 55 56 57 58 59 5A
>>   vcan0  123   [8]  2D 5B 5C 5D 5E 5F 60 61
>>   vcan0  123   [8]  2E 62 63 64 65 66 67 68
>>   vcan0  123   [8]  2F 69 6A 6B 6C 6D 6E 6F
>>   vcan0  123   [8]  20 70 71 72 73 74 75 76
>>   vcan0  123   [8]  21 77 78 79 7A 7B 7C 7D
>>   vcan0  123   [8]  22 7E 7F 80 81 82 83 84
>>   vcan0  123   [8]  23 85 86 87 88 89 8A 8B
>>   vcan0  123   [8]  24 8C 8D 8E 8F 90 91 92
>>   vcan0  123   [8]  25 93 94 95 96 97 98 99
>>   vcan0  123   [8]  26 9A 9B 9C 9D 9E 9F A0
>>   vcan0  123   [8]  27 A1 A2 A3 A4 A5 A6 A7
>>   vcan0  123   [8]  28 A8 A9 AA AB AC AD AE
>>   vcan0  123   [8]  29 AF B0 B1 B2 B3 B4 B5
>>   vcan0  123   [8]  2A B6 B7 B8 B9 BA BB BC
>>   vcan0  123   [8]  2B BD BE BF C0 C1 C2 C3
>>   vcan0  123   [8]  2C C4 C5 C6 C7 C8 C9 CA
>>   vcan0  123   [8]  2D CB CC CD CE CF D0 D1
>>   vcan0  123   [8]  2E D2 D3 D4 D5 D6 D7 D8
>>   vcan0  123   [8]  2F D9 DA DB DC DD DE DF
>>   vcan0  123   [8]  20 E0 E1 E2 E3 E4 E5 E6
>>   vcan0  123   [8]  21 E7 E8 E9 EA EB EC ED
>>   vcan0  123   [8]  22 EE EF F0 F1 F2 F3 F4
>>   vcan0  123   [8]  23 F5 F6 F7 F8 F9 FA FB
>>   vcan0  123   [5]  24 FC FD FE FF
>>
>> with isotpdump:
>>
>> $ isotpdump -s 123 -d 321 vcan0
>>  vcan0  123  [8]  [FF] ln: 255  data: 01 02 03 04 05 06
>>  vcan0  321  [3]  [FC] FC: 0 = CTS # BS: 0 = off # STmin: 0x00 = 0 ms
>>  vcan0  123  [8]  [CF] sn: 1    data: 07 08 09 0A 0B 0C 0D
>>  vcan0  123  [8]  [CF] sn: 2    data: 0E 0F 10 11 12 13 14
>>  vcan0  123  [8]  [CF] sn: 3    data: 15 16 17 18 19 1A 1B
>>  vcan0  123  [8]  [CF] sn: 4    data: 1C 1D 1E 1F 20 21 22
>>  vcan0  123  [8]  [CF] sn: 5    data: 23 24 25 26 27 28 29
>>  vcan0  123  [8]  [CF] sn: 6    data: 2A 2B 2C 2D 2E 2F 30
>>  vcan0  123  [8]  [CF] sn: 7    data: 31 32 33 34 35 36 37
>>  vcan0  123  [8]  [CF] sn: 8    data: 38 39 3A 3B 3C 3D 3E
>>  vcan0  123  [8]  [CF] sn: 9    data: 3F 40 41 42 43 44 45
>>  vcan0  123  [8]  [CF] sn: A    data: 46 47 48 49 4A 4B 4C
>>  vcan0  123  [8]  [CF] sn: B    data: 4D 4E 4F 50 51 52 53
>>  vcan0  123  [8]  [CF] sn: C    data: 54 55 56 57 58 59 5A
>>  vcan0  123  [8]  [CF] sn: D    data: 5B 5C 5D 5E 5F 60 61
>>  vcan0  123  [8]  [CF] sn: E    data: 62 63 64 65 66 67 68
>>  vcan0  123  [8]  [CF] sn: F    data: 69 6A 6B 6C 6D 6E 6F
>>  vcan0  123  [8]  [CF] sn: 0    data: 70 71 72 73 74 75 76
>>  vcan0  123  [8]  [CF] sn: 1    data: 77 78 79 7A 7B 7C 7D
>>  vcan0  123  [8]  [CF] sn: 2    data: 7E 7F 80 81 82 83 84
>>  vcan0  123  [8]  [CF] sn: 3    data: 85 86 87 88 89 8A 8B
>>  vcan0  123  [8]  [CF] sn: 4    data: 8C 8D 8E 8F 90 91 92
>>  vcan0  123  [8]  [CF] sn: 5    data: 93 94 95 96 97 98 99
>>  vcan0  123  [8]  [CF] sn: 6    data: 9A 9B 9C 9D 9E 9F A0
>>  vcan0  123  [8]  [CF] sn: 7    data: A1 A2 A3 A4 A5 A6 A7
>>  vcan0  123  [8]  [CF] sn: 8    data: A8 A9 AA AB AC AD AE
>>  vcan0  123  [8]  [CF] sn: 9    data: AF B0 B1 B2 B3 B4 B5
>>  vcan0  123  [8]  [CF] sn: A    data: B6 B7 B8 B9 BA BB BC
>>  vcan0  123  [8]  [CF] sn: B    data: BD BE BF C0 C1 C2 C3
>>  vcan0  123  [8]  [CF] sn: C    data: C4 C5 C6 C7 C8 C9 CA
>>  vcan0  123  [8]  [CF] sn: D    data: CB CC CD CE CF D0 D1
>>  vcan0  123  [8]  [CF] sn: E    data: D2 D3 D4 D5 D6 D7 D8
>>  vcan0  123  [8]  [CF] sn: F    data: D9 DA DB DC DD DE DF
>>  vcan0  123  [8]  [CF] sn: 0    data: E0 E1 E2 E3 E4 E5 E6
>>  vcan0  123  [8]  [CF] sn: 1    data: E7 E8 E9 EA EB EC ED
>>  vcan0  123  [8]  [CF] sn: 2    data: EE EF F0 F1 F2 F3 F4
>>  vcan0  123  [8]  [CF] sn: 3    data: F5 F6 F7 F8 F9 FA FB
>>  vcan0  123  [5]  [CF] sn: 4    data: FC FD FE FF
>>
>> Please check out the README.isotp:
>>
>> https://gitorious.org/linux-can/can-modules/source/f306f8ef6154d5625f261374917ec6226910fbbb:README.isotp
>>
>> Did you probably run your test on a real CAN interface but did not increase
>> the tx queue length of the CAN netdevice accordingly??
>>
>>> I will search for this problem as it is a big problem if we want to make
>>> some download through isotp.
>>
>> I flashed several instrument clusters and climate control ECUs with this
>> implementation :-)
>>
>> Regards,
>> Oliver
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Maxime Jayat

Re: linux-can ISOTP module

[Oliver Hartkopp]

Hello Maxime and Laurent,

On 05.06.2014 12:18, Maxime Jayat wrote:

>> Ok, with isotp.h api, i understand that we can parameter block size, stmin,
>> wftmax, transmission time (n_ax), padding.
>> But how can i specify the timing n_CS (time between flow control reception
>> and first consecutive frame) and the timing n_BS (time between first frame
>> reception and flow control emission)? In the same way, is it possible to
>> specify according timeout (n_BR for flow control timeout reception, and n_CR
>> for consecutive frame timeout reception)?

Hm - didn't know that n_CS is important at all ...
I'll take a look, if this can be integrated easily.

>>>>
>>>> For extended adressing method, it seems that both rx and tx frame must have
>>>> the same first byte in can frame (the one set by ext_address field of the
>>>> structure). This is correct for mixed addressing method (see Iso15765-2),
>>>> but for extended adressing method, we should be able to specify different
>>>> Target and source adress. I have not seen anything like this.
>>>
>>> One socket represents one virtual 1:1 connection (defined by two CAN
>>> identifiers and optional with one address extension) on the CAN bus.
>>>
>>> If you want to receive from different sources just create different sockets
>>> (and e.g. use select() to listen to many open socket file descriptors).
>>>
>>> The protocol engine has always to answer with the correct address information.
>>>
>> With this method, 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), but i don't see how it can work using two socket.
> I confirm.
> This is a problem that we also encountered on a BMW ECU with the current
> implementation of ISOTP.
> The use-case is real and not currently supported.

Ooops!

I've never read anything about an address extension used this way.
Despite the fact that this is used at FIAT and BMW - can this be found
somewhere in the protocol specification??

> I had to hack isotp.c, adding a socket option to be able to choose an
> address extension for the reception. Probably not the best solution but
> it worked.

I wonder if it would work to just add an rx address extension u8 element to
struct can_isotp_options:

struct can_isotp_options {

        __u32 flags;            /* set flags for isotp behaviour.       */
                                /* __u32 value : flags see below        */

        __u32 frame_txtime;     /* frame transmission time (N_As/N_Ar)  */
                                /* __u32 value : time in nano secs      */

        __u8  ext_address;      /* set address for extended addressing  */
                                /* __u8 value : extended address        */

        __u8  txpad_content;    /* set content of padding byte (tx)     */
                                /* __u8 value : content on tx path      */

        __u8  rxpad_content;    /* set content of padding byte (rx)     */
                                /* __u8 value : content on rx path      */

        __u8  rx_ext_address;   /* set address for extended addressing  */
                                /* __u8 value : extended address        */

};

/* flags for isotp behaviour */

#define CAN_ISOTP_LISTEN_MODE   0x001   /* listen only (do not send FC) */
#define CAN_ISOTP_EXTEND_ADDR   0x002   /* enable extended addressing */
#define CAN_ISOTP_TX_PADDING    0x004   /* enable CAN frame padding tx path */
#define CAN_ISOTP_RX_PADDING    0x008   /* enable CAN frame padding rx path */
#define CAN_ISOTP_CHK_PAD_LEN   0x010   /* check received CAN frame padding */
#define CAN_ISOTP_CHK_PAD_DATA  0x020   /* check received CAN frame padding */
#define CAN_ISOTP_HALF_DUPLEX   0x040   /* half duplex error state handling */
#define CAN_ISOTP_FORCE_TXSTMIN 0x080   /* ignore stmin from received FC */
#define CAN_ISOTP_FORCE_RXSTMIN 0x100   /* ignore CFs depending on rx stmin */
#define CAN_ISOTP_RX_EXT_ADDR   0x200   /* different rx extended addressing */


pahole can-isotp.ko says:

struct can_isotp_options {
        __u32                      flags;                /*     0     4 */
        __u32                      frame_txtime;         /*     4     4 */
        __u8                       ext_address;          /*     8     1 */
        __u8                       txpad_content;        /*     9     1 */
        __u8                       rxpad_content;        /*    10     1 */

        /* size: 12, cachelines: 1, members: 5 */
        /* padding: 1 */
        /* last cacheline: 12 bytes */
};

So this could be a working extension ...

Regards,
Oliver

Re: linux-can ISOTP module

[laurent vaudoit]

Hello,

On Thu, Jun 5, 2014 at 8:22 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hello Maxime and Laurent,
>
> On 05.06.2014 12:18, Maxime Jayat wrote:
>
>>> Ok, with isotp.h api, i understand that we can parameter block size, stmin,
>>> wftmax, transmission time (n_ax), padding.
>>> But how can i specify the timing n_CS (time between flow control reception
>>> and first consecutive frame) and the timing n_BS (time between first frame
>>> reception and flow control emission)? In the same way, is it possible to
>>> specify according timeout (n_BR for flow control timeout reception, and n_CR
>>> for consecutive frame timeout reception)?
>
> Hm - didn't know that n_CS is important at all ...
> I'll take a look, if this can be integrated easily.
>
Most of the time, this timings are not critical, but when you want to
mke some diagnostic on a large panel of ECU, there is allways one who
has some particularity. I had some problem with some ECUs who didn't
send consecutive frame because i was sending the flow control too
fast. In this case, n_BS has to be parametrable.

>>>>>
>>>>> For extended adressing method, it seems that both rx and tx frame must have
>>>>> the same first byte in can frame (the one set by ext_address field of the
>>>>> structure). This is correct for mixed addressing method (see Iso15765-2),
>>>>> but for extended adressing method, we should be able to specify different
>>>>> Target and source adress. I have not seen anything like this.
>>>>
>>>> One socket represents one virtual 1:1 connection (defined by two CAN
>>>> identifiers and optional with one address extension) on the CAN bus.
>>>>
>>>> If you want to receive from different sources just create different sockets
>>>> (and e.g. use select() to listen to many open socket file descriptors).
>>>>
>>>> The protocol engine has always to answer with the correct address information.
>>>>
>>> With this method, 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), but i don't see how it can work using two socket.
>> I confirm.
>> This is a problem that we also encountered on a BMW ECU with the current
>> implementation of ISOTP.
>> The use-case is real and not currently supported.
>
> Ooops!
>
> I've never read anything about an address extension used this way.
> Despite the fact that this is used at FIAT and BMW - can this be found
> somewhere in the protocol specification??
>
>> I had to hack isotp.c, adding a socket option to be able to choose an
>> address extension for the reception. Probably not the best solution but
>> it worked.
>
> I wonder if it would work to just add an rx address extension u8 element to
> struct can_isotp_options:
>
> struct can_isotp_options {
>
>         __u32 flags;            /* set flags for isotp behaviour.       */
>                                 /* __u32 value : flags see below        */
>
>         __u32 frame_txtime;     /* frame transmission time (N_As/N_Ar)  */
>                                 /* __u32 value : time in nano secs      */
>
>         __u8  ext_address;      /* set address for extended addressing  */
>                                 /* __u8 value : extended address        */
>
>         __u8  txpad_content;    /* set content of padding byte (tx)     */
>                                 /* __u8 value : content on tx path      */
>
>         __u8  rxpad_content;    /* set content of padding byte (rx)     */
>                                 /* __u8 value : content on rx path      */
>
>         __u8  rx_ext_address;   /* set address for extended addressing  */
>                                 /* __u8 value : extended address        */
>
> };
>
> /* flags for isotp behaviour */
>
> #define CAN_ISOTP_LISTEN_MODE   0x001   /* listen only (do not send FC) */
> #define CAN_ISOTP_EXTEND_ADDR   0x002   /* enable extended addressing */
> #define CAN_ISOTP_TX_PADDING    0x004   /* enable CAN frame padding tx path */
> #define CAN_ISOTP_RX_PADDING    0x008   /* enable CAN frame padding rx path */
> #define CAN_ISOTP_CHK_PAD_LEN   0x010   /* check received CAN frame padding */
> #define CAN_ISOTP_CHK_PAD_DATA  0x020   /* check received CAN frame padding */
> #define CAN_ISOTP_HALF_DUPLEX   0x040   /* half duplex error state handling */
> #define CAN_ISOTP_FORCE_TXSTMIN 0x080   /* ignore stmin from received FC */
> #define CAN_ISOTP_FORCE_RXSTMIN 0x100   /* ignore CFs depending on rx stmin */
> #define CAN_ISOTP_RX_EXT_ADDR   0x200   /* different rx extended addressing */
>
>
> pahole can-isotp.ko says:
>
> struct can_isotp_options {
>         __u32                      flags;                /*     0     4 */
>         __u32                      frame_txtime;         /*     4     4 */
>         __u8                       ext_address;          /*     8     1 */
>         __u8                       txpad_content;        /*     9     1 */
>         __u8                       rxpad_content;        /*    10     1 */
>
>         /* size: 12, cachelines: 1, members: 5 */
>         /* padding: 1 */
>         /* last cacheline: 12 bytes */
> };
>
> So this could be a working extension ...

In my opinion, it would be better to have all normalization parameters
in the structure:
__u8 Adressing_method
__u8 TA
__u8 SA
__u8 AE

Because depending on the Adressing method used, you have to use TA
(target adress) and SA (Source Adress) for first byte of the frame (TA
in emission, SA in reception) or AE (adress extension) for both
emission and reception (case of mixed adressing, see ISO15765-2
normalization)
But i don't know if it is available, due to compatibility.

Maybe i will have to work on this topic in the following weeks
(depending on some higher enterprise decision), so if i have some
patch i will send you.

>
> Regards,
> Oliver
>
>
Regards
Laurent

Re: linux-can ISOTP module

[Oliver Hartkopp]

Hello Laurent,

On 06.06.2014 08:42, laurent vaudoit wrote:

>>>> With this method, 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), but i don't see how it can work using two socket.
>>> I confirm.
>>> This is a problem that we also encountered on a BMW ECU with the current
>>> implementation of ISOTP.
>>> The use-case is real and not currently supported.

I added the funtionality of a different rx_ext_addr to a specific branch of
can-utils and can-modules:

https://gitorious.org/linux-can/can-utils/commits/rx_ext_addr
https://gitorious.org/linux-can/can-modules/commits/rx_ext_addr

Please check them out for a test. As all the isotp tools (in the branch)
support the new feature too, it should be easy to do.

> In my opinion, it would be better to have all normalization parameters
> in the structure:
> __u8 Adressing_method
> __u8 TA
> __u8 SA
> __u8 AE
> 
> Because depending on the Adressing method used, you have to use TA
> (target adress) and SA (Source Adress) for first byte of the frame (TA
> in emission, SA in reception) or AE (adress extension) for both
> emission and reception (case of mixed adressing, see ISO15765-2
> normalization)
> But i don't know if it is available, due to compatibility.

I wonder whether this should be part of a syscall interface API.
The ISO15765-2 protocol is a CAN transport protocol which creates a virtual
point-to-point data connection with help of two CAN identifiers.
There are many use-cases for transport protocols besides diagnosis.

The fact that the ISO15765-2 appendix defines an assignment of logical
addresses to CAN identifiers does not mean that a socket API needs to provide
this assignment pattern. This can be done by some library too.

Regards,
Oliver

Re: linux-can ISOTP module

[laurent vaudoit]

Hello Oliver,

On Fri, Jun 20, 2014 at 9:08 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hello Laurent,
>
> On 06.06.2014 08:42, laurent vaudoit wrote:
>
>>>>> With this method, 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), but i don't see how it can work using two socket.
>>>> I confirm.
>>>> This is a problem that we also encountered on a BMW ECU with the current
>>>> implementation of ISOTP.
>>>> The use-case is real and not currently supported.
>
> I added the funtionality of a different rx_ext_addr to a specific branch of
> can-utils and can-modules:
>
> https://gitorious.org/linux-can/can-utils/commits/rx_ext_addr
> https://gitorious.org/linux-can/can-modules/commits/rx_ext_addr
>
> Please check them out for a test. As all the isotp tools (in the branch)
> support the new feature too, it should be easy to do.

i did not have time for test but regarding the source code, it should be ok.
>
>> In my opinion, it would be better to have all normalization parameters
>> in the structure:
>> __u8 Adressing_method
>> __u8 TA
>> __u8 SA
>> __u8 AE
>>
>> Because depending on the Adressing method used, you have to use TA
>> (target adress) and SA (Source Adress) for first byte of the frame (TA
>> in emission, SA in reception) or AE (adress extension) for both
>> emission and reception (case of mixed adressing, see ISO15765-2
>> normalization)
>> But i don't know if it is available, due to compatibility.
>
> I wonder whether this should be part of a syscall interface API.
> The ISO15765-2 protocol is a CAN transport protocol which creates a virtual
> point-to-point data connection with help of two CAN identifiers.
> There are many use-cases for transport protocols besides diagnosis.
>
> The fact that the ISO15765-2 appendix defines an assignment of logical
> addresses to CAN identifiers does not mean that a socket API needs to provide
> this assignment pattern. This can be done by some library too.
>
You're rigth, it can be done in a specific library instead of in kernel.
It is like this we do in our firmware, i has just forget it...

> Regards,
> Oliver

as soon as i can test i do it.
Regards
Laurent
>

Re: linux-can ISOTP module

[Oliver Hartkopp]

Hello Laurent,

On 23.06.2014 20:01, laurent vaudoit wrote:
> On Fri, Jun 20, 2014 at 9:08 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>> On 06.06.2014 08:42, laurent vaudoit wrote:
>>
>>>>>> With this method, 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), but i don't see how it can work using two socket.
>>>>> I confirm.
>>>>> This is a problem that we also encountered on a BMW ECU with the current
>>>>> implementation of ISOTP.
>>>>> The use-case is real and not currently supported.
>>
>> I added the funtionality of a different rx_ext_addr to a specific branch of
>> can-utils and can-modules:
>>
>> https://gitorious.org/linux-can/can-utils/commits/rx_ext_addr
>> https://gitorious.org/linux-can/can-modules/commits/rx_ext_addr
>>
>> Please check them out for a test. As all the isotp tools (in the branch)
>> support the new feature too, it should be easy to do.
> 
> i did not have time for test but regarding the source code, it should be ok.

Did you find some time to check this change?

I would like to move this patch into the master branch before continuing the
development.

Regards,
Oliver

Re: linux-can ISOTP module

[Oliver Hartkopp]

On 15.01.2015 09:45, laurent vaudoit wrote:

> On Thu, Nov 13, 2014 at 6:47 PM, Oliver Hartkopp <socketcan@hartkopp.net


>     >> I added the funtionality of a different rx_ext_addr to a specific branch of
>     >> can-utils and can-modules:
>     >>
>     >>https://gitorious.org/linux-can/can-utils/commits/rx_ext_addr
>     >>https://gitorious.org/linux-can/can-modules/commits/rx_ext_addr
>     >>
>     >> Please check them out for a test. As all the isotp tools (in the branch)
>     >> support the new feature too, it should be easy to do.
>     >
>     > i did not have time for test but regarding the source code, it should be ok.

(..)
>
> it works well.
> I've made some tests sending single frame and segmented frame
> and receiving some single frame, with different extended adressing mode.
>
> We are now able to deal with all the addressing method of the Iso15765-2.

Great! Many thanks for testing!

> Branch can be merge (by the way it seems kernel evolution is allready merged
> into master).

Yes, I had some other stuff to add for a complete ISO15765-2:2015 support, 
e.g. the 32 bit FF_DL and the checks for optimized frame length.

So I needed to extend the API step by step and the rx_ext_addr was already 
defined - therefore it was hard to continue with integrating new features.

But it's good to know that it fits your needs and the isotp got 'even better' 
for all use cases in the wild :-)

Best regards,
Oliver

N_Cs timing - was Re: linux-can ISOTP module

[Oliver Hartkopp]

Hi Laurent,

as the extended address specification for the rx path is discussed/answered
in another thread I changed the subject for the timing discussion ...

On 05.06.2014 09:16, laurent vaudoit wrote:

> 
> Ok, with isotp.h api, i understand that we can parameter block size, stmin,
> wftmax, transmission time (n_ax), padding.
> But how can i specify the timing n_CS (time between flow control reception
> and first consecutive frame)

N_Cs is defined by the received STmin.

Then the tx_gap time is calculated by tx_gap = N_As + N_Cs

https://gitorious.org/linux-can/can-modules/source/027899c01aa2482423376e1e9f2a5875c316303a:net/can/isotp.c#L324

Finally the timer for the tx job is started relatively with this value
which leads to the required gap between the FC reception and the first CF. 


> and the timing n_BS (time between first frame
> reception and flow control emission)? 

N_Bs = N_Br + N_Ar

N_Ar is defined by the frame transmission time (on the real CAN bus)
N_Br has no setting but only a performance requirement:

N_Br + N_Ar < 0.9 * N_Bs timeout

N_Bs timeout = 1000ms => N_Br + N_Ar < 900ms

So AFAICS there's no way to specify N_Br. It can be as small as possible.
Therefore N_Bs is at least N_Ar + some various time for the protocol machine. 

> In the same way, is it possible to
> specify according timeout (n_BR for flow control timeout reception, and n_CR
> for consecutive frame timeout reception)?

Due to the spec all these timeouts are defined to be 1000ms.
Or did I miss something here?

Regards,
Oliver

Re: N_Cs timing - was Re: linux-can ISOTP module

[laurent vaudoit]

Hi Oliver,

On Sat, Jun 21, 2014 at 1:18 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hi Laurent,
>
> as the extended address specification for the rx path is discussed/answered
> in another thread I changed the subject for the timing discussion ...

ok no problem, it will be more clear.
>
> On 05.06.2014 09:16, laurent vaudoit wrote:
>
>>
>> Ok, with isotp.h api, i understand that we can parameter block size, stmin,
>> wftmax, transmission time (n_ax), padding.
>> But how can i specify the timing n_CS (time between flow control reception
>> and first consecutive frame)
>
> N_Cs is defined by the received STmin.
>
> Then the tx_gap time is calculated by tx_gap = N_As + N_Cs
>
> https://gitorious.org/linux-can/can-modules/source/027899c01aa2482423376e1e9f2a5875c316303a:net/can/isotp.c#L324
>
> Finally the timer for the tx job is started relatively with this value
> which leads to the required gap between the FC reception and the first CF.
>
Yes i saw this in the code.
In my opinion, it should be two different timing, N_CS for emission of
the first Consecutive frame and then stmin given by ECU from flow
control.
After, this implementation will work in most of the case, but it is a
little  different from iso15765-2.


>> and the timing n_BS (time between first frame
>> reception and flow control emission)?
>
> N_Bs = N_Br + N_Ar
>
> N_Ar is defined by the frame transmission time (on the real CAN bus)
> N_Br has no setting but only a performance requirement:
>
> N_Br + N_Ar < 0.9 * N_Bs timeout
>
> N_Bs timeout = 1000ms => N_Br + N_Ar < 900ms
>
> So AFAICS there's no way to specify N_Br. It can be as small as possible.
> Therefore N_Bs is at least N_Ar + some various time for the protocol machine.

Hum, this can be a blocking fact for some ECU diagnostic.
I had this implementation (sending flow control as quick as possible),
and some ECUs (seen on PSA car) did not answer to the request, because
i had not 25ms before flow control sending.
>
>> In the same way, is it possible to
>> specify according timeout (n_BR for flow control timeout reception, and n_CR
>> for consecutive frame timeout reception)?
>
> Due to the spec these timeouts are defined to be 1000ms.
> Or did I miss something here?
>
Coming from diagnostic, i prefer to be able to configure all protocol
timing (in order to deal with the maximum ECU number (even very old
ecu, which may be very slow). Constructor gives us the timing we must
respect, sometimes different from the normalization....
but 1000ms is enough i think for most of the case.
> Regards,
> Oliver
>
regards
Laurent