search

openxc / uds-c

Unified Diagnostics Service (UDS) and OBD-II (On Board Diagnostics for Vehicles) C Library
BSD 3-Clause "New" or "Revised" License
685 stars 323 forks source link

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

Open peplin opened 10 years ago

peplin commented 10 years ago

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 commented 10 years ago

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.