tracetronic: Ethernet

Vendor information

Vendor

Web page

Product name

Version

tracetronic GmbH

https://www.tracetronic.de

Ethernet Library

Categories

MDL 🛈

APL 🛈

BAN 🛈

BMA 🛈

SVC 🛈

DGN 🛈

FIU 🛈

EES 🛈

FCT 🛈

DBG 🛈

IMG 🛈

AUDIO 🛈

ENVSIM 🛈

ENVCOM 🛈

✓

✓

✓

✓

✓

✓

Platform

Operating system

Support

Windows

✓

Linux

✓

Ports

Info

Ports marked with ✦ are part of the Add-on ecu.test calibration (subject to a separate license)

Specifics

The tool adapter Ethernet has primarily been developed to enable the control of Ethernet based control units. Furthermore individual applications for simulation, diagnostics and functional validation can be realized based on the Ethernet connector. The possible application scenarios are not limited to the control unit domain; the tool adapter can be used anywhere Ethernet based network technologies are used. The protocols Ethernet, ARP, NDP, IP, ICMP, TCP and UDP are the basis for this. Moreover, ecu.test supports the user when using the middle ware technologies SOME/IP and SOME/IP-SD that become more and more important in the automotive industry. The main focus of the port types introduced in the following is on the basic network operations SEND and RECEIVE as well as on the recording of measurement data. The resulting recordings in PCAP format can be processed and analyzed with the trace analysis module.

Further information about how to use services offered via SOME/IP is found in section Service access.

Furthermore, ecu.test can receive PLP/TECMP frames which are sent by so-called probes/devices to data loggers, and thus receive and process the same CAN/CAN-FD, LIN and FlexRay bus traffic that the logger is recording. Also diagnostic via ethernet, based on the Diagnostic over Internet Protocol (DoIP) is supported.

Info

The ports DOIP-SOCKET, DOIP-PCAP and DOSOAD-SOCKET can only be used with the Add-on ecu.test diagnostics

Info

Ethernet measurement devices by Vector Informatik GmbH can be used via the Tool Vector: XL API.

Prerequisites

  • Working with this tool adapter requires basic knowledge of the used network protocols as well as working with Python object structures.

  • Installation of a PCAP driver (e.g. Npcap) is necessary for PCAP based Ports on Windows.

  • Using Npcap 1.70 and newer in conjunction with 802.1q “tagged VLAN” can have limitations regarding the recording of outgoing frames.

  • With Npcap 1.86 and 1.87, problems have been observed. These versions are not recommended.

Protocol, Diagnostic ans Service Port types

Port

Description

Properties

Field of application

SERVICE

  • configurably based on the socket library of the OS or on a custom network stack

SERVICE-PCAP-PASSIVE

  • Passive port for read only service based communication

  • optional consideration of a PLP/TECMP or ASAM CMP data stream

  • also supports reading events without service discovery, if the corresponding IP addresses and ports are contained in the database

  • based on an custom network stack that works independent of the OS

  • conflicts through network settings in the OS are possible => either configure IP address or MAC address with values that differ from addresses in the OS or deactivate IP stack of the OS

  • ARP, NDP and ICMP communication for call control occurs automatically

  • each port can have its own network setting and nevertheless be configured for the same tool adapter

  • if for a physical network adapter several equal or different network configurations are required at the same time

  • if dynamic VLANs shall be configured and used for network connections

TCP-CLIENT-PCAP-SOCKET

  • TCP client

TCP-SERVER-PCAP-SOCKET

  • TCP server for one incoming TCP connection

UDP-PCAP-SOCKET

  • UDP session

DOIP-PCAP

IPSEC

  • negotiates IPsec parameters and activates IPsec for communication by other ports based on the custom network stack, sharing the same network interface, MAC and IP address

  • IPv4 only

MACSEC

  • negotiates MACsec parameters and activates MACsec for communication by other ports based on the custom network stack, sharing the same network interface and MAC address

  • only one IP address can be used by other ports per combination of network interface and MAC address

TLS

  • negotiates TLS parameters and activates TLS for the communication of other ports

  • is based on its own network stack and adds functionality to existing ports

  • Upgrading existing connections

TCP-CLIENT-SOCKET

  • TCP client

  • based on the socket library of the OS

  • if simple network connections shall be used based on the system network settings

  • if very high transmission rates are required

TCP-SERVER-SOCKET

  • TCP server for one incoming TCP connection

UDP-SOCKET

  • UDP session

DOIP-SOCKET

DOSOAD-SOCKET

