Home

/

Knowledge Base

/

Wireshark Filter for Port 13400 and DoIP Traffic

Knowledge Base

Last Updated: 2026-07-02

Wireshark Filter for Port 13400 and DoIP Traffic

Port 13400 is the default destination engineers look for when narrowing Wireshark captures down to Diagnostic over IP traffic.

What to Filter First

Start with tcp.port == 13400 || udp.port == 13400 to isolate the core DoIP traffic lanes before inspecting individual payload types.

Once the transport stream is isolated, focus on routing activation, vehicle identification, and UDS request or response sequences rather than scanning the full capture blindly.

Useful Follow-Up Checks

After transport filtering, check whether the capture shows vehicle announcement traffic, routing activation, and then the diagnostic requests that matter to your failure point.

If the flow jumps between multiple source addresses or sessions, separate the tester-to-gateway path from ECU-specific traffic before drawing conclusions.

Why This Still Gets Messy

Raw packet views still require manual stitching across timing gaps, retransmissions, and mixed session traffic.

That is the point where a structured analyzer becomes more efficient than handcrafted filters alone.

When to Stop Filtering and Start Parsing

If you already know the port but still cannot tell which request triggered the failure, the bottleneck is no longer filtering. It is session reconstruction.

That is the handoff point where uploading the original capture is faster than building more custom Wireshark display rules.

Capture-Backed Evidence

These examples are drawn from real capture files available in the project evidence pool. They give the article something stronger than generic protocol theory.

Connection opens, routing activates, then the session is closed anyway

Vehicle identified, then VCI disconnects immediately

Evidence reference: EVID-PORT13400-VCI-DISCONNECT-01

Node roles in this case

  • tester: the external diagnostic client
  • gateway: the vehicle-side DoIP entry point

A compact field capture where the transport setup succeeds but the session is still lost immediately afterward.

Evidence signals

  • 1 Routing Activation Request (0x0005) and 1 Routing Activation Response (0x0006) were observed on TCP 13400.
  • Only 2 UDS diagnostic payloads followed before the TCP session closed with a bidirectional FIN exchange.
  • This is a strong example of why filtering by port alone does not prove the diagnostic session stayed healthy.

Timeline

  • Packet 1231: the tester sends a Routing Activation Request to the gateway on TCP 13400.
  • Packet 1233: the gateway responds with a Routing Activation Response, so the DoIP path does open.
  • Packets 1243-1244: both sides issue FIN and the connection ends less than half a second later.

For the Wireshark port-13400 search intent, this is the exact moment where port filtering stops being enough and state reconstruction begins.

Common Misreads

These are the interpretation traps that real packet evidence helps avoid.

  • Seeing traffic on TCP 13400 does not mean the diagnostic path remained stable after routing activation.
  • A clean Routing Activation Response does not guarantee that the following UDS exchange completed.
  • A short capture with only one or two UDS frames after activation is not a successful session. It is usually an interrupted session.

Related Diagnostic Guides

Use nearby guides to move from protocol filtering to root-cause troubleshooting without leaving the knowledge base.

How to Diagnose UDS NRC 0x31 Request Out Of RangeHow to Read UDS NRC 0x78 Response Pending TimeoutsBMW DoIP Routing Activation Request Troubleshooting

Frequently Asked Questions

What Wireshark filter should I use for DoIP?

Start with tcp.port == 13400 || udp.port == 13400. That isolates the default DoIP transport lanes before deeper payload inspection.

Why is port filtering not enough on its own?

Because the real bottleneck is usually reconstructing session order, identifying the failing request, and separating overlapping exchanges.

Upload a raw pcap and isolate DoIP traffic automatically

Best for engineers who already know the port but still cannot reconstruct the failing exchange.

Browse all seeded guides