Validating Automotive Ethernet Networks with Man-in-the-Middle Testing

Automotive Ethernet introduces complexity beyond legacy protocols like controller area network (CAN) CAN or local interconnect network (LIN).While higher-level software validation is common, low-level communication errors—such as corrupted frames, timing violations, or electrical noise—are often filtered out by commercial NICs and remain undetected. These faults can manifest as ECU software lockups, unexplained error messages, latency spikes, or failures in sleep/wake protocols like TC10.

To ensure reliability and safety, engineers need tools that allow testing at the MAC layer, where these issues originate. MitM testing addresses this gap by enabling active manipulation of live traffic, including anomalies such as corrupted frame check sequences (FCS), to evaluate system robustness under real-world conditions. This capability is critical for modern vehicles, where Ethernet supports time-sensitive and safety-critical applications.

Validating Automotive Ethernet Networks with Man-in-the-Middle Testing

As vehicles become more connected, autonomous, and software-defined, automotive Ethernet is emerging as the backbone of in-vehicle communication. From advanced driver assistance systems (ADAS) to infotainment and vehicle to everything (V2X), automotive Ethernet enables high-speed, low-latency data exchange across increasingly complex electronic control units (ECUs).

However, traditional validation methods often overlook low-level communication faults that can lead to software lockups, timing issues, and unpredictable behavior. This white paper introduces man-in-the-middle (MitM) testing as a powerful technique to uncover hidden issues and validate the robustness of automotive Ethernet networks.

Leveraging the modular NI hardware platform—specifically, the NI PXIe-6592 (used for both the MitM and the personality/Sim-DUT)—engineers can simulate real-world faults, inject traffic, and monitor ECU responses with precision.

MitM testing involves inserting a programmable test system between two communicating devices—typically ECUs or gateways—to intercept, manipulate, and analyze network traffic at the MAC layer. Unlike passive monitoring, MitM enables engineers to actively manipulate live traffic, introducing controlled disruptions to validate fault tolerance and error-handling mechanisms.

Figure 1: MitM Architecture Diagram

Traditional NICs discard invalid frames, making fault injection impossible. The PXIe-6592 high-speed serial module bypasses the operating system (OS) and network interface card (NIC) layers, providing direct access to Ethernet frames—valid or corrupted—with microsecond latency and sub-microsecond timestamp accuracy. Engineers can break FCS, inject traffic from files or live sources, trigger TC10 sleep/wake commands, log traffic into packet capture (PCAP) files and automate tests using Google remote procedure call (gRPC) application programming interfaces (APIs).

Figure 2: MitM Workflow Diagram

To enable man-in-the-middle testing at scale, the NI modular platform is designed for high-performance, deterministic control of automotive Ethernet traffic. Unlike traditional NIC-based solutions, this platform combines FPGA-level flexibility with the synchronization and scalability of PXI, making it ideal for fault injection, timing analysis, and protocol validation. At its core, the system integrates specialized hardware for real-time frame manipulation and a software stack that supports automation, remote control, and deep packet inspection.

Hardware: PXIe-6592 with four SFP ports supporting 100/1000BASE-T1 and other Ethernet variants.

Software: NI LabVIEW and gRPC APIs for automation and PCAP integration for packet analysis.

In MitM testing for automotive Ethernet, two core capabilities define how engineers manipulate and analyze network traffic at the MAC layer:

• FCS operations—These operations involve altering the frame check sequence in Ethernet frames to simulate corruption and validate error-handling mechanisms. MitM comes with several FCS breaking modes.
• Injection methods—These methods are techniques for introducing additional traffic—either synthetic or replayed—into the communication stream to stress-test ECUs under realistic or extreme conditions.

Together, these capabilities enable engineers to reproduce field issues, inject controlled faults, and validate robustness under diverse scenarios—something traditional NICs or passive monitoring cannot achieve.

Let’s take a deep dive into each one of them to analyze their features.

