Hi Oliver, thanks for the welcome... I got curious as you mentioned the mailing list it on GitHub. On Wed, Dec 02, 2020 2:32 PM, Oliver Hartkopp wrote: > Hi Thomas, > > thanks for showing up here on the Linux-CAN mailing list! > > On 02.12.20 13:28, Thomas Wagner wrote: > > > as already discussed with Oliver Hartkopp via Github (https://github.com/hartkopp/can-isotp/issues/36), I suggest a new > > option/flag to enable ISO-TP sockets with just a TX address, while the RX address is being ignored/discarded. This can be useful for > > OBD2/UDS usage, where functional requests are used and sent in a 1-to-N scenario, while still having an ISO-TP style PCI. > > > > Oliver: > > > It would be something like a new flag, e.g. CAN_ISOTP_FADDR_TX_ONLY where only the tp.tx_id is used at bind() time (no > > > registering of a tp.rx_id) and where you only can send PDUs that are max 7 bytes => SF. > > Yes. I would be fine with it. > > Btw. I would like to ask about the naming of the flag. > > CAN_ISOTP_FADDR_TX_ONLY > CAN_ISOTP_FUNCADDR_TX > CAN_ISOTP_FUNC_ADDR > CAN_ISOTP_FUNC_ADDR_TX > (?? other ideas ??) I guess broadcast CAN_ISOTP_BROADCAST would be a more generic description, implying the 1-to-N nature where listeners might establish a 1-to-1 connection as needed. But considering the flag would probably mainly be used with OBD/UDS functional addressing CAN_ISOTP_FUNC_ADDR doesn't seem half bad IMO. > > In depth Use-Case explanation: > > With OBD2 and UDS requests on CAN, ISO-TP is used as a transport protocol. Requests can be physically addressed by a tester to a > > specific ECU using the CAN-IDs 0x7E0 to 0x7E7 (11-bit IDs). > > The ECUs respond to the tester using the CAN-IDs 0x7E8 to 0x7EF. A tester can open 8 ISO-TP sockets, using the specific RX and TX > > addresses, to communicate with each ECU. > > In some cases requests aren't sent physically addressed to a specific ECU, but broadcasted/functionally addressed to all ECUs who > > might care/can respond. This is done using the special CAN-ID 0x7DF. > > Any ECU that might respond does so, using it's to-tester address (0x7E8 to 0x7EF). This way a 1-to-N broadcast/request can be done, > > after which multiple 1-to-1 connections can be established to transfer large PDUs. > > Btw. If you already have established the 8 1-to-1 sockets as described > above the ECU can also send PDUs with length >7 bytes as your socket > would do the protocol handshake. Yes, that's the way I have been working most of the time. Even when sending functional requests to all ECUs, they will respond to those 8 1-to-1 sockets and hence I am able to receive responses that are quiet long. E.g. I can send a single functional request to make all available ECUs identify with an ID, which is normally longer than 7 byte. > > In the current ISO-TP/SocketCAN implementation, an additional 9th socket needs to be used for those functional requests. Using an > > ISO-TP socket as 9th socket forces the user to choose an RX address that is never actually used. Using a RAW CAN socket forces the > > user to calculate/build a PCI manually and have the socket discard/filter all RX traffic. > > You can simply remove the single default CAN_RAW filter which receives > all CAN-IDs: > > (see in cansend.c code) > > setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0); Perfect! > > AFAIK functional requests are always <7B data, so ISO-TP would be fine without a RX address for flow control on the 7DF request > > socket. > > Now I seed what you meant with "<7B" .. "<7 bytes" > :-D If I ever come up with a kernel patch, I promise I will try to choose clearer abbreviations :D > > Any feedback/thoughts on that? :) > > I'm currently working on the sja1000 arbitration lost topic but I can > send a RFC patch for this suggestion afterwards. > > Are you currently working on a Linux 5.10-rc kernel with ISO-TP included > in the tree - or would you like the testing based on my GitHub isotp repo? I would much prefer to work of the GitHub repo if possible, as I don't have a setup for newer kernels with CAN hardware. Best regards Thomas
