Duplicate Conversation is same TCP stream?

Seems to me like a wrong setting of monitoring on a switch, can you provide more details on how the capture has been taken? Are the source and destination MAC addresses of the two packets (the original and the duplicate) also the same? Are there any sessions in the same capture which don't show this anomaly?

Sindy, thanks for weighing in, further analysis on my side showed multiple webservers running. I cannot explain this yet, but shutting down one of the webservers removed the duplicate issue. The server is rhel 6 with multiple IP addresses, so a bit more analysis to do here. I cannot say I have ever seen a duplicate conversation such as this.... perplexing, but interesting.

As @sindy already told you, you should find the root cause for this behaviour at least to be able to explain this behaviour for yourself.

If you then need to deduplicate a trace like this you could use editcap with the option -D. Editcap is part of the wireshark distribution. The man page can be found here: https://www.wireshark.org/docs/man-pages/editcap.html

editcap -D dup_window infile outfile
Attempts to remove duplicate packets. The length and MD5 hash of the current packet are compared to the previous dup_window - 1 packets. If a match is found, the current packet is skipped.

The use of the option -D 0 combined with the -v option is useful in that each packet's Packet number, Len and MD5 Hash will be printed to standard out. This verbose output (specifically the MD5 hash strings) can be useful in scripts to identify duplicate packets across trace files.

The dup_window is specified as an integer value between 0 and 1000000 (inclusive).

NOTE: Specifying large &lt;dup window=&quot;&quot;&gt; values with large tracefiles can result in very long processing times for editcap.</code></pre></div><div id="comment-49479-info" class="comment-info"><span class="comment-age">(23 Jan '16, 04:01)</span> <span class="comment-user userinfo">Christian_R</span></div></div><span id="49480"></span><div id="comment-49480" class="comment"><div id="post-49480-score" class="comment-score"></div><div class="comment-text"><p>The explanation with multiple web servers as a cause sounds weak to me at least for one reason: already the SYN packet from the client came twice, and that cannot be a consequence of both webservers <em>reacting</em> to the same packet in parallel (leaving aside many other things which would have to go wrong to that it could happen).</p><p>So I stay with my assumption that it is a capturing issue.</p><p>If you publish the capture somewhere and place a link here, we may find more information (screenshots are useless for any deeper investingation), but still it is interesting to know whether the capture has been taken directly at the server or using another hardware and capture setup.</p></div><div id="comment-49480-info" class="comment-info"><span class="comment-age">(23 Jan '16, 04:57)</span> <span class="comment-user userinfo">sindy</span></div></div><span id="49481"></span><div id="comment-49481" class="comment"><div id="post-49481-score" class="comment-score"></div><div class="comment-text"><p>This looks like a typical case of duplicate packets, which can happen whenever you SPAN more than one source (meaning: when SPANning a link or VLAN that has more than one node in it). So if you SPAN a VLAN you get duplicates whenever two nodes in the VLAN talk to each other. If you SPAN more than one link, the same will happen when the nodes on the SPANned links talk to each other.</p><p>Follow the editcap hint <span>@Christian_R</span> gave you and deduplicate your file - you'll see editcap drops the duplicates and your trace looks much better.</p><p>BTW, it's not a "wrong" capture setting - if the goal of the capture is to capture packets from more than one source on a Switch via SPAN this happens and can't be helped (except in some corner cases, e.g. when you can afford to SPAN a VLAN "source only")</p></div><div id="comment-49481-info" class="comment-info"><span class="comment-age">(23 Jan '16, 07:26)</span> <span class="comment-user userinfo">Jasper ♦♦</span></div></div><span id="49482"></span><div id="comment-49482" class="comment not_top_scorer"><div id="post-49482-score" class="comment-score"></div><div class="comment-text"><p>Well, I agree that "wrong" is only an appropriate word with regard to a particular goal of the capture, not in general.</p><p><span></span><span>@Jasper</span>'s example of SPANning a complete VLAN (means: both ingress and egress direction of each member port of that VLAN) has made me think about another case where "pseudo-duplicate" frames (i.e. pairs of frames which are identical from L3 layer upwards) are inherent, which is capturing of communication between two STAs in a wireless network using monitoring mode. Here, Wireshark would also show duplicated packets as the AP is re-translating packets between the STAs, as discussed in <a href="https://ask.wireshark.org/questions/49145/ap-forward-labeled-as-retransmission">this question</a>.</p><p>In both these cases, the fact that frames exist which have <em>not</em> been duplicated may indicate packet loss. But in case of SPANning, any missing frames in the capture are more likely to be caused by overbooking of the monitoring port's bandwidth rather than by overbooking of bandwidth of one of the traffic ports or even by malfunction of the switch fabric. That said, when SPANning the complete VLAN, a lot of care has to be taken not to make conclusions too fast.</p></div><div id="comment-49482-info" class="comment-info"><span class="comment-age">(23 Jan '16, 08:31)</span> <span class="comment-user userinfo">sindy</span></div></div><span id="49483"></span><div id="comment-49483" class="comment not_top_scorer"><div id="post-49483-score" class="comment-score"></div><div class="comment-text"><p>BTW, this may help, too:</p><p><a href="https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/">https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/</a></p></div><div id="comment-49483-info" class="comment-info"><span class="comment-age">(23 Jan '16, 08:44)</span> <span class="comment-user userinfo">Jasper ♦♦</span></div></div></div><div id="comment-tools-49463" class="comment-tools"><span class="comments-showing"> showing 5 of 7 </span> <a href="#" class="show-all-comments-link">show 2 more comments</a></div><div class="clear"></div><div id="comment-49463-form-container" class="comment-form-container"></div><div class="clear"></div></div></td></tr></tbody></table>