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

HTTP connection reset

0

I'm testing some HTTP service for downloading quite big files (above 20MB) because there are problems with it. Using ipfw I set bandwidth throttling to 112Kbit/s, latency to 150ms and packet loss to 10% (all settings set both for incoming and outgoing data).

I'm testing it using OSX Maverics and curl. After some time curl finishes its work with error status: "curl: (56) Recv failure: Operation timed out". whireshark gives me the following log for this conversation.

alt text

I'm not really sure why there is that timeout at all and what causes it. Log doesn't show any long pauses in packet transmission.

Also, sometimes there is some other kind of error reported by curl: "curl: (18) transfer closed with 58153725 bytes remaining to read" (or quite similar to it). Log for this looks quite similar: there is also RST packet out of nowhere sent by client:

alt text

Do you have any ideas what's going on? Thank you very much for your help!

Edit - final packets and their times received and sent by client for each stream:

  • Stream 0: Received packet #7814 - 491s, and then RST, ACK #8054, 531s (tcp.stream == 0 && (tcp.ack == 1562393 || tcp.seq == 1562393))
  • Stream 1: Received packet #5237, 315s, and then RST, ACK #5261, 316s (tcp.stream == 1 && (tcp.ack == 928169 || tcp.seq == 928169))
  • Stream 2: Received packet #7651, 477s, and then RST, ACK #7665, 478s (tcp.stream == 2 && (tcp.ack == 1600041 || tcp.seq == 1600041))
  • Stream 3: Received packet #8918, 666s, and then RST, ACK #8929, 668s (tcp.stream == 3 && (tcp.ack == 2057368 || tcp.seq == 2057368))

asked 24 Dec '14, 06:29

ocher's gravatar image

ocher
11114
accept rate: 0%

edited 26 Dec '14, 03:33

If you can, upload a capture at http://www.cloudshark.org. If you need to sanitize it first, use TraceWrangler at http://www.tracewrangler.com. It's easier to read captures than screenshots ;-)

(24 Dec '14, 06:32) Jasper ♦♦

There you go: https://www.cloudshark.org/captures/a50b03a0e508 I've used tracewrangler.com. There are four connections in that capture. All of them failed, two of them I described above.

(24 Dec '14, 07:02) ocher

One Answer:

2

From a quick look at stream 0 (filter: tcp.stream==0) I'd say this looks like massive (you could also call it "fatal") packet loss to me - to a point where in the end the 1514 byte packets do not get through, so no ACKs come back, and (funny enough) the receiver (not the sender) finally terminates the connection with an RST packet.

My guess is that the final packets (#7814 and later) sent by 241.201.189.2 never get to 22.188.85.155 at all, so it finally runs out of patience and shuts down the connection. The RST has the acknowledge to the sequence number of packet 7813, so we can be quite sure that everything after that packet did not get to its destination.

The whole connection also has a pretty bad initial round trip time of over 310 milliseconds, which indicates that at least some physical or wireless links used for this connection are very slow or unreliable.

answered 24 Dec '14, 15:36

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thank you for the response. There is a very big packet loss, because I added such connection setting deliberately for testing problems with downloads (I described it in my question - ipfw). In case of stream 0 there is, as you pointed out, quite long time between last received packet and an outgoing packet with RST, ACK flags. It's about 40s. But in case of other three streams that time is pretty short (maximum 2 seconds), and still clients sent RST. I wonder why does it happen, why they, as you wrote it, ran out of patience? Is there any other mechanism besides timeouts, when clients may do this?

I've edited my question and I added there times of last incoming and outgoing client packets.

(26 Dec '14, 03:41) ocher

The other (fast) RSTs look more like "normal" session termination - they're too quick to be considered "impatient", and right now I don't see another critical issue which would force this connection abort...

(27 Dec '14, 10:07) Jasper ♦♦

@ocher: what happens if you replace curl with wget?

(27 Dec '14, 12:56) Kurt Knochner ♦

@jasper And do you know any potential causes, besides timeout, when session might be terminated in a scenario when both clients are working properly?

(29 Dec '14, 01:54) ocher

@kurt It's the same with wget. Actually, I had similar problems in a normal brwoser, and then I moved on to curl. Here you can find a capture from my test with wget: https://www.cloudshark.org/captures/7575dee35bf5 And here are some extracted details:

Stream 0: Received packet #4835 - 309s, and then RST, ACK #4934, 316s (tcp.stream == 0 && (tcp.ack == 747169 || tcp.seq == 747169))

Stream 1: No received packet with seq: 1798417, weird - it tries ACK pacekt which is not in the capture! (tcp.stream == 1 && (tcp.ack == 1798417 || tcp.seq == 1798417))

Stream 2: Received packet #10398 - 706s, and then RST, ACK #10410, 707s (tcp.stream == 2 && (tcp.ack == 1836065 || tcp.seq == 1836065))

Stream 3: Received packet #7655 - 518s, and then RST, ACK #7704, 522s (tcp.stream == 3 && (tcp.ack == 1365229 || tcp.seq == 1365229))

These times are very far from 900s which is a default wget timeout. Also, new connections are estabilished in the capture, because wget automatically retries download.

(29 Dec '14, 02:00) ocher

When both clients are working properly there is only the option of tearing down a successful connection the fast way with an RST. All other scenarios I know off involve at least one side doing something wrong.

(29 Dec '14, 03:25) Jasper ♦♦

@jasper Any why that RST might happen in my case? Do you have any ideas?

(30 Dec '14, 01:02) ocher

The only thing coming to mind is that the application holding the socket released it, which would result in a socket close with a RST packet being sent out. Maybe there was an application error/exception which aborted the program, but that is hard to say from here.

(30 Dec '14, 02:36) Jasper ♦♦

Any why that RST might happen in my case? Do you have any ideas?

Maybe some "intelligent monitoring" in the Apple IP stack. Try to use a different OS as client and see what's happening there.

(30 Dec '14, 04:07) Kurt Knochner ♦
showing 5 of 9 show 4 more comments