Responses to functional broadcast request may be of a much wider range of IDs

[peplin]

I thought it was just 8 possible return values, but it seems that proprietary modules may return from much higher IDs. We might consider accepting any ID if the mode and PID matches.

[peplin]

I'm kind of stumped with this issue. The exact example case saw a response to an 0x7df request coming from ID 0x74e. If we just accept any ID for the response, we have to pass every single received CAN message to the isotp-c receiver. How does that know when it got a request that completed the ISO-TP transfer? Right now uds-c passes messages to the isotp receive handle and waits for it to return completed == true. That returns true if the arbitration ID matches the expected and the payload size was greater than 0. If we pass it every CAN message and match on any arb ID, it's going to say "completed" for any CAN message.

It could be that we have to inspect the CAN messages more closely in uds-c before handing off to the ISO-TP receive handle to see if it is potentially a response to our functional broadcast. This seems messy and unpredictable, though, and I can't believe there isn't a more explicit way to recognize a response.

Since these has to do with proprietary diagnostic messages that I don't have access to, I'm going to leave this is an open issue and not make any code changes right now. I'll leave my drafted changes in an 'wildcard-response' branch.