The following figure shows where the FCS breaking feature (red rectangle) is applied; acquired traffic on Port 0 is passed to the FCS breaking feature, and modified traffic is then passed to the mixer.

Figure 3: MitM FCS Breaking Feature Location

MitM supports multiple FCS manipulation modes. Those modes are illustrated with PCAP files loaded into Wireshark®* and some screen captures are available in Appendix A.

• All Enabled: All frames have incorrect FCS.
• All Disabled: All frames have correct FCS.
• 1 Cycle—50%: Half of frames have broken FCS.
• N Cycles—50%: Every other frame has broken FCS.
• Random: Randomized FCS corruption.
• Percentage: User-defined percentage of frames corrupted.
• Custom: User uploads an array (up to 8,192 elements) for precise control.
  

Figure 4 shows how the FCS breaking settings are applied on incoming traffic by the FPGA.

Figure 4: FCS Breaking FPGA Algorithm

MitM supports two injection methods:

Frame generator (DMA), which generates frames for stress testing, and port injection, which mixes live traffic from Port 1 with generated frames.

Injected traffic is combined with FCS-modified frames to simulate realistic network conditions. The red rectangles in Figure 5 represent the injection path.

Figure 5: Injection

Appendix B details test conditions and results for the frame generator (DMA) injection method.

A second PXIe-6592 is used to test the MitM. It runs a different FPGA personality called “Sim/DUT,”

Figure 6: MitM with Test Setup (Sim/DUT)

1. Regression Testing for Known Faults

When a field issue is traced to a specific corrupted frame or timing anomaly, MitM testing provides deterministic reproduction of the fault scenario; therefore, engineers can:

• Replay exact traffic patterns captured from the field, including malformed frames and timing irregularities.
• Monitor ECU behavior at the MAC layer, ensuring visibility into error-handling routines and protocol stack responses.
• Validate corrective software patches under identical conditions before deployment, reducing risk of regression in production environments.

2. Stress Testing Under Full Bus Load

MitM systems enable controlled saturation of the Ethernet bus by injecting high volumes of mixed traffic, both real and simulated, therefore this allows engineers to:

• Push bandwidth to theoretical limits, validating throughput and latency under worst-case conditions.
• Characterize ECU performance under congestion, including frame prioritization and buffer management.
• Identify timing violations and bottlenecks that may compromise deterministic communication in safety-critical applications.

3. Sleep/Wake Protocol Validation (TC10)

In electric vehicles, the TC10 protocol governs transitions between active and low-power states. MitM testing ensures compliance and robustness by:

• Triggering sleep/wake sequences with microsecond precision, simulating real-world timing constraints.
• Introducing controlled noise or delays to validate ECU resilience against imperfect network conditions.
• Measuring latency and power transition behavior, providing quantitative data for compliance with OEM power management requirements.

The adoption of MitM systems for Ethernet validation marks a significant advancement in the testing and assurance of automotive networks. By enabling precise control over traffic injection, fault simulation, and protocol validation, these solutions empower engineers to recreate real-world network conditions, thoroughly assess ECU behavior, and verify compliance with stringent industry requirements. Stress testing under full bus load and rigorous sleep/wake protocol validation ensure that critical parameters—such as bandwidth, latency, and power management—are not only measured but also optimized for safety and reliability. The ability to identify bottlenecks, timing violations, and resilience against imperfect conditions provides a robust foundation for developing next-generation electric and connected vehicles.

As automotive Ethernet continues to evolve, the integration of advanced validation tools—such as FPGA-based hardware and flexible, automated software—will remain essential for OEMs and Tier 1 suppliers. These technologies not only streamline the development process but also elevate the standard for vehicle safety, connectivity, and efficiency. Looking forward, comprehensive validation strategies rooted in realistic testing will be critical to meeting the demands of increasingly complex vehicle architectures and ensuring the seamless operation of tomorrow’s mobility solutions.

This section illustrates the different FCS breaking modes available with the MitM.

