Consider a probing technique for query_available_pids.

[tobz]

Right now, we hardcode our socket to send a request to the functional diagnostic address while listening to the physical response address for the ECU. For something like extended addressing, this means we're expecting a response to be sent to 18DAF101, following that that last octet is variable and should map to ECU #xx i.e. ECU #0 would be 00, ECU #1 would be 01, and so on.

However, testing on a new Acura TLX, we see identifiers that come back beyond the expected range of 01-08, starting with 10 for the ECU and also including 1E and 1F. This is outside of the recommended range as described in ISO 15765-4, as there is a limit of 8 ECUs and they should start at 0, thus the expected range of 01-08.

Thus, all of that said, we likely want to explore an approach where we send on the functional address and try to receive on any of the possible physical addresses to figure out what's available, and then switch to the physical addressing for both send/receive from that point on. I don't think we can actually do this directly with socketcan_isotp as it wants the specific send/receive IDs upfront, with no option for masking... but we could theoretically do it with socketcan directly as it has support for this.