>From programmers 'using' perspective i think must be exactly like UDP, with appropriate MASK can get responses from all available ECU. >From implementation perspective things are more complex. On Sat, Sep 8, 2018 at 5:40 PM Zahari Zahariev <harryzz@xxxxxxxxx> wrote: > > 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)