Note: In the following screenshot examples, Wireshark® is used; it is set to:

• Check for FCS and expect an FCS.
• Display in red font frames with invalid FCS.

All-Enabled Mode

In all-enabled mode, all frames’ FCS are broken.

Figure 7: All‑Enabled FCS Breaking Mode All‑Enabled FCS Breaking Mode – All captured Ethernet frames show invalid FCS due to MitM corruption.

All-Disabled Mode

In all-disabled mode, no frames have their FCS broken.

Figure 8: All‑Disabled FCS Breaking Mode – Wireshark capture showing normal Ethernet traffic with all frames

1 Cycle 50% Mode

In this example, the block size is 20 frames. It implies that 50 percent of the block (10 frames) has its FCS broken and rest (10 frames) has its FCS untouched.

Figure 9: Cycle 50% FCS Breaking Mode – Half of the frames in each block have broken FCS, half remain valid.

N Cycles 50% Mode

In this example, every other frame has its FCS broken.

Figure 10: N‑Cycle 50% FCS Breaking Mode – Every other Ethernet frame has its FCS intentionally broken.

Percent (%) Mode

In this mode, the block size is 100 frames and the percent passed by the user is 80. It implies that 80 percent of the block (80 frames) has its FCS broken and the rest (20 frames) have its FCS untouched, then we repeat that.

Figure 11: Percent (%) FCS Breaking Mode – Repeating blocks of 100 frames where 80% of the frames have intentionally broken FCS and 20% remain valid.

Random Mode

In this example, user defines a block Size (up to 8,192), random values (True or False) are synthesized and used to define when the frame FCS is broken. Then, it repeats.

Figure 12: Random FCS Breaking Mode – Ethernet frames have their FCS broken according to a randomized pattern within a user‑defined block size, repeated cyclically.

This section illustrates the use of injection (frames generator (DMA)).

Test Conditions

This is the result of a test at 1 Gb/s.

• Port 0 of MitM is connected to a data source via 1000BASE-T1 link.
• Ports 2 and 3 are connected to some other test ports via direct SFP cable. The test ports are used to measure number of frames received.
• We use the PCAP sniffing feature to acquire the output traffic of the mixer (MitM Tx data). This allows a very accurate timestamp of the operations.
• The test happens in three phases:
  • Phase 1. We start applying traffic on Port 0 (MitM Rx). Traffic is made of 20 streams, 100 µs period. The stream size varies from 78 to 173 bytes by 5 bytes increment. The MAC source is: 00:2F:80:17:29:68. The traffic is generated by another FPGA-based source, used with a SFP 1000BASE-T1 adapter.
  • Phase 2. While still applying traffic on Port 0, we start the frames generator . The traffic from the generator is the same as the one applied on Port 0 but with a different MAC source: 00:2F80:11:25:34.
  • Phase 3. No more traffic on Port 0, only the injection frames generator .
• Quantity of data is 1,200,000 frames total. A breakdown:
  • 600,000 frames (30,000 frames per stream, 20 streams) applied to MitM Rx, MAC source: 00:2F:80:17:29:68.
  • 600,000 frames (30,000 frames per stream, 20 streams) generated by the frames generator (DMA), MAC source: 00:2F80:11:25:34.

Test Results

Phase 1

We have MitM Rx only. Figure 13 shows a representation of the streams versus time. The width of each bar is proportional to stream size.

Figure 13: Test Results – Phase 1 (MitM Rx Only) – Stream activity over time with bar width indicating relative stream size.

Figure 14 shows each block of 20 streams issued at a 100 µs period. It’s the same result, zoomed in on one period.

Figure 14: Test Results – Phase 1 (Zoomed View) – Zoomed‑in view of one 100 µs period showing a block of 20 received streams issued sequentially.

We expect 4 µs between two consecutive streams’ start time.

