DISCUSSION FROM GITHUB: ==>harryzz commented 7 hours 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 5 hours 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 4 hours 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)? ==>hartkopp commented 2 hours 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 an hour 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 an hour ago how would you think this could look like from a programmers perspective? 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)
