Hi all, 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. 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. 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. 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. Any feedback/thoughts on that? :) Mit freundlichen Grüßen Best Regards Thomas Wagner