Figure 15 shows a subset of the data during Phase 1. We compute the mean of the period of each stream, standard deviation (s) and variance (s²) of the period. Here, we see only data from the MAC source 00:2F:80:17:29:68—the frames generator is not yet running.

Figure 15: Test Results Phase 1 subset: per‑stream period stats (mean, σ, σ²) for MAC 00:2F:80:17:29:68; frame generator off.

Another interesting measurement is the time between two consecutive streams. Figure 16 shows a graph of periods joined together. We expect 4 µs.

Figure 16: Test Results Phase 1: inter‑stream time with periods joined, ~4 µs between consecutive streams.

Phase 2

During this phase, we have traffic on both MitM Rx and the frames generator. In Figure 17, we can see the different streams from different sources of traffic.

Figure 17: Test Results – Phase 2 – Streams over time showing concurrent MitM Rx traffic and frame generator traffic from multiple sources.

The plain bars’ plots are the ones from the MitM Rx (MAC source is: 00:2F:80:17:29:68). The other ones (not plain) are the ones from the injection (frames generator), MAC source is: 00:2F:80:11:25:34.The traffic coming from MitM Rx has priority over the injection traffic. So, if both MitM Rx and injection have frames, then the frames from MitM Rx have a priority.

Injection traffic could affect the MitM Rx traffic timing in an example situation such as: in the mixer, when there is no frame from MitM Rx to be sent but a frame from injection to be sent, then injection frame is sent. If during injection from MitM Rx is available, then its emission is going to be delayed in time. We can see that if we look at the inter-stream time during that phase. As a reminder, in theory, it’s 4 µs.

Figure 18: Test Results – Phase 2 Inter‑Stream Timing – Inter‑stream time showing delayed MitM Rx frames when injection traffic occupies the mixer, despite MitM Rx having priority.

If we look at the streams’ statistics during the test and the mean(s) is still at 100 µs, we can also see the effect on timing when looking at standard deviation(s) (compared to Phase 1).

Figure 19: Test Results – Phase 2 Stream Statistics – Mean stream period remains at 100 µs, while increased standard deviation highlights timing variability introduced by concurrent injection traffic.

Phase 3

During this phase, we only have traffic from the frames generator. MAC source is 00:2F:80:11:25:34.

Figure 20: Test Results – Phase 3 – Stream activity over time showing only frame‑generator traffic from MAC 00:2F:80:11:25:34.

Following the overview of Phase 3 traffic, we now zoom in on a smaller time window to highlight the temporal distribution of individual frame‑generator streams when no MitM Rx traffic is present.

Figure 21: Test Results – Phase 3 (Zoomed View) – Zoomed‑in view of frame‑generator streams over time, showing consistent stream spacing without MitM Rx interference.

In addition to time‑domain visualizations, inter‑frame statistics provide further insight into timing behavior when only frame‑generator traffic is present, confirming stable transmission intervals and low jitter in the absence of MitM Rx interference.

Figure 22: Test Results – Phase 3 Inter‑Frame Statistics – Per‑stream inter‑frame timing metrics for injection‑only traffic during Phase 3.

Overall

To conclude, we aggregate statistics across all phases to evaluate overall throughput and timing stability across all streams.

Figure 23: Overall Test Statistics – Aggregate results showing 1,200,000 total frames captured, corresponding to 30,000 frames per stream.

Finally, we examine the global inter‑stream timing across the entire test to compare system behavior in phases with active MitM receive traffic (Phase 1 and Phase 2) versus phases with injection‑only traffic, highlighting how concurrent sources influence overall timing characteristics.

Figure 24: Global inter‑stream time plot showing a flat ~4 µs interval during Phase 1 and increased timing variation during Phase 2, with no inter‑stream data visible for injection‑only Phase 3.

• Learn about automotive Ethernet testing
• Discover the NI PXI-based validation platforms
• Explore the NI Vehicle Communication Toolkit
• See ECU Testing with NI PXIe-8520 and NI PXIe-8523
• Understand HIL Testing for Automotive Systems