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

Uploading Issues

0

To whom it may concern, While I am not new to Help Desk work I am relatively new to advanced networking operations such as deciphering Wireshark messages as related to tracking down why errors pop up in applications when uploading files over the internet. If I'm able to, I'm going to attached 3 Wireshark captures to this message. One is from the device that was doing the uploading and the other 2 were from the Cisco ASA firewall's ingress_egress capturing TCP only. These captures were all performed simultaneously, of course, but the added twist is my ASA captures are about 8 minutes fast (sorry about that). The time on the 'Nancy' capture is correct and the specific times the PC was throwing out each error message during the upload were at 2:08 p.m., 2:09 p.m. and 2:14 p.m. Wireshark captures are located at: https://drive.google.com/open?id=0B6yAAiHYJtJSU3phWUl3eFdseDQ

asked 11 Apr '17, 11:22

mahrsmusic's gravatar image

mahrsmusic
4●1●1●3
accept rate: 0%

edited 11 Apr '17, 11:27

One Answer:

1

I've taken the time to answer this one because I think that it might make a nice case study one day.

I can't tell you why but I can tell you what is happening.

There are many HTTPS connections to 52.5.5.205 in this capture. The 7 connections have client port numbers 57519, 57565, 57568, 57580, 57587, 57589 & 57638 and they all have a similar form in the way they terminate. Since they sessions are encrypted, we can't see what the transactions contained or if there were any HTTP error messages within them.

Using the last one, port 57638, as an example, here's what happens:

  1. There is short burst of normal looking activity.
  2. Then there is 21 seconds of inactivity.
  3. The server presumably times out and issues a Final (packet #138287).
  4. The client ACKs (#18288) that Final but doesn't send one of its own.
  5. After a further 9 seconds, the client sends a burst of 64 KB of data, spread across 4 round trips (#139262 - #139359).
  6. The server acknowledges all the data.
  7. The server, however, does not send any response to that data (because it has already closed the connection).
  8. The client then sends its own Final (#139360).

These connections/terminations seem to match the times you mention. Further, they look the same in your other ASA captures.

My suspicion would be that these requests with no response are triggering your error messages.

The questions you might like to find answers to are:

  • Does your server have a timeout setting of around 20-21 seconds?
  • Can that be made longer (as a test)?
  • Why doesn't your client send any data in that 21 seconds?
  • Or, why does the client wait 30 seconds to send its last request.

I note that there was lots and lots of other traffic in your PC trace. Just for fun (other readers might like to test their skills in finding these) here are some other items that I found interesting.

  1. The GoDaddy SSL certificate for "*lifelogics.org" expired on 31-05-03 (May 31 2003?) but the application still accepts it.
  2. In the SMB2 file server connection to 10.10.105.114 there are many accesses to a "thumbs.db" file that is at least 64 MB in size. All the accesses are for 4 KB at a time (as SMB does).
  3. SMB2 traffic to a different file server contains dozens of accesses to "Paris\UPDATES\PixMoveNancy.exe" that fail with "ACCESS_DENIED".

answered 12 Apr '17, 00:05

Philst's gravatar image

Philst
431●1●6●16
accept rate: 27%

Thank you so much! I tried to cast my vote but it's says I'm not able to at this time. AWESOME ANSWER! Thank you again, so much! I've been trying to learn Wireshark for the past 2 weeks (and study for my CCNA, raise 3 kids, etc. etc.). Your help is SO MUCH APPRECIATED!!!!

(27 Apr '17, 16:23) mahrsmusic