ARP

  • responds to ARP inquires that are directed to the configured adapter

  • can be started and stopped via tool jobs

  • works autonomically upon start

  • data reception based on filter rules that are specified in BPF (see http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf)

  • During parameterization special attention needs to be paid to the filter configuration. It must be ensured that only packets matching the respective port type are permitted to pass the filter (i.e. for the ARP port only ARP packets, for the UDP port only UDP packets, …). If this rule is disregarded errors during data reception can occur.

  • Rules for VLAN filtering do not have to be regarded during filter parameterization since respective rules are automatically added to the filter. This happens depending on whether the VLAN tagging in the port settings has been activated or not.

  • if the structure of the protocol header for OSI layers 2-4 shall be defined and analyzed manually

  • if full control of data and the way of transmission (no flow control etc.) is required

  • requires extensive protocol knowledge

ETHERNET-RAW

  • enables communication at OSI layer 2

  • any desired network protocol or transport protocol can be implemented and used for sending and receiving

UDP-RAW

  • enables communication based on the transport protocol UDP

Bus Port types

Port

Description

Properties

CAPTURE-CAN(-FD)

  • Enable access to the Ethernet data stream containing PLP/TECMP messages with bus communication

  • Based on PCAP and require a PCAP driver

  • All reading test steps for accessing signals, PDUs and frames are supported

  • Recordings can be created in *.asc format

CAPTURE-LIN

CAPTURE-FLX

SOCKETADAPTOR

  • Enables communication by way of PDUs packaged in UDP packets (AUTOSAR SOCKET ADAPTOR)

  • Based on a custom network stack and requires a PCAP driver

  • Can be used either in active or passive mode, as desired

  • In active mode, only a single local combination of IP address and UDP port is used (for

    listening and as source for outgoing packets), as well as a single combination of IP address and UDP port as a destination. The job “SendPdu” allows sending to arbitrary destinations, independent of that.

  • In passive mode, no transmission is possible. But PDUs not addressed to an IP address

    associated with the ecu.test PC can be received.

  • Recordings can be created in *.pcapng format

SOCKET-ADAPTOR-ACTIVE

  • Properties of port “SOCKET-ADAPTOR-PASSIVE” and port “SERVICE” (using custom network stack, see above) apply, whereby unicast UDP packets between ECUs cannot be received via the active port.

  • Sending to an ECU is supported, but currently limited to just one IP address UDP port combination. However, different IP addresses and UDP ports can be used with the “SendPdu” job.

IEEE1722-CAN(-FD)

  • Access to CAN(-FD) tunneled in IEEE1722/UDP/IPv4

  • Enables reception and transmission of CAN(-FD) frames encapsulated in IEEE1722

  • Based on PCAP und require a PCAP driver

  • Support all functionality of the corresponding “real” hardware-based bus ports.

  • Recordings are createdin *.asc format

IEEE1722-J1939

  • Access to J1939 on CAN tunneled in IEEE1722/UDP/IPv4

Application Port types

Port

Description

Properties

XCP-ETH

Measurement and calibration with XCP

  • configurably based on the socket library of the OS or on a custom network stack

General

Configuration

Set port option “Autostart” to “Always” in the test bench configuration to make sure the tool is started (the default “If necessary” normally won’t work for Ethernet ports due missing dependencies).

Data objects

To efficiently create and evaluate network packet structures special Python data structures have been developed. An API documentation for working with these structures can be found under Ethernet API in the ecu.test installation directory.

Receiving data

If data reception of a port has been started, received packets are stored in a ring buffer data structure. They can be fetched from the buffer via the tool job ReceivePackage by the test case. Packets that has already been fetched from the buffer cannot be fetched again. So fetched data objects have to be stored in variables if needed for further processing.

If it cannot be ensured that a packet has already been received and stored in the ring buffer when calling ReceivePackage it is recommended to enable the Wait until true time option and select ~Present~ as comparison condition.

Notes regarding local use

Using the localhost IP address (127.0.0.1), e.g. for testing and simulation purposes, has the following restriction. Connections between ports based on the socket library of the OS (TCP-CLIENT-SOCKET, TCP-SERVER-SOCKET, UDP-PCAP-SOCKET or external applications) and ports belonging to the network family with own network stack (TCP-CLIENT-PCAP-SOCKET, TCP-SERVER-PCAP-SOCKET, ETHERNET-RAW, UDP-RAW, etc.) CANNOT be established. This restriction is determined by the OS and applies to local communication only.

Notes regarding VLAN

