everything appears twice

edit

You can upload the image (even better the capture itself) to a file sharing site, e.g. Google Drive, DropBox and post a link to it by editing your question.

We have these restrictions because of spammers.

Graham, I could try to upload the capture. But I am a little concerned that it will show my sites actual IP and thus open my site to nasty stuff. If I upload an image, I can erase my IP address. Also, I did upload my image to photoBucket and then tried to ctrl-v the link to it in my post, but it would not work.

To anonymize a capture see TraceWrangler.

I loaded up TraceWrangler but honestly don't know how to use it. Before I kill myself trying to get that going I am hoping that someone could comment on my problem and confirm my thought that it is NOT a Wireshark issue. I am sending an XOR buffer from my client browser to my server. I am running Wireshark on the client. As I explained already, I am seeing two of the exact same buffer going out from the client to the server. But when I look at the Chrome Debugger Network tab, I am only seeing one copy of the buffer. But in Wireshark I see two of them. And I also see the server responding back with two Acks. What I don't get is the discrepency between the Chrome Debugger and Wireshark.

It's likely to be something in your capture setup as Wireshark won't just "invent" packets. Can you describe your capture setup and how you start the capture in Wireshark?

It is not very sophisticated. I bring up Wireshark (on the client), press the fin in the upper left corner to start it. I then bring up my Chrome extension within the Chrome browser by Inspecting the popup. I then login my app (which seems to work fine). I then bring up the survey popup, fill in the data and press submit. This causes a send of a json buffer. It is this json buffer that appears twice to Wireshark (running on the client). It would seem that the client is sending it twice, but the chrome debugger only shows it going out once. That is the problem; wireshark sees it twice and chrome debugger network tab only sees it once.

Unfortunately I think the answer lies in the capture.

What do you mean by that? Are you saying that the capture is accurate and the chrome debugger is not? That is fine, BTW, I just need to know where to look.

@richb201 Drop the image on a site like imgur.com, then paste the link to the image here. It's not that difficult.

Thanks Jaap. Here it is. As you can see, at some point everything appears twice ie Client hello, the ack, server hello, etc. Even my HTTP POST appears twice. The issue is that when I look at the Chrome debugger, I only see one POST to Logger_survey, not two.

https://imgur.com/IH4bTZm

And here is a shot of the chrome debugger showing that it is only being sent once! https://imgur.com/0SsBYJO

As is usual, solving issues via screenshot is difficult and frustrating because it's the info in the capture that we can't see that's important. I'd like to see the packet details for frames 26 & 27.

You can see that the two SYN's for those frames are sent from different ports, 49814 & 49815 respectively, which implies that 2 connections are being made.

BTW, please stop posting comments as "Answers".

Thanks Graham, I will try to get the capture posted. I loaded tracewrangler and did annonimize it. Other that Google drive, is there someway to share it?

On the two ports "thing" I did see some mention somewhere that TCP keeps a second copy at port n-1, just in case the real port fails. But I would have hoped that it would have waited for the 200ms timeout while waiting for the ack before sending it. Or that the server would realize that it already got that same buffer and ignore it.

OK. Let me know if you can't see this. https://drive.google.com/file/d/1ylXj...

I don't know why you can't see the http in this? They are definately visible in the original.

That anonymised capture is accessible. It allows to play around with it, like @grahamb suggested.

Try this when you have the original capture loaded: Apply the display filter tcp.port==49814 and study the result. Then set apply the display filter tcp.port==49815 and study that result. Does that make the situation more clear?

Downloaded OK. Looks as though your TW session has erased all the data of the TCP payload, that's why http isn't showing up.

Anyway I can see that the 2 SYN packets are sent on the same interface, on different ports, the second after a delay of 1.1 ms. This reveals a fundamental limit of Wireshark, it show you WHAT happened, but can't tell you WHY.

What is the browser and OS on the client?

Thx. What is strange is that it is not just the http that is being sent twice. It happens also before I send the http. Can you see the two client hellos at 33. 11.791580, or the two identical Encrypted Alerts at num 17 and 18? Btw, earlier in the sequence, I am sending an earlier post which works perfectly. I wonder if I am just leaving the interface in a bad state before I get to the current post? The browser is chrome extension under Windows 7 and the server is linux.

Unfortunately your anonymised capture doesn't have the tcp payload data for any of the frames so we can't tell what the messages are, but 17 & 18 do go in different directions, 17 is 125.78.142.254 -> 10.216.21.110, 18 is the reverse.

The two frames you note as "Client Hellos", which I think are 33 & 34, are sent on the 2 different streams, source ports 49814 and 49815 respectively, i.e. they are part of the multiple streams that commence with the SYNs in frames 26 & 27.

As you're on Windows, you could try Message Analyzer from MS that will also tell you the process that sent the packets.

Thx Graham. I installed Message Analyzer, but honestly I am not an expert in reading TCP packets so, I going to the library right now to pick up Practical Packet Analysis to see if I can figure out what is going on. If I can't figure it out, I will modify the php app to expect 2 packets and just send back a Null message on the 2nd one. Thanks for your help, btw.