This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I have a tcp capture - it appears to be completely duplicate. In other words, the client sends a SYN followed by a second SYN within a different frame 206/207, same time stamp in both frames, TSVal is same for both frames. The SYN, ACK is frames 212, 213 ( for 206, 207 ) Frame 214 ACK's frame 206 Frame 215 Dup ACK's (frame) 214#1

This duplication process continues for the conversation. It appears the TCP conversation is occurring twice on the same socket. The second conversation seems to be marked as 'DUP' all the way through.alt text

I added two screen shot- it seems the upload truncated the img This continues for the entire 100 meg transfer..

Thanks in advance for assistance jim alt text

asked 22 Jan '16, 12:22

JimSax's gravatar image

JimSax
1111
accept rate: 0%

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?

(22 Jan '16, 12:59) sindy

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.

(23 Jan '16, 03:18) JimSax

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 <dup window=""> values with large tracefiles can result in very long processing times for editcap.
(23 Jan '16, 04:01) Christian_R

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 reacting to the same packet in parallel (leaving aside many other things which would have to go wrong to that it could happen).

So I stay with my assumption that it is a capturing issue.

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.

(23 Jan '16, 04:57) sindy

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.

Follow the editcap hint @Christian_R gave you and deduplicate your file - you'll see editcap drops the duplicates and your trace looks much better.

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")

(23 Jan '16, 07:26) Jasper ♦♦

Well, I agree that "wrong" is only an appropriate word with regard to a particular goal of the capture, not in general.

@Jasper'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 this question.

In both these cases, the fact that frames exist which have not 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.

(23 Jan '16, 08:31) sindy
showing 5 of 7 show 2 more comments
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×41
×1

question asked: 22 Jan '16, 12:22

question was seen: 1,917 times

last updated: 23 Jan '16, 09:06

p​o​w​e​r​e​d by O​S​Q​A