tracetronic: Ethernet

Bisheriger/interner Bezeichner: ETHERNET

Herstellerinformationen

Hersteller

Webseite

Produktname

Version

tracetronic GmbH

https://www.tracetronic.de

Ethernet Library

Kategorien

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

✓

✓

✓

Plattform

Betriebssystem

Unterstützung

Windows

✓

Linux

✓

Ports

Besonderheiten

Der Tooladapter Ethernet wurde vorrangig entwickelt, um die Ansteuerung Ethernet-basierter Steuergeräte zu ermöglichen. Darüber hinaus können auf Basis der Ethernet-Anbindung eigene Applikationen zur Simulation, Diagnose und funktionalen Absicherung realisiert werden. Die möglichen Anwendungsszenarien beschränken sich hierbei nicht auf das Steuergeräteumfeld; zum Einsatz kann der Tooladapter überall dort kommen, wo auf Ethernet aufbauende Vernetzungstechnologien verwendet werden. Die Protokolle Ethernet, ARP, NDP, IP, ICMP, TCP und UDP bilden hierfür die Grundlage. Außerdem unterstützt ecu.test den Anwender bei der Verwendung der sich im Fahrzeugumfeld etablierenden Middleware-Technologien SOME/IP und SOME/IP-SD. Im Fokus der nachfolgend näher beschriebenen Porttypen stehen die grundlegenden Netzwerkoperationen Senden und Empfangen sowie die Messdatenaufzeichnung. Die dabei anfallenden Aufzeichnungen, die im PCAP-Format erstellt werden, können mit der Traceanalyse weiterverarbeitet und analysiert werden.

Weitergehende Informationen wie per SOME/IP angebotene Services verwendet werden können, finden sich im Abschnitt Service-Zugriff.

Darüberhinaus können PLP/TECMP-Botschaften, die von sogenannten Probes/Devices an Datenlogger gesendet werden, mitgelesen werden, um die vom Logger aufgezeichneten CAN-/CAN-FD-, LIN- und FlexRay-Botschaften gleichzeitig in ecu.test zu empfangen und auszuwerten. Des Weiteren wird Ethernet-basierte UDS-Diagnose auf Grundlage des Diagnostic over Internet Protocols (DoIP) unterstützt.

Info

Die Ports DOIP-SOCKET, DOIP-PCAP und DOSOAD-SOCKET sind nur mit dem Add-on ecu.test diagnostics verfügbar

Info

Ethernet-Messgeräte der Vector Informatik GmbH können über das Tool Vector: XL API verwendet werden.

