DoIP-Testaufbau: vom Ethernet-Link zu UDS über IP

DoIP (Diagnostics over Internet Protocol, ISO 13400-2) trägt UDS über Ethernet statt über CAN. Einen Prüfstand dafür aufzubauen ist vor allem eine Frage der Reihenfolge: Link und Adressierung richtig hinbekommen, das Fahrzeug entdecken, Routing aktivieren, und erst dann Diagnostik fahren. Jeder Schritt hat eine bestimmte Nachricht, und ein Scan, der einen überspringt, bekommt Stille statt Findings. Hier ist der Aufbau, der funktioniert, mit den Austauschen Byte für Byte.

Der physische und der Netzwerk-Link

Ein DoIP-ECU oder -Gateway ist ein Ethernet-Knoten. Am Prüfstand brauchst du:

• Eine Punkt-zu-Punkt-Ethernet-Verbindung oder einen Switch, 100BASE-TX oder 100BASE-T1 mit einem Medienkonverter für Automotive-Ethernet.
• Eine IP-Adresse im selben Subnetz wie die DoIP-Entität. Viele Gateways nutzen Link-Local-Adressen (169.254.0.0/16) oder vergeben eine Adresse über DHCP.
• Die DoIP-Ports: UDP 13400 für Discovery und Announcements, TCP 13400 für die Diagnoseverbindung.

Sendet das Gateway beim Einschalten ein Vehicle Announcement, kannst du seine IP und logische Adresse direkt vom Draht lesen, bevor du etwas sendest.

Adressierung, der Teil, über den man stolpert

DoIP hat zwei Adressräume, die man nicht verwechseln darf. Auf der Netzwerkschicht gibt es die IP-Adresse. Auf der Diagnoseschicht gibt es die logische Adresse, einen 16-Bit-Identifier für jede Diagnose-Entität: der Tester hat eine (oft 0x0E00), jedes ECU hat eine (zum Beispiel 0x1001), das Gateway hat seine eigene. Der Diagnostic-Message-Header trägt eine Quell- und eine Ziel-Logical-Address, und das Gateway routet nach diesen.

Schritt eins: Vehicle Discovery

Sende einen Vehicle Identification Request per UDP-Broadcast, und die Entität antwortet mit ihrer VIN, ihrer logischen Adresse und ihrer EID/GID.

tx (UDP 13400 Broadcast)  02 FD 00 01 00 00 00 00
                          │     └ Payload-Type 0x0001 VehicleIdentificationRequest
                          └ Protokollversion 0x02, invers 0xFD
rx                        02 FD 00 04 ...  VehicleIdentificationResponse
                          (VIN, logische Adresse 0x1001, EID, GID)

Jetzt hast du die logische Zieladresse und die Bestätigung, dass die Entität lebt.

Schritt zwei: TCP öffnen und Routing aktivieren

Öffne eine TCP-Verbindung zu Port 13400, dann sende einen Routing Activation Request. Das ist der Handshake, der deine Quelladresse autorisiert. Nichts, was du vorher sendest, wird geroutet.

tx  02 FD 00 05 00 00 00 07  0E 00  00  00 00 00 00
    │           │            │      │
    │           │            │      └ Activation-Type 0x00 (default)
    │           │            └ Quelladresse 0x0E00 (der Tester)
    │           └ Payload-Type 0x0005 RoutingActivationRequest
    └ Version
rx  02 FD 00 06 ...  RoutingActivationResponse, Code 0x10 = Erfolg

Response-Code 0x10 heißt aktiviert. Häufige Fehler sind 0x00 (unbekannte Quelladresse), 0x02 (kein freier Socket) und 0x06 (abgelehnt). Ein Gateway, das eine Quelladresse aktiviert, die es nicht sollte, ist selbst ein Finding.

Schritt drei: UDS über IP

Mit aktivem Routing kapselst du jede UDS-Nachricht in einen Diagnostic-Message-Header (Payload-Type 0x8001), der Quell- und Ziel-Logical-Address trägt. Die UDS-Bytes sind identisch zu CAN; nur die Hülle ändert sich.

tx  02 FD 80 01 00 00 00 06  0E 00  10 01  10 03
    │           │            │      │      └ UDS: 10 03 Extended Session starten
    │           │            │      └ Ziel 0x1001 (das ECU)
    │           │            └ Quelle 0x0E00 (der Tester)
    │           └ Payload-Type 0x8001 DiagnosticMessage
    └ Version
rx  ... 50 03 ...  positive Antwort, Extended Session

Von hier laufen Enumeration, DID-Lesungen (22 F1 90), Routinen (31 ...) und SecurityAccess (27 01) alle genau wie über CAN, weil der UDS-Application-Layer den darunterliegenden Transport nicht interessiert.

Was zu testen ist, das CAN nicht hat

DoIP fügt über UDS hinaus seine eigene Angriffsfläche hinzu:

• Gateway-Routing. Routet das Gateway einen Tester zu ECUs, die vor externer Diagnostik gesperrt sein sollten? Wir sehen regelmäßig Gateways, die zu internen ECUs routen, die sie isolieren sollten.
• Routing Activation. Akzeptiert sie jede Quelladresse oder setzt sie einen autorisierten Satz durch? Begrenzt sie gleichzeitige Sockets?
• Discovery-Exposition. Kündigt sich die Entität an und beantwortet sie Identification Requests für jeden im Netzwerk?
• SOME/IP daneben. DoIP-Prüfstände tragen meist auch SOME/IP-Service-Traffic, was ein separates Discovery- und Expositions-Problem auf demselben Link ist.

Die Reihenfolge richtig machen

Der ganze Aufbau scheitert leise, wenn Routing Activation übersprungen wird oder die logischen Adressen falsch sind, denn das Gateway verwirft die Nachrichten einfach und der Tester sieht Timeouts. Discovery, dann TCP, dann Routing Activation, dann UDS: in dieser Reihenfolge verhält sich ein DoIP-Prüfstand vorhersagbar. AutoST fährt diese Sequenz automatisch, handhabt Discovery und Routing Activation und treibt dann seine transport-generischen UDS-Enumeration- und SecurityAccess-Engines über den IP-Link, sodass dieselben Tests, die du auf CAN gefahren hast, direkt auf Ethernet übergehen und die SOME/IP-Exposition am selben Prüfstand im selben Lauf abgebildet wird.