This is a static archive of our old Q&A Site. Please post any new questions and answers at

Decoding WireShark Traffic Capture


Hi All,

We are using an ASP application and sometimes the application does not let the user type data in a given field. This issue occurs on different fields and screens of the program. We have opened support tickets with the vendor on this issue and they are claiming the reason the user can't type is because packets are being lost between the client computer and the ASP server.

Using Wireshark, I have captured the network traffic between the client computer and the ASP server when this issue has occurred. Unfortunately, I do no have the knowledge to interrupter the captured data to determine if lost packets are causing an issue.

I have uploaded the capture file to:

Would anyone be will to review the file and render an opinion?



asked 15 Jan '13, 16:36

dwerner's gravatar image

accept rate: 0%

One Answer:


I haven't bothered to look at your capture file because your vendor's explanation is bogus. B-O-G-U-S bogus.

You mention ASP, which means HTTP, which means TCP, which means lost packets get transmitted automatically by the network stack. The stack will try and try and try until it succeeds, and the higher level code never sees any of this. At worst, the ASP level code will see a conversation be truncated if a lost packet is never able to be retransmitted successfully. It won't see lost information.

If someone did examine your capture file, they're not terribly likely to be able to do much with it without being one of the developers of the application in question, or at least having login details so they can play with it from the client side. A raw capture file doesn't have enough information to provide a diagnosis, except by sheerest blind luck.

answered 15 Jan '13, 18:36

Warren%20Young's gravatar image

Warren Young
accept rate: 0%

Hi Warren,

Thanks for your response.

I highly suspected you are correct in your analysis of my situation. I have given the vendor several of our captures files when this issues occurs and they are "reviewing" them. Although I am using to having to jump through hoops to get vendors to address their issues, this particular vendor is particular vexing in blaming all our issues on network performance. I had no decision authority in picking or remaining with this vendor, but if they are offering an ASP program, I would think their program should account for various network performance issues.

Thanks again,


(16 Jan '13, 09:04) dwerner

Re "thanks": On a site like this, upvotes are better than "thanks," particularly to one such as me, with 16 whole points so far. :)

Re "network performance": Your vendor may well be right, that your network is crap. It may even be losing packets. My only point is that lost packets aren't going to result in corrupted conversations, due to data missing from the middle of a transmission. TCP takes care of that. But, bad network performance can still cause application problems. If this is what's going on, your vendor would just need a more intelligent explanation than "lost packets".

(16 Jan '13, 16:19) Warren Young