Gateway Configuration

[dmholtz]

First of all, thank you very much for great work. I've been successfully using doipclient for a while in combination with udsoncan. Until now, my tests were limited to sending and receiving UDS request to / from the primary gateway ECU of the vehicle and other ECUs that are connected to the gateway via CAN.

However, I was not able to communicate with other gateway ECUs or ECUs that or connected to these gateways. More precisely, the primary gateway always responds with NACK 0x03 (Invalid Target Address).

Since I could not find any hints in the docs about how to properly configure gateways, I wonder if there are any additional configuration steps necessary to make that routing possible.

[jacobschaer]

I don't remember there being any magic configuration, there's only three parameters really - target IP and target and tester logical addresses. I would expect you just provide the edge node/gateway's IP and the target ECU's logical address. 0x3 seems like it's just not a supported gateway. The address could be real but the gateway doesn't expose it.

I suppose it's possible that an ECU could be serving as an IP router, but the configuration needed to work with that would be in your operating systems' network settings, not the doip client. It's also possible there's some OEM specific requirements, I vaguely recall someone asking about custom activations for a similar use case in another ticket. Or, maybe I missed something!

If you figure something out, perhaps make a PR to add your findings to the documents?

[dmholtz]

Thank you very much for the response. Having also contacted the vehicle supplier, I found that I was using the wrong IP address. Indeed, there should not be any further settings than those stated by your comment. If I find time, I'll create a brief explanation for the documentation about such a scenario and draft a PR.

However, I observed that for some ECUs, the method request_entity_status terminates with NACK 0x01 even though UDS communication using a DoIPConnection works perfectly fine. Until now it is too early to state whether this is issue is caused by the car or the client but I will keep you up to date.

[Power-6]

Hi! Just wanted to drop a note on gateways with the DoIP client. I have been working with this module and built a software for Volvo diag using this module and UDSonCAN module. There is a fundamental issue with both of these when working with a car that has a gateway. I do not mean to minimize the effort and work put into these modules! Time and technology moves on and the introduction of gateways changes the premise of a "connection" which simply was not a problem I when these modules were created.

DoIPClient and UDSonCAN both operate on a single client ECU at a time, defined by both IP address and the ECU address. In many cases this is not an issue, you can talk to one ECU, close the client, then open a new client to talk to another ECU. The IP address of the gateway is always used, the ECU address changes. The issues I had in building a tool to work with a car using a DoIP gatweay, relate to safety and security features. Keep in mind UDS is a loose standard and I am new at both programming and automotive diagnostics. OEM mfrs have plenty of room for proprietary operation. In my case from the very beginning, I discovered enforcement of "Tester Present" messages. We must send these "pings" every few secs, no longer than 5 secs between. If the gateway does not receive a "ping" for longer than 5 secs, it closes the TCP session and goes back o broadcasting the announcement, and we must reconnect. Easy enough to loop that and I moved that idle loop to another thread to keep the connection alive. Now once we want to actually do something in the car, we want to talk to another ECU, we need to kill that idle loop and open a new client, with the destination ECU. We can only have a single socket and single TCP session, the DoIP gateway in my case enforces that. That was the first hurdle to get over, which I solved by using the send_doip command to send the Tester Present pings to the broadcast address while we have a DoIPClient open to a specific ECU.

There was much, much more work to do to deal with more complex tasks. Any security access or session changes from default, these also time out after 5 secs, so need to be kept alive by pings, and also any process needing to be done on multiple ECUs, must be done in the same TCP session, we cannot close and reopen the DoIP client, otherwise the session is lost and the ECUs will time out and go back to default session and locked state. The most difficult case is dealing with the latest models that have a "firewall" on the DoIP connection. It must be disabled to do any flashing or extended diagnostics, and any change of the TCP session will reset and re-enable the diag firewall. I've solved all the issues, but it's workarounds. I've mostly abandoned the UDSonCAN client and working DoIPClient directly. That required building my own security access, session change, and response handling functions. Currently I had to modify the DoIP client in a "quick and dirty" way to add a function to allow specifying an ECU address on the send_diagnostic, so multiple communications can be done inside the same session.

On a car with a gateway, at least what I am working with, any time you close one connection and create another, to change the destination ECU, what is happening is the diag tool is disconnecting, the gateway goes into "announcement" broadcasting, then the new connection is sending a new routing request and connecting like a new diag tool session. The car wasn't built to operate that way. The purpose built OEM tools of course connect with a single TCP session, and all comms are threaded inside that from start to finish.

I did have a conversation with you Jacob some time ago when I was discovering this issue. I know the ultimate solution is to fork the DoIP client and update it to divorce the IP endpoint from the ECU endpoint, so the same client connection can be used to communicate with any ECU through the gateway. I'm a real n00b to programming so I wasn't sure I could take that on, I don't even know what a pull request is ;-). I didn't understand the issues that would need to dealt with until I built my software tool. I am almost there and I may be ready to take on modifying/updating the DoIPClient soon. Even then to use UDSonCAN, that itself would also need to be updated to handle multiple ECUs, which may be possible without modifying it, if the destination ECU passed when creating the client within that module, could be controlled from the DoIPclient. I believe that could work as DoIPClient manages the TCP session.

I don't know that is is directly related to the issue of request_entity_status, but I figured it may be related, and a good place to mention the myriad of general issues when working a gateway. The DoIPClient has still saved me tons of time and allowed me to go far further in buliding a diag/service/flashing tool than a total n00b software dev has any business going ;-)

[ckurtz22]

Thanks for all the info @Power-6, it appears I'm following close in your footsteps :^)
Been working on my own diagnostic logging tool for my Polestar 2 that I might turn into a generic Volvo/Polestar OBD2 adaptor. Since I have a small amount of background coding I might try my hand at a pull request for this very issue.

My idea is to do something similar to what you did already - first modify the send_diagnostic function to allow an arbitrary ECU address to be supplied, and then expand on the DoIPClientUDSConnector class by allowing each connector to be associated to a different ECU address. This way you can create a single DoIPClient for establishing the TCP communications to the gateway, and then create individual connector for each of the ECUs and attach those to their own udsoncan instances.

Please let me know if there is any other advice available that might make my time a bit easier :)