Capture evidence
A PCAP preserves packets, timestamps, and headers from an observation interval. Its completeness and timing information determine what can be concluded about the reported problem.
Vehicle Networks & Communication
Wireshark Analysis Guide
A practical engineering guide to inspecting PCAP data, decoding Automotive Ethernet traffic, and isolating DoIP or SOME/IP communication failures.
Engineering model
How Wireshark fits together
Wireshark analysis connects observed vehicle-network behavior to packet-level evidence. The engineer works from timestamps, headers, protocol exchanges, and the problem description to determine whether communication was absent, malformed, delayed, or progressing only partially. In this scope, analysis depends on a usable PCAP, correct protocol interpretation, and a clear comparison between observed behavior and the expected diagnostic or service-oriented exchange.
Core concepts
The parts of a practical Wireshark setup
Protocol decoding
Wireshark translates captured traffic into protocol fields that can be inspected rather than treating the capture as an undifferentiated byte stream. Correct decoding is necessary before interpreting an exchange.
DoIP exchange state
DoIP analysis follows diagnostic discovery, routing activation, and subsequent TCP communication as separate stages. This separation helps identify where a connection failure begins.
Service-oriented traffic
SOME/IP traffic is analyzed as communication between services over Automotive Ethernet. Packet order, timing, and decoded fields help distinguish missing traffic from an exchange that is present but inconsistent.
What Wireshark analysis can establish
The useful output is not a packet list by itself, but a bounded engineering finding supported by capture evidence.
Start with the problem description: what was observed, when it occurred, how it was reproduced, and what behavior was expected. Then map those claims to the PCAP. Wireshark can show whether relevant traffic exists, when it appears, how packets are ordered, and which decoded fields differ between an unsuccessful and a successful exchange when both are available.
- Presence: determine whether the expected Automotive Ethernet, DoIP, or SOME/IP traffic appears at all.
- Sequence: inspect whether the observed packets follow the expected progression for the exchange being investigated.
- Timing: use packet timestamps to identify gaps, delayed responses, or repeated attempts.
- Content: inspect decoded headers and fields for values that do not match the problem description or the comparison capture.
- Scope: distinguish evidence in the PCAP from behavior that the capture does not contain.
Prepare the PCAP and problem description
Analysis quality depends on preserving context before interpreting individual packets.
- 01
Define the event window
Record the reproduction steps, the expected behavior, and the approximate interval in which the failure occurred. Use this context to focus the capture without discarding surrounding packets prematurely.
- 02
Check capture continuity
Inspect timestamps and packet progression for gaps or abrupt starts and stops. Note whether the PCAP appears to cover the complete exchange or only one segment of it.
- 03
Identify the traffic of interest
Separate Automotive Ethernet traffic relevant to the reported behavior from unrelated packets. For DoIP, look for diagnostic discovery, routing activation, and TCP communication; for SOME/IP, identify the service-oriented exchange under investigation.
- 04
Preserve the original evidence
Keep the original PCAP unchanged and perform interpretation on a working copy or documented view. Record the capture conditions and the problem description alongside any extracted findings.
Read Automotive Ethernet traffic in layers
Interpret packets from transport and timing evidence toward application meaning rather than jumping directly to a presumed root cause.
First establish that the Automotive Ethernet traffic relevant to the event is present in the PCAP. Next inspect the packet sequence and timestamps. Only after that should you interpret DoIP or SOME/IP fields. This order prevents a decoded application field from being treated as the cause when the preceding communication was never established or when the capture is incomplete.
| Analysis view | Evidence to inspect | Engineering question |
|---|---|---|
| Capture continuity | Timestamps and packet progression | Does the PCAP cover the interval in which the behavior was reproduced? |
| Network traffic | Automotive Ethernet packets and headers | Is traffic present between the expected participants during the event? |
| Protocol exchange | Decoded DoIP or SOME/IP fields and packet order | Which stage of the exchange was reached? |
| Failure boundary | Last relevant packet and following time gap | Where does expected communication stop or change? |
- Use timestamps to describe ordering and delay without assuming that a delay alone proves a cause.
- Treat decoded values as evidence tied to a specific packet and exchange stage.
- Compare repeated attempts when available; consistent failure boundaries are stronger evidence than a single anomalous packet.
- Keep packet-level findings separate from conclusions about behavior outside the capture.
Analyze DoIP connection failures
DoIP connection failure analysis is most effective when discovery, routing activation, and TCP communication are treated as distinct checkpoints.
- 01
Check diagnostic discovery
Determine whether the PCAP contains the discovery traffic expected for the attempted DoIP connection. If it is absent, record that the capture does not show the discovery stage rather than inferring why it was absent.
- 02
Check routing activation
Inspect whether routing activation is attempted and whether the exchange progresses beyond that point. Compare the request and response sequence, decoded fields, and timestamps.
- 03
Check TCP communication
If the exchange reaches TCP communication, inspect packet order, timing, and whether communication continues after routing activation. Identify the last observed packet before the failure boundary.
- 04
State the bounded finding
Describe the earliest stage that is not evidenced or does not progress as expected. Separate that observation from hypotheses about network configuration or endpoint behavior unless the PCAP supports them.
| DoIP stage | What to verify | Possible bounded finding |
|---|---|---|
| Diagnostic discovery | Relevant discovery traffic is present and ordered | Discovery is not evidenced in the captured interval, or the exchange reaches the next stage. |
| Routing activation | An attempt and its response are visible | Routing activation is not evidenced, does not receive an observed response, or progresses further. |
| TCP communication | Packets continue after the preceding stage | TCP communication is not evidenced or stops after a specific observed packet. |
Inspect SOME/IP communication
SOME/IP analysis focuses on whether service-oriented traffic is present, ordered, and consistent with the reported behavior.
Begin by locating the relevant SOME/IP packets within the Automotive Ethernet traffic. Follow the exchange through its observed sequence and use timestamps to identify missing responses, unexpected pauses, or repeated requests. The useful finding is usually a relationship between a request or announcement, the packets that follow, and the point at which the expected exchange no longer continues.
- Confirm that the relevant SOME/IP traffic is present during the reproduction window.
- Group packets by the service-oriented exchange being investigated rather than reviewing isolated packets only.
- Compare packet order and timing across repeated attempts when the PCAP contains more than one attempt.
- Record decoded fields that differ between expected and observed exchanges, while retaining the packet timestamp and sequence context.
- Avoid treating a missing packet as conclusive when the capture point may not observe both sides of the communication.
Turn observations into an engineering analysis
A useful analysis preserves the path from the reported symptom to the evidence and then to a carefully bounded finding.
- 01
Restate the observed symptom
Use the problem description to define the failure condition, reproduction context, and expected behavior without adding assumptions.
- 02
List the relevant evidence
Reference the PCAP observations by exchange stage, packet sequence, and timestamps. Include both present traffic and important gaps.
- 03
Locate the failure boundary
Identify the last stage or packet that is clearly evidenced and the first expected behavior that is not observed.
- 04
Separate findings from hypotheses
Label directly observed facts separately from possible explanations. A plausible explanation should remain qualified when the PCAP cannot distinguish among alternatives.
- 05
Document the next comparison
State what additional capture context or repeatable comparison would reduce uncertainty, without claiming that the current PCAP proves more than it does.
For a root-cause report, preserve the evidence chain: problem description, capture scope, decoded exchange, timing observations, failure boundary, and confidence or remaining uncertainty. This makes the report reviewable and prevents a protocol symptom from being mistaken for a confirmed underlying cause.
Practical analysis patterns
The following patterns help organize recurring observations without turning them into unsupported diagnoses.
| Observed pattern | What it establishes | What remains uncertain |
|---|---|---|
| No relevant traffic in the event window | The PCAP does not evidence the expected exchange | Whether traffic was absent at the system or outside the capture scope |
| Discovery is visible but routing activation is not progressed | The connection reaches or approaches the discovery stage before the observed boundary | Why routing activation did not progress |
| Routing activation is visible and later TCP communication stops | The capture evidences progress beyond routing activation and a later communication boundary | Whether the cause is endpoint behavior, network behavior, or capture scope |
| Repeated SOME/IP requests have no observed response | The repeated attempts are not followed by a response in the PCAP | Whether the response was not generated, not transmitted, or not captured |
Engineering pitfalls
Common mistakes
Starting with a presumed root cause
Engineers may begin by blaming a network gateway or endpoint before locating the first failed exchange stage. The correct approach is to establish the observed sequence and failure boundary first.
Ignoring capture scope
A missing packet is sometimes treated as proof that no packet was sent. Capture point, interval, and continuity must be checked before making that claim.
Conflating DoIP stages
Discovery, routing activation, and TCP communication are often described as one connection event. Treating them separately makes the earliest unsupported stage visible.
Reading packets without timestamps
Packet content alone can hide delays, gaps, and repeated attempts. Timestamps are part of the evidence and should be retained in findings.
Overstating decoded fields
A decoded field can be reported as an observation, but it does not automatically explain the system behavior. Interpret it in sequence and protocol context.
Changing the original evidence
Filtering or modifying working data without preserving the original PCAP can make later review difficult. Retain the source capture and document the analysis view used.
FAQ
Wireshark questions
- What should be checked first in a Wireshark PCAP?
- Check the capture interval, timestamp continuity, and whether the traffic relevant to the problem description is present. Then follow the exchange in order before interpreting individual decoded fields.
- How can Wireshark help with a DoIP connection failure?
- It can show whether diagnostic discovery, routing activation, and TCP communication are evidenced, how the packets are ordered, and where the observed exchange stops progressing.
- Does missing traffic prove that a packet was never sent?
- No. Missing traffic may reflect capture scope, capture timing, or an incomplete PCAP. State that the packet is not evidenced in the capture unless the observation conditions support a stronger conclusion.
- How should SOME/IP traffic be analyzed?
- Locate the relevant service-oriented exchange, inspect packet order and timestamps, compare repeated attempts when available, and document the first point where the expected exchange is no longer observed.
- What makes a Wireshark analysis suitable for a root-cause report?
- It should connect the problem description to preserved PCAP evidence, identify the observed failure boundary, distinguish findings from hypotheses, and state remaining uncertainty instead of overstating what the capture proves.
Engineering support
Discuss a Wireshark Project
Need focused packet-level analysis? Provide the PCAP and problem description for a structured engineering analysis of Automotive Ethernet, DoIP, or SOME/IP behavior.