5

Occasionally, I'll need to compare packet captures (usually wireshark or tcpdump) that are collected from both sides of a TCP conversation. Sometimes the two hosts involved are very "chatty" so I'll need to narrow down the capture to just a specific session.

I'll usually do this by looking in the details column of wireshark for something that looks familiar, right-clicking on that packet, and selecting Follow TCP Stream. That's all well and good, but how can I find the same equivalent stream in the other packet capture? Does WireShark support searching for a stream ID of some sort?

Mike B
  • 11,871
  • 42
  • 107
  • 168

2 Answers2

3

Statistics, Conversations seems very similar to what you want, there you can do "Apply as filter" to the streams in there.

If you know the stream index number you can put in the filter: tcp.stream eq 5

You should check out ask.wireshark.org where I found:

How does Wireshark calculate the TCP stream index?

How can I view stream lists

PersianGulf
  • 602
  • 8
  • 21
gm3dmo
  • 10,057
  • 1
  • 42
  • 36
  • 2
    (I.e., Wireshark *does* support searching for a stream ID, but there is no guarantee whatsoever that the stream ID for a given TCP conversation in one capture will be the same as the stream ID for that conversation in another capture, as there are no stream IDs in TCP, just endpoint identifiers - IP address and TCP port. So you'll have to use Statistics -> Conversations to find the conversations in both captures, and then display them separately.) –  May 24 '15 at 00:20
2

Assuming you're using TCP, the source port is usually unique enough for tracing in known periods. I would load the first capture in Wireshark, then go to File -> Merge to get both ends of the trace to be listed next to each other. Ensure "Merge packets chronologically" is selected.

Then find one of the packets that looks interesting. Depending on the direction, the unique source port or destination port will probably be between 49152 to 65535.

Then in the filter box in the main screen, type tcp.port == 49152, where 49152 is your unique port.

Alastair McCormack
  • 2,184
  • 1
  • 15
  • 22
  • I think the TCP analysis performed by Wireshark is going to get very confused when every packet is seen twice in the capture. And if you haven't gotten clocks "perfectly" synchronized between client and server the packets could still end up being shown out of order. Even if you manage to get the packets in an order that honors causality, I think it may be tricky to keep track of when you are looking at a packet which was sent and when you are looking at a packet which was received. – kasperd May 27 '15 at 08:59
  • I agree, it's not very neat but it does work – Alastair McCormack May 27 '15 at 12:07