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

I host a couple of sites dealing with many file uploads/downloads. Every now and then I see failures in my log files, for reasons I only wish I knew. My visitors are mostly anonymous to me, but today I managed to capture one failed download with tcpdump and I'm asking for help understanding it better.

The client (67.189.6.55) was a modern version of Firefox, downloads list showed the files as "Failed".

The capture is available at http://www.cloudshark.org/captures/238c31c13426

What conclusions can be drawn from how the attached stream ends?

No.     Time        Source         Destination   Protocol Length Info
  1 0.000000    67.189.6.55    148.251.25.18 TCP  66     62330 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
  2 0.000062    148.251.25.18  67.189.6.55   TCP  66     http > 62330 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=128
  3 0.234566    67.189.6.55    148.251.25.18 TCP  60     62330 > http [ACK] Seq=1 Ack=1 Win=65700 Len=0
  4 0.251202    67.189.6.55    148.251.25.18 HTTP 612    GET /download?o=abee26401673422e8cc6b066aed9c1ba HTTP/1.1 
  5 0.251266    148.251.25.18  67.189.6.55   TCP  54     http > 62330 [ACK] Seq=1 Ack=559 Win=15744 Len=0
  6 0.302918    148.251.25.18  67.189.6.55   TCP  1514   [TCP segment of a reassembled PDU]
 --8<--
 16 0.499921    67.189.6.55    148.251.25.18 TCP  60     62330 > http [ACK] Seq=559 Ack=11681 Win=64240 Len=0
 17 0.500034    148.251.25.18  67.189.6.55   TCP  1510   [TCP segment of a reassembled PDU]
 --8<--
 24 0.505703    67.189.6.55    148.251.25.18 TCP  60     62330 > http [ACK] Seq=559 Ack=14601 Win=61320 Len=0
 25 0.506461    148.251.25.18  67.189.6.55   TCP  1514   [TCP segment of a reassembled PDU]
 --8<--
 30 0.511704    67.189.6.55    148.251.25.18 TCP  60     [TCP Window Update] 62330 > http [ACK] Seq=559 Ack=14601 Win=65700 Len=0
 31 0.523490    67.189.6.55    148.251.25.18 TCP  60     62330 > http [RST, ACK] Seq=559 Ack=14601 Win=0 Len=0

In my Tomcat logs this manifests itself as

Caused by: java.net.SocketException: Connection reset
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:159)

asked 04 Jan '14, 18:45

llehtinen's gravatar image

llehtinen
11113
accept rate: 0%

edited 04 Jan '14, 18:59


This looks like a client problem. For some reason it sends ACK packets only a couple of times, mostly packet 16 for packets up to packet 13, and then it gets strange - because in packet 24 it acknowledges packet 15, and does the same ACK again in packet 30. After that in packet 31 a Reset is sent. Clearly the client seems to be confused :-)

permanent link

answered 06 Jan '14, 03:07

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Jasper, I noticed #15 with psh bit set, it should mean like "hey, 67. guy, please took off all of those bytes, give me an Ack, and i will give you next chunks of data". But #16 only acks #13 rather than 15, under such condition, is 148. allowed to send additional bytes? Is it a standard behavior? Maybe I mis-undertood the psh bit here.

Could you help me to understand psh bit more precisely?

(06 Jan '14, 18:07) SteveZhou

I referred to rfc1122 page 83, which states that the discussion in rfc-793 erroneously implies that a received PSH flag must be passed to the app layer. Passing a received PSH flag to the app layer is now OPTIONAL.

(06 Jan '14, 18:42) SteveZhou
1

The PSH bit is a notification to process the segment immediately when sending and receiving it, which means that no "waiting for more segments" mechanism is allowed (well, let's say "waiting/buffering SHOULD not happen"). It does not mean that there may not be more data sent afterwards, it only means "process this right away".

A PSH bit also means that the data should be passed towards the application layer on the receiving side immediately (as you quoted), but it may not mean that the TCP stack has to acknowledge it right away. RFCs are one thing, reality is often something else :-)

(07 Jan '14, 00:02) Jasper ♦♦

(Not sure if I was correct, just for your reference. Looking forward experts' input later)

Your web server was doing its job well on file transfer until the client reset the TCP connection. Nothing wrong on tcp side as I can see, it must be a purely application level issue. Live application debugging would be needed to figure out the reason of TCP reset.

permanent link

answered 05 Jan '14, 00:44

SteveZhou's gravatar image

SteveZhou
191273034
accept rate: 0%

edited 05 Jan '14, 03:29

I have to overturn my previous conclusion. This is definitely a server side problem! Apparently, this client is just one of the example to the issue log found on your server, isn't it? It cannot be every client was having problem.

I reviewed the trace again and found that #17's tcp length = 1456 which is bigger than the negotiated value 1460 during handshaking. And after that, #24 and #30 only acked #15 as Jasper mentioned. There must be some problem after receiving the weird length packet on the client, and this caused the client send out an reset to end the connection.

You should take a look at the web server to figure out why it would send out weird length tcp segment. Maybe a NIC card driver issue.

(06 Jan '14, 08:23) SteveZhou
Your answer
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:

×293
×81
×36

question asked: 04 Jan '14, 18:45

question was seen: 6,086 times

last updated: 07 Jan '14, 00:02

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