When using VLAN in combination with consumer-grade network drivers and npcap, a bug (https://github.com/nmap/npcap/issues/171) exists that can cause the VLAN tags to be dropped for incoming packets. As a workaround, the receive filter accepts packets with or without VLAN tags. In network segments where packets with and without VLAN tags (tagged and untagged) are mixed, errors can occur as a result.

The workaround only applies when receiving. For sending, the VLAN tag from the TBC is used.

Notes regarding PLP/TECMP access

The main prerequisite is that the bus activity is being captured by so-called Probes/Devices and transferred to a logger via PLP/TECMP. This logger needs to be configured to mirror this PLP/TECMP traffic to an ethernet port. Connect a network adapter of the PC running ecu.test to this port.

In the test bench configuration, that network adapter must be chosen. Moreover, the Probe ID/Device-ID and Bus Spec ID/Interface-ID may be provided as filter. These two parameters can usually be found in the data logger’s configuration.

Transmitting via PLP/TECMP is not supported.

ecu.test is not able to directly interface with a Probe/Device (without a data logger). PLP capable data loggers are e.g. some models of x2e XORAYA and ViGEM CCA.

Notes for use under Linux

Sent messages cannot be recorded by the same port. Another port will be needed for recording.

Ports for bus access (CAPTURE, SOCKET-ADAPTOR) currently cannot be used unter Linux.

With the exception of the port types categorized as “based on the socket library of the OS” in the above table, using this tool inside a container (e.g. Docker) requires the container to have the capabilities CAP_NET_RAW and CAP_NET_ADMIN assigned to it.

Notes about IPsec

Currently only IPv4 is supported, no IPv6. Also, only AH and transport mode are implemented, not ESP, nor tunnel mode. Dead Peer Detection, or, more precisely, Liveness Checks, are currently neither transmitted nor answered.

The configuration requires various certificates and keys. These must be provided in PEM format (ASCII base64). The binary DER format is not supported.

Algorithms/modes are specified as follows:

  • Square brackets group algorithms to be used together (“proposal”).

  • Such groups, as well as algorithms within a group, are separated using commas.

  • For algorithms with variable key length, the algorithm name is followed by a colon and then by the key length in bits.

  • For IKE, one algorithm of each kind (except sequence numbers) is required.

  • For AH, one integrity algorithm and one sequence number mode is needed.

  • The following algorithms are supported:

Designation

Kind

Use

Variable key length?

AUTH_AES_CMAC_96

integrity

AH

no

AUTH_HMAC_SHA2_256_128

integrity

IKE

no

AUTH_HMAC_SHA2_384_192

integrity

IKE

no

AUTH_HMAC_SHA2_512_256

integrity

AH, IKE

no

DH_GROUP_19

key exchange

IKE

no

DH_GROUP_20

key exchange

IKE

no

ENCR_AES_CBC

encryption

IKE

yes

ENCR_AES_CTR

encryption

IKE

yes

ENCR_CAMELLIA_CBC

encryption

IKE

yes

ENCR_CAMELLIA_CTR

encryption

IKE

yes

ESN

sequence numbers

AH

no

NO_ESN

sequence numbers

AH

no

PRF_HMAC_SHA2_256

pseudo random numbers

IKE

no

PRF_HMAC_SHA2_384

pseudo random numbers

IKE

no

PRF_HMAC_SHA2_512

pseudo random numbers

IKE

no

Decrypted IKEv2 packets

IKEv2 packets can automatically be decrypted by trace analysis. For this purpose a file ikev2_decryption_table is required, which will be created by ecu.test and saved in the report directory alongside the pcapng file if signal recording is used.

The file ikev2_decryption_table corresponds to the format used by Wireshark, so the file may be copied to e.g. %APPDATA%/Wireshark in order to be able to decrypt and examine the IKEv2 packets of the recording inside Wireshark as well.

Notes about MACsec

Currently only integrity without confidentiality is supported.

Algorithms/modes are specified as follows:

  • All desired algorithms are written in square brackets separated by a comma

  • ‘GCM-AES-128’ is the default algorithm and will always be enabled

  • The following algorithms are supported:

Designation

Extended packet numbering?

GCM-AES-128

no

GCM-AES-XPN-128

yes

GCM-AES-256

no

GCM-AES-XPN-256

yes

Name

Available if

Default value

Valid values

Type

Description

Validation

☐

bool

If enabled, area boundaries are checked when certain network data objects are parametrized.

Timeout for tool call ❲in sec.❳

‘600’

string

Timeout after which a tool call is aborted.

ClearArpCache

Clears all entries from the internal ARP/NDP cache