DoIP troubleshooting
The diagnostic application cannot discover the vehicle, complete routing activation, or establish usable TCP communication with an ECU over DoIP. This guide narrows the failure to the network path, DoIP exchange, ECU availability, or diagnostic configuration.
Start the diagnostic workflowObservable symptoms
The tool sends a discovery request but no vehicle or ECU discovery response appears in the trace. This differs from a later routing failure because the failure occurs before a target can be selected.
A vehicle or ECU is visible, yet the routing activation exchange is rejected, times out, or closes. This distinguishes a reachable DoIP endpoint from an established diagnostic route.
The trace shows repeated TCP connection attempts, connection refusal, or an immediate close after connection. This points to transport or endpoint behavior rather than a UDS service response.
The connection remains open, but a UDS request receives no response or does not produce the expected positive response. This differs from a pure DoIP connection failure because the DoIP path is at least partially operational.
The same diagnostic setup can communicate with other ECUs or in another vehicle state, while one target remains unavailable. This helps separate target ECU availability and configuration from a general Automotive Ethernet path failure.
Possible causes
A disconnected, incorrectly connected, or inactive Automotive Ethernet path prevents discovery traffic from reaching the vehicle or prevents responses from returning to the diagnostic application. The result is typically a complete absence of discovery evidence.
The application may target the wrong vehicle or ECU endpoint, use stale addressing information, or request routing activation with parameters that do not match the available DoIP path. Discovery can therefore succeed while routed communication fails.
The target ECU may not be powered, may not have completed its startup behavior, or may not be available through the current vehicle state. This can produce a silent timeout or a connection that closes before diagnostic communication becomes usable.
A transport connection can be refused, reset, or closed by the endpoint or an intermediate network component. Repeated connection attempts with no completed diagnostic exchange indicate that the failure is below UDS service handling.
An ODX or PDX description may identify the wrong ECU, addressing information, diagnostic session, or expected service behavior. The DoIP connection may be healthy while the subsequent UDS request is directed or interpreted incorrectly.
A CANoe configuration, CAPL automation, or diagnostic application may send requests in the wrong order, use an incorrect target, or fail to preserve the relevant timing and response evidence. The apparent connection failure may therefore be a test or integration defect.
Ordered investigation
Record the exact target ECU, vehicle state, reproduction sequence, expected behavior, and first missing or rejected response. Separate discovery failure, routing activation failure, TCP failure, and post-connection UDS failure before changing the setup.
Confirm that the Automotive Ethernet connection is present and that the diagnostic application is attached to the intended interface. A missing discovery response at this stage rules the investigation toward the network path or endpoint availability, but does not by itself identify which one is defective.
Capture one clean reproduction and determine whether discovery requests and responses are present, whether the response identifies the expected vehicle or ECU, and whether the response disappears only after a particular request. This separates reachability and target-selection issues from later routing activation issues.
Use the capture to establish whether TCP connection setup completes, whether routing activation is sent to the intended endpoint, and whether the endpoint accepts, rejects, or closes the exchange. This rules out a purely physical failure when the endpoint responds, but may require ECU-side evidence to distinguish configuration from ECU behavior.
Check the ODX or PDX data used by the application against the selected ECU and the requests being sent. Confirm that the connection issue is not actually a UDS addressing, diagnostic-session, or service-expectation mismatch after DoIP communication has already been established.
Repeat the minimum exchange in CANoe or the diagnostic application without unnecessary CAPL automation, then compare the result with the automated sequence. If the controlled exchange works, investigate sequencing, target selection, and timing in the automation rather than the vehicle network first.
Verification gates
Read the active interface selected by the diagnostic application and compare it with the interface physically connected to the vehicle network for the reproduction.
The intended interface is active and is the one used by the capture and diagnostic application.
The result does not isolate the vehicle from the setup; correct the interface selection or connection and repeat discovery before investigating UDS.
In the PCAP, compare the timestamps and target information of each discovery request with the expected vehicle or ECU response.
A response is present for the request and identifies the intended DoIP endpoint.
No response points toward the Automotive Ethernet path, endpoint availability, or incorrect discovery targeting; a response for another endpoint points toward target selection.
Inspect the PCAP for a completed TCP connection to the intended DoIP endpoint and record whether the connection is refused, reset, or closed immediately.
The TCP connection completes and remains available for the DoIP exchange.
A refusal or reset requires investigation of endpoint availability, TCP targeting, or the network path before UDS services are assessed.
Compare the routing activation request with the endpoint response and record whether the exchange is accepted, rejected, absent, or terminated.
The intended endpoint returns an acceptance result and the connection remains usable.
A rejection or termination points toward DoIP configuration, endpoint state, or an ECU-side condition; an absent response points back to transport or endpoint availability.
Read the ECU and diagnostic addressing information used by the diagnostic application from the selected ODX or PDX data and compare it with the discovered target.
The description identifies the same ECU and addressing context as the discovered DoIP endpoint.
A mismatch can cause post-connection diagnostic failure or an apparent target failure; correct the diagnostic data or confirm the intended ECU with the responsible owner.
After a stable DoIP route exists, inspect whether the UDS request and response are present and whether the selected diagnostic session and service expectation match the target ECU.
The UDS request traverses the established route and the ECU returns a response consistent with the selected diagnostic session.
The DoIP connection is not the remaining fault domain; investigate UDS configuration, diagnostic session behavior, or ECU-specific handling.
From evidence to action
Correct the interface selection, physical connection, or network setup identified by the evidence, then repeat discovery and capture a clean exchange. If the path remains unavailable, the vehicle or network owner may need to verify the connected ECU and vehicle state.
Update the diagnostic application, CANoe configuration, or CAPL sequence to use the discovered target and the expected routing activation sequence. Revalidate with a PCAP rather than relying only on application-level status.
Confirm the ECU power and vehicle state required for DoIP communication and repeat the test after startup is complete. If the ECU still does not respond while the Automotive Ethernet path and requests are correct, provide the evidence to the ECU supplier or OEM for ECU-side investigation.
Replace or revise the diagnostic description when it identifies the wrong ECU, addressing context, diagnostic session, or expected service behavior. Validate that the corrected data matches the discovered endpoint before testing UDS services.
FAQ
Diagnostic support
For a documented engineering analysis, diagnostic application, or automated test suite around DoIP and UDS communication, provide the problem description, relevant PCAP, ECU details, and ODX or PDX data for focused investigation.