Voraussetzungen

  • Die Arbeit mit diesem Tooladapter erfordert grundlegende Kenntnisse über die verwendeten Netzwerkprotokolle und die Arbeit mit Python-Objektstrukturen.

  • Für PCAP-basierte Ports ist die Installation des Npcap-Gerätetreibers (https://nmap.org/npcap/) notwendig.

  • Bei der Verwendung von Npcap 1.70 und neuer i.V.m. 802.1q „tagged VLAN“ kann es zu Einschränkungen bei der Aufzeichnung von selbst versendeten Paketen kommen.

Protokoll-, Diagnose- und Service-Porttypen

Port

Beschreibung

Eigenschaften

Einsatzbereich

SERVICE

  • basiert wahlweise entweder auf Socketbibliothek des Betriebssystems oder auf eigenem Netzwerkstack

SERVICE-PCAP-PASSIVE

  • Passiver Port für ausschließlich lesende Service-basierte Kommunikation

  • optional Berücksichtigung eines PLP/TECMP- oder ASAM-CMP-Datemstroms

  • unterstützt auch das Lesen von Events ohne Service-Discovery, sofern die zugehörigen IP-Adressen und Ports in der Datenbasis enthalten sind

  • basieren auf einem eigenen Netzwerkstack der unabhängig vom Netzwerkstack des Betriebssystems arbeitet

  • Konflikte durch Netzwerkeinstellungen im Betriebssystem sind möglich => Entweder IP- und MAC-Adresse mit Werten konfigurieren, die sich von den Adressen im Betriebssystem unterscheiden oder IP-Stack des Betriebssystems deaktivieren

  • ARP-, NDP- und ICMP-Kommunikation zur Verbindungssteuerung erfolgt automatisch

  • jeder Port kann eigene Netzwerkeinstellungen besitzen und dennoch für den gleichen Netzwerkadapter konfiguriert sein

  • wenn einfache Netzwerkverbindungen auf Basis der System-Netzwerkeinstellungen verwendet werden sollen

  • falls für einen physikalischen Netzwerkadapter mehrere gleiche oder unterschiedliche Netzwerkkonfigurationen zur selben Zeit benötigt werden

  • dynamisch VLANs konfiguriert und für Netzwerkverbindungen verwendet werden sollen

TCP-CLIENT-PCAP-SOCKET

  • TCP-Client

TCP-SERVER-PCAP-SOCKET

  • TCP-Server für eine eingehende TCP-Verbindung

UDP-PCAP-SOCKET

  • UDP-Sitzung

DOIP-PCAP

IPSEC

  • handelt IPsec-Parameter aus und aktiviert IPsec für die Kommunikation anderer Ports mit eigenem Netzwerkstack, die die gleiche Netzwerkkarte sowie MAC- und IP-Adresse verwenden

  • nur IPv4

MACSEC

  • handelt MACsec-Parameter aus und aktiviert MACsec für die Kommunikation anderer Ports mit eigenem Netzwerkstack, die die gleiche Netzwerkkarte sowie MAC-Adresse verwenden

  • pro Kombination aus Netzwerkkarte und MAC-Adresse darf nur eine IP-Adresse durch andere Ports verwendet werden

TLS

  • handelt TLS-Parameter aus und aktiviert TLS für die Kommunikation anderer Ports

  • basiert auf eigenem Netzwerkstack und erweitert bestehende Ports um die Funktionalität

  • erweitert bestehender Verbindungen

TCP-CLIENT-SOCKET

  • TCP-Client

  • basieren auf der Socket-Bibliothek des Betriebssystems

  • wenn einfache Netzwerkverbindungen auf Basis der System-Netzwerkeinstellungen verwendet werden sollen

  • sehr hohe Übertragungsraten erforderlich sind

TCP-SERVER-SOCKET

  • TCP-Server für eine eingehende TCP-Verbindung

UDP-SOCKET

  • UDP-Sitzung

DOIP-SOCKET

DOSOAD-SOCKET

  • Port für Diagnosesitzung auf Grundlage von Diagnostics over AUTOSAR Socket Adaptor (DoSoAD)

ARP

  • beantwortet ARP-Anfragen die an den konfigurierten Adapter gerichtet werden

  • kann über Tooljobs gestartet und beendet werden

  • arbeitet nach dem Start autonom

  • Datenempfang basiert auf Filterregeln, die im BPF (Berkeley Packet Format) angegeben sind (siehe http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)

  • Bei der Parametrierung muss beachtet werden, dass nur Pakete durch den Filter gelassen werden dürfen, die dem Typ des Ports entsprechen (im ARP-Port dürfen nur ARP-Pakete den Filter passierten, im UDP-Port nur UDP-Pakete, …). Die einzige Ausnahme bildet der Port RECORDING-PCAP, mit dem beliebige Datenströme aufgezeichnet werden können. Beachtet man diese Regel nicht, kann es zu Fehlern während des Datenempfangs kommen.

  • Regeln zur VLAN-Filterung brauchen bei der Filterparametrierung nicht berücksichtigt werden, da der Filter automatisch um den entsprechende Regelzusatz ergänzt wird. Dies geschieht in Abhängigkeit davon, ob VLAN-Tagging in den Port-Einstellungen aktiviert wurde oder nicht.

  • wenn der Aufbau der Protokollheader für OSI-Schicht 2-4 für Protokolltests manuell definiert und analysiert werden sollen

  • exakt vorgegeben werden soll, welche Daten wie versendet werden sollen (keine Flusskontrolle, etc.)

  • Verwendung erfordert tiefergehende Protokollkenntnisse

ETHERNET-RAW

  • ermöglicht Kommunikation auf OSI-Schicht 2

  • beliebige Vermittlungs- und Transportprotokolle können zum Senden und Empfangen implementiert und verwendet werden

ICMP-RAW

  • ermöglicht ICMP-basiertes Senden und Empfangen

  • Echo Requests werden nicht automatisch beantwortet, Beantwortung muss bei Bedarf manuell erfolgen

UDP-RAW

  • ermöglicht auf dem Transportprotokoll UDP aufbauende Kommunikation

RECORDING-PCAP

  • Port zu Erzeugung von PCAP-Aufnahmen mit beliebigem Inhalt

Bus-Porttypen

Port

Beschreibung

Eigenschaften

CAPTURE-CAN(-FD)

  • Ermöglicht den Zugriff auf den Ethernet-Datenstrom in dem PLP/TECMP Nachrichten mit Buskommunikation enthalten sind

  • Basieren auf PCAP und benötigen den Npcap-Gerätetreiber

  • Unterstützt werden alle lesenden Testschritte für den Zugriff auf Signale, PDUs und Frames

  • Aufnahme können im *.asc Format erstellt werden

CAPTURE-LIN

CAPTURE-FLX

SOCKETADAPTOR

  • Ermöglicht Kommunikation mittels in UDP verpackten PDUs (AUTOSAR SOCKET ADAPTOR)

  • Basiert auf einem eigenen Netzwerkstack und benötigt den Npcap-Gerätetreiber

  • Kann wahlweise aktiv oder passiv betrieben werden.

  • Im aktiven Modus wird nur eine einzige lokale Kombination aus IP-Adresse und UDP-Port für Empfang und als

    Absender verwendet, sowie eine einzige Kombination aus IP-Adresse und UDP-Port als Ziel. Der Job „SendPdu“ ermöglicht davon unabhängig das Senden an beliebige Empfänger.

  • Im passiven Modus ist kein Senden möglich. Dafür können PDUs auch dann empfangen werden, wenn sie nicht an

    eine dem ecu.test-Rechner zugewiesene IP-Adresse gerichtet sind.

  • Aufnahmen erfolgen im *.pcapng Format

IEEE1722-CAN(-FD)

  • Zugriff auf CAN(-FD) über IEEE1722/UDP/IPv4

  • Ermöglicht Empfang und Senden von in IEEE1722 gekapselten CAN(-FD)-Frames

  • Basieren auf PCAP und benötigt den Npcap-Gerätetreiber

  • Unterstützen alle Funktionen der entsprechenden „echten“ hardwarebasierten Bus-Ports

  • Aufnahmen erfolgen im *.asc Format

IEEE1722-CAN(-FD)-MANIP

  • Zugriff auf CAN(-FD) über IEEE1722/UDP/IPv4

IEEE1722-J1939

  • Zugriff auf J1939 über CAN über IEEE1722/UDP/IPv4

Applikations-Porttypen

Info

Diese Ports sind nur mit dem Add-on ecu.test calibration verfügbar.

Port

Beschreibung

Eigenschaften

XCP-ETH

Messen und Verstellen per XCP

basiert auf der Socket-Bibliothek des Betriebssystems

XCP-PCAP

basiert auf eigenem Netzwerkstack

Allgemein

Konfiguration

Als Autostart-Option der Ports sollte „Immer“ in der Testbenchkonfiguration ausgewählt werden, um sicherzustellen, dass das Tool gestartet wird (der Standardwert „Wenn benötigt“ funktioniert aufgrund fehlender Abhängigkeiten in der Regel nicht für Ethernet-Ports).

Datenobjekte

Um effizient Netzwerkpaketstrukturen erstellen und auswerten zu können, wurden spezielle Python-Datenstrukturen entwickelt. Eine API-Dokumentation für die Arbeit mit diesen Strukturen befindet sich unter Ethernet API im ecu.test Installationsverzeichnis.

Empfangen von Daten

Ist der Datenempfang eines Ports gestartet, werden entgegengenommene Pakete in einer Ringpuffer-Datenstruktur abgelegt. Empfangene Pakete werden im Testfall mit dem Tooljob ReceivePacket aus dem Ringpuffer ausgelesen. Einmal abgeholte Pakte können kein weiteres Mal aus dem Ringpuffer ausgelesen werden. Deshalb müssen abgeholte Datenobjekte in Variablen gespeichert werden, falls für die weitere Verarbeitung benötigt.

Kann zum Zeitpunkt des ReceivePacket-Aufrufs nicht sichergestellt werden, dass bereits ein Paket empfangen wurde, empfiehlt es sich, den Aufruf mit der Warte bis wahr Zeitoption und der Bedingung ~Present~ zu kombinieren.

Bemerkung zur lokalen Verwendung

Die Nutzung der localhost IP-Adresse (127.0.0.1), z.B. für Test- oder Simulationszwecken, ist mit folgender Einschränkung verbunden. Es können keine Verbindungen zwischen Ports, die auf der Socket-Bibliothek des Betriebssystems basieren (TCP-CLIENT-SOCKET, TCP-SERVER-SOCKET, UDP-PCAP-SOCKET oder externe Anwendungen) und Ports, die zur Netzwerkfamilie mit eigenem Netzwerkstack gehören (TCP-CLIENT-PCAP-SOCKET, TCP-SERVER-PCAP-SOCKET, ETHERNET-RAW, UDP-RAW, usw.), hergestellt werden. Diese Einschränkung ist betriebssystembedingt und gilt nur für die lokale Kommunikation.

Hinweise zu VLAN

Bei der Verwendung von VLAN in Kombination mit Consumer-Grade Netzwerktreibern und npcap existiert ein Bug (https://github.com/nmap/npcap/issues/171), der dazu führen kann, dass bei eingehenden Paketen die VLAN-Tags abgeschnitten werden. Als Workaround nimmt der Empfangsfilter sowohl Pakete mit dem konfigurierten als auch gänzlich ohne VLAN-Tag entgegen. In Netzwerksegmenten in denen Pakete mit und ohne VLAN-Tag (tagged und untagged) gemischt sind, kann es dementsprechend zu Fehlern kommen.

Der Workaround bezieht sich nur auf das Empfangen. Beim Senden werden, sofern in der Testbenchkonfiguration VLAN-Tagging konfiguriert ist, immer Ethernet-Frames mit VLAN-Tag verschickt.

Hinweise zum PLP/TECMP Zugriff

Voraussetzung ist, dass die mitzulesenden Busse von sogenannten Probes abgehört und per PLP/TECMP an einen Logger übertragen werden. Dieser Logger muss so konfiguriert sein, dass er den PLP/TECMP-Datenverkehr an einen Ethernet-Port spiegelt. An diesen wird ein Netzwerkadapter des PCs angeschlossen, auf dem ecu.test läuft.

In der Testbenchkonfiguration muss dann jeweils dieser Netzwerkadapter gewählt werden. Außerdem können die Parameter Probe-ID/Device-ID und Bus-Spec-ID/Interface-ID als Filter angegeben werden. Diese beiden Parameter können ggf. der Konfiguration des Datenloggers entnommen werden.

Senden über PLP/TECMP ist nicht möglich.

ecu.test ist nicht in der Lage, eine Probe/Device direkt (ohne Datenlogger) anzusteuern. PLP/TECMP-fähige Datenlogger sind z.B. manche Modelle von x2e XORAYA und ViGEM CCA.

Hinweise zur Verwendung unter Linux

Aufgrund eines Fehlers in der libpcap0.8 Version 1.8.1, die z.B. unter Ubuntu 18.04 LTS zum Einsatz kommt, funktionieren bestimmte BPF-Filter nicht, insbesondere für das VLAN-tagging. Daher wird empfohlen, mindestens die libpcap0.8 Version 1.9.1 zu verwenden, z.B. aus Ubuntu 20.04 LTS.

Gesendete Botschaften können nicht mit demselben Port aufgezeichnet werden. Hierfür ist ein weiterer Port erforderlich.

Ports für den Buszugriff (CAPTURE, SOCKET-ADAPTOR) können derzeit unter Linux nicht verwendet werden.

Mit Ausnahme der in der obigen Tabelle als „basieren auf der Socket-Bibliothek des Betriebssystems“ gekennzeichneten Port-Typen erfordert die Verwendung dieses Tooladapters in einem Container (z.B. Docker) dass diesem die Capabilities CAP_NET_RAW und CAP_NET_ADMIN zur Verfügung stehen.

Hinweise zu IPsec

Aktuell wird nur IPv4 unterstützt, kein IPv6. Es wird auch nur AH und der Transport Mode unterstützt, weder ESP noch Tunnel Mode. Dead Peer Detection bzw. Liveness Checks werden aktuell weder gesendet noch beantwortet.

Zur Konfiguration ist die Angabe diverser Zertifikate und Schlüssel erforderlich. Diese müssen jeweils im PEM-Format (ASCII base64) vorliegen. Das binäre DER-Format wird nicht unterstützt.

Die Algorithmen bzw. Modi werden wie folgt angegeben:

  • In eckigen Klammern stehen gemeinsam zu verwendende Algorithmen („proposal“).

  • Mehrere solche Gruppen, sowie die Algorithmen innerhalb einer Gruppe, sind durch Komma getrennt.

  • Bei Algorithmen mit parametrierbarer Schlüssellänge folgt auf den Namen des Algorithmus ein Doppelpunkt und dann die Schlüssellänge in Bit.

  • Für IKE ist pro Art (außer Sequenznummern) ein Algorithmus erforderlich.

  • Für AH muss ein Integritäts-Algorithmus und ein Sequenznummern-Modus angegeben werden.

  • Unterstützt werden folgende Algorithmen:

Bezeichnung

Art

Verwendung

Schlüssellänge variabel?

AUTH_AES_CMAC_96

Integrität

AH

nein

AUTH_HMAC_SHA2_256_128

Integrität

IKE

nein

AUTH_HMAC_SHA2_384_192

Integrität

IKE

nein

AUTH_HMAC_SHA2_512_256

Integrität

AH, IKE

nein

DH_GROUP_19

Schlüsselaustausch

IKE

nein

DH_GROUP_20

Schlüsselaustausch

IKE

nein

ENCR_AES_CBC

Verschlüsselung

IKE

ja

ENCR_AES_CTR

Verschlüsselung

IKE

ja

ENCR_CAMELLIA_CBC

Verschlüsselung

IKE

ja

ENCR_CAMELLIA_CTR

Verschlüsselung

IKE

ja

ESN

Sequenznummern

AH

nein

NO_ESN

Sequenznummern

AH

nein

PRF_HMAC_SHA2_256

Pseudozufallszahlen

IKE

nein

PRF_HMAC_SHA2_384

Pseudozufallszahlen

IKE

nein

PRF_HMAC_SHA2_512

Pseudozufallszahlen

IKE

nein

Entschlüsselte IKEv2-Pakete

IKEv2-Pakete können mit der Traceanalyse bei Bedarf automatisch entschlüsselt werden. Voraussetzung hierfür ist eine Datei ikev2_decryption_table, die durch ecu.test erzeugt und bei Verwendung der Signalaufnahme neben die entstehende pcapng-Datei im Reportverzeichnis abgelegt wird.

Die Datei ikev2_decryption_table entspricht dem von Wireshark verwendeten Format, sodass sie z.B. nach %APPDATA%/Wireshark kopiert werden kann, um die IKEv2-Pakete der Aufnahme anschließend auch mit Wireshark entschlüsseln und analysieren zu können.

Hinweise zu MACsec

Aktuell wird nur die Integritätsprüfung ohne Verschlüsselung unterstützt.

Die Algorithmen bzw. Modi werden wie folgt angegeben:

  • In eckigen Klammern stehen durch Komma getrennt alle gewünschten Algorithmen

  • ‚GCM-AES-128‘ ist der Standard-Algorithmus und ist immer aktiviert

  • Unterstützt werden folgende Algorithmen:

Bezeichnung

Erweiterte Paketnummern?

GCM-AES-128

nein

GCM-AES-XPN-128

ja

GCM-AES-256

nein

GCM-AES-XPN-256

ja