hartkopp / can-isotp

Linux Kernel Module for ISO 15765-2:2016 CAN transport protocol PLEASE NOTE: This module is part of the mainline Linux kernel since version 5.10
Other
240 stars 69 forks source link

missing real examples #10

Closed harryzz closed 6 years ago

harryzz commented 6 years ago

hello because is to hard to find real examples and options is to complicated here is real example from beaglebone black - Linux beaglebone 4.14.49-ti-r54 - with BMW car connected to diagnostic bus talking to ecu 0x40 (CAS) with tester address 0xF1:

echo "22 31 01" | isotpsend -s 6F1 -d 640 -x 640 can1

isotprecv -s 6F1 -d 640 -x 640:6F1 -l can1 62 31 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 30 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 04 50 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 04 50 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

isotpdump -s 6F1 -d 640 -x 640 can1 can1 6F1{40} [5] [SF] ln: 3 data: 22 31 01 can1 640{F1} [8] [FF] ln: 234 data: 62 31 01 08 00 can1 6F1{40} [4] [FC] FC: 0 = CTS # BS: 0 = off # STmin: 0x00 = 0 ms can1 640{F1} [8] [CF] sn: 1 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 2 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 3 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 4 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 5 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 6 data: 00 08 00 00 00 00 can1 640{F1} [8] [CF] sn: 7 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 8 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 9 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: A data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: B data: 00 00 00 00 08 00 can1 640{F1} [8] [CF] sn: C data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: D data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: E data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: F data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 0 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 1 data: 00 03 30 18 00 00 can1 640{F1} [8] [CF] sn: 2 data: 00 50 50 00 00 00 can1 640{F1} [8] [CF] sn: 3 data: E7 70 00 00 20 00 can1 640{F1} [8] [CF] sn: 4 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 5 data: 14 A0 13 A0 00 00 can1 640{F1} [8] [CF] sn: 6 data: 00 00 00 00 04 50 can1 640{F1} [8] [CF] sn: 7 data: 18 00 00 00 50 50 can1 640{F1} [8] [CF] sn: 8 data: 00 00 00 E7 70 00 can1 640{F1} [8] [CF] sn: 9 data: 00 20 00 00 00 00 can1 640{F1} [8] [CF] sn: A data: 00 00 00 14 A0 13 can1 640{F1} [8] [CF] sn: B data: A0 00 00 00 00 00 can1 640{F1} [8] [CF] sn: C data: 00 04 50 18 00 00 can1 640{F1} [8] [CF] sn: D data: 00 50 50 00 00 00 can1 640{F1} [8] [CF] sn: E data: E7 70 00 00 20 00 can1 640{F1} [8] [CF] sn: F data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 0 data: 14 A0 13 A0 00 00 can1 640{F1} [8] [CF] sn: 1 data: 00 00 00 00 08 00 can1 640{F1} [8] [CF] sn: 2 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 3 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 4 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 5 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 6 data: 00 00 00 00 00 00 can1 640{F1} [8] [CF] sn: 7 data: 00 FF FF FF FF FF

isotpsniffer -s 640 -d 6F1 -x 6F1 -X 640 -f 1 can1 can1 6F1 [3] 22 31 01 can1 640 [234] 62 31 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 30 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 04 50 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 04 50 18 00 00 00 50 50 00 00 00 E7 70 00 00 20 00 00 00 00 00 00 00 14 A0 13 A0 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

to work isotpsniffer and isotpdump - isotprecv must be running to send FC frames.

hartkopp commented 6 years ago

These command line tools are just for testing. To make a proper diagnosis communication you should open an isotp socket from C code and write/read from that socket (as long as it is opended). isotpsend and isotprecv open two separate sockets - this is not a good approach to talk to ECUs.

harryzz commented 6 years ago

Ok. thanks. And what about BROADCAST messages. Is possible to handle and what is right way?

like this with broadcast address 0xDF:

can1 6F1 [5] DF 03 22 F1 01

can1 610 [8] F1 10 34 62 F1 01 01 01 can1 6F1 [8] 10 30 0F 02 00 00 00 00 can1 610 [8] F1 21 00 04 11 01 11 8B can1 610 [8] F1 22 00 09 00 00 00 00 can1 610 [8] F1 23 00 00 00 06 00 00 can1 610 [8] F1 24 04 52 02 0B 1E 08 can1 610 [8] F1 25 00 00 04 53 02 0B can1 610 [8] F1 26 3C 08 00 00 04 54 can1 610 [8] F1 27 02 05 04 01 00 00 can1 610 [8] F1 28 01 B4 00 C4 00 FF

