DoIP test setup: from Ethernet link to UDS over IP

DoIP (Diagnostics over Internet Protocol, ISO 13400-2) carries UDS over Ethernet instead of CAN. Setting up a bench for it is mostly a matter of order: get the link and addressing right, discover the vehicle, activate routing, and only then run diagnostics. Each step has a specific message, and a scan that skips one gets silence instead of findings. Here is the setup that works, with the exchanges byte for byte.

The physical and network link

A DoIP ECU or gateway is an Ethernet node. On the bench you need:

• A point-to-point Ethernet connection or a switch, 100BASE-TX or 100BASE-T1 with a media converter for automotive Ethernet.
• An IP address on the same subnet as the DoIP entity. Many gateways use link-local addressing (169.254.0.0/16) or hand out an address over DHCP.
• The DoIP ports: UDP 13400 for discovery and announcements, TCP 13400 for the diagnostic connection.

If the gateway sends a vehicle announcement on power-up, you can read its IP and logical address straight off the wire before sending anything.

Addressing, the part that trips people up

DoIP has two address spaces that must not be confused. At the network layer there is the IP address. At the diagnostic layer there is the logical address, a 16-bit identifier for each diagnostic entity: the tester has one (often 0x0E00), each ECU has one (for example 0x1001), and the gateway has its own. The diagnostic message header carries a source and a target logical address, and the gateway routes on those.

Step one: vehicle discovery

Send a vehicle identification request over UDP broadcast and the entity answers with its VIN, its logical address and its EID/GID.

tx (UDP 13400 broadcast)  02 FD 00 01 00 00 00 00
                          │     └ payload type 0x0001 VehicleIdentificationRequest
                          └ protocol version 0x02, inverse 0xFD
rx                        02 FD 00 04 ...  VehicleIdentificationResponse
                          (VIN, logical address 0x1001, EID, GID)

Now you have the logical address to target and confirmation the entity is alive.

Step two: open TCP and activate routing

Open a TCP connection to port 13400, then send a routing activation request. This is the handshake that authorises your source address. Nothing you send before it will be routed.

tx  02 FD 00 05 00 00 00 07  0E 00  00  00 00 00 00
    │           │            │      │
    │           │            │      └ activation type 0x00 (default)
    │           │            └ source address 0x0E00 (the tester)
    │           └ payload type 0x0005 RoutingActivationRequest
    └ version
rx  02 FD 00 06 ...  RoutingActivationResponse, code 0x10 = success

Response code 0x10 means activated. Common failures are 0x00 (unknown source address), 0x02 (no free socket) and 0x06 (rejected). A gateway that activates a source address it should not is itself a finding.

Step three: UDS over IP

With routing active, wrap each UDS message in a diagnostic message header (payload type 0x8001) carrying source and target logical addresses. The UDS bytes are identical to CAN; only the wrapper changes.

tx  02 FD 80 01 00 00 00 06  0E 00  10 01  10 03
    │           │            │      │      └ UDS: 10 03 start extended session
    │           │            │      └ target 0x1001 (the ECU)
    │           │            └ source 0x0E00 (the tester)
    │           └ payload type 0x8001 DiagnosticMessage
    └ version
rx  ... 50 03 ...  positive response, extended session

From here, enumeration, DID reads (22 F1 90), routines (31 ...) and SecurityAccess (27 01) all run exactly as over CAN, because the UDS application layer does not care about the transport underneath.

What to test that CAN does not have

DoIP adds its own attack surface on top of UDS:

• Gateway routing. Does the gateway route a tester to ECUs that should be blocked from external diagnostics? We regularly see gateways that route to internal ECUs they should isolate.
• Routing activation. Does it accept any source address, or enforce an authorised set? Does it limit concurrent sockets?
• Discovery exposure. Does the entity announce itself and answer identification requests to anyone on the network?
• SOME/IP alongside. DoIP benches usually carry SOME/IP service traffic too, which is a separate discovery and exposure problem on the same link.

Getting the order right

The whole setup fails quietly if routing activation is skipped or the logical addresses are wrong, because the gateway simply drops the messages and the tester sees timeouts. Discovery, then TCP, then routing activation, then UDS: in that order a DoIP bench behaves predictably. AutoST runs this sequence automatically, handling discovery and routing activation and then driving its transport-generic UDS enumeration and SecurityAccess engines over the IP link, so the same tests you ran on CAN carry straight over to Ethernet and the SOME/IP exposure on the same bench is mapped in the same run.