can1 640 [8] F1 10 54 62 F1 01 01 01 can1 6F1 [8] 40 30 0F 02 00 00 00 00 can1 640 [8] F1 21 00 08 12 07 10 8A can1 640 [8] F1 22 8F 71 01 00 00 01 can1 640 [8] F1 23 23 00 00 01 00 00 can1 640 [8] F1 24 00 07 05 00 02 02 can1 640 [8] F1 25 00 00 02 EB FF FF can1 640 [8] F1 26 FF 06 00 00 07 4B can1 640 [8] F1 27 06 00 08 08 00 00 can1 640 [8] F1 28 07 4F 06 06 14 08 can1 640 [8] F1 29 00 00 07 4D 06 06 can1 640 [8] F1 2A 14 08 00 00 07 4E can1 640 [8] F1 2B 06 06 14 08 00 00 can1 640 [8] F1 2C 07 4C 06 06 14 05 can1 640 [8] F1 2D 00 00 00 0F 05 13 can1 640 [8] F1 2E 05 FF FF FF FF FF

can1 672 [8] F1 10 4C 62 F1 01 01 01 can1 6F1 [8] 72 30 0F 02 00 00 00 00 can1 672 [8] F1 21 00 07 13 02 07 8B can1 672 [8] F1 22 00 24 00 00 00 00 can1 672 [8] F1 23 00 00 00 01 00 00 can1 672 [8] F1 24 0D 10 01 00 01 06 can1 672 [8] F1 25 00 00 05 15 0D 03 can1 672 [8] F1 26 00 08 00 00 05 13 can1 672 [8] F1 27 0D 03 23 08 00 00 can1 672 [8] F1 28 05 14 0D 03 23 08 can1 672 [8] F1 29 00 00 05 12 0D 03 can1 672 [8] F1 2A 23 08 00 00 05 11 can1 672 [8] F1 2B 0D 03 28 05 00 00 can1 672 [8] F1 2C 01 2F 0C 06 16 FF

hartkopp commented 6 years ago

The point is, that broadcast messages fit into one CAN frame - which does not need a "transport protocol". So the idea is to perform broadcast PDUs with a CAN_RAW socket - and whenever you need a segmented PDU transfer you use the CAN_ISOTP socket. E.g. you may open an isotp socket which is listening on a specific connection (two CAN IDs) but trigger some function with a CAN_RAW socket via broadcast.

harryzz commented 6 years ago

Ok. If i understand you correctly: for my case i need to open up to 240 sockets to handle response from broadcast and find available ECU (i don't know how many ECU have installed)?

On Sat, Sep 8, 2018 at 12:52 PM Oliver Hartkopp notifications@github.com wrote:

The point is, that broadcast messages fit into one CAN frame - which does not need a "transport protocol". So the idea is to perform broadcast PDUs with a CAN_RAW socket - and whenever you need a segmented PDU transfer you use the CAN_ISOTP socket. E.g. you may open an isotp socket which is listening on a specific connection (two CAN IDs) but trigger some function with a CAN_RAW socket via broadcast.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hartkopp/can-isotp/issues/10#issuecomment-419628158, or mute the thread https://github.com/notifications/unsubscribe-auth/AEie6LrRGPbnsvzZksg9f6tbd5MLn1LJks5uY5NSgaJpZM4WcdCp .

hartkopp commented 6 years ago

Formally yes. The problem is, that you would have to deal with all that possible back channels (and its communication channel CAN ID pairs) anyway, right? How would you do that with another approach? In any case you would formally need to create 240 state machines that could react on answers of a broadcast request - or am I missing anything here? ps. Thanks for the discussion. Most people just fork and use the isotp module without giving feedback. And I would like to push it into mainline Linux, so feedback is really appreciated.

harryzz commented 6 years ago

I don't need to have all the time opened all 240 sockets. I send broadcast and then collect available ecu's and returned data and close all connections. After this diagnostic is in normal way peer-to-peer. I know i can make this also with can_raw and assemble data in user-space .... what you think about implementation of 'listen' and 'accept' functionality - this will fix issue and will be more flexible?

hartkopp commented 6 years ago
  1. how would you think this could look like from a programmers perspective?
  2. Can we continue this discussion on the linux-can mailing list please? Github is not the best place for these kind of discussions as the CAN community is more active on the mailing list (and it is archived there too)
harryzz commented 6 years ago

okey. is this the right place: https://www.spinics.net/lists/linux-can/ ?

hartkopp commented 6 years ago

Yes it is - already seen your posting. Tnx! Would you like to answer my question 1 there? Closing this issue here for now.