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

Server stops reading TCP stream after it sends a TCP Window update

0

Hello all,

we have very strange behaviour with our web application. When certain clients do a HTTP POST request to our JBOSS 4.2 application server (running behind an apache), they sometimes(!) never get a reply from the server. In all these cases, the wireshark dumpfile shows that a TCP Window Update is sent from server to client while the client sends the POST data. The server then sends consecutively a lot more of these window updates (which are markes as TCP DUP ACK in wireshark), and the client tries to do multiple retransmits of the POST data. But it never gets an ACK from the server. This goes on until the retransmission times out and the client sends a RST.

Here are example dumps of one TCP stream for this bahaviour:

http://www.cloudshark.org/captures/0c9860e1507b

http://www.cloudshark.org/captures/18eff2081f27

Thanks for any help.

Markus

asked 22 Jan '14, 07:16

msh's gravatar image

msh
11114
accept rate: 100%

edited 22 Jan '14, 08:07


3 Answers:

0

Thanks for your help. We now found a setting that solves the problem. In our Apache Webserver, KeepAlive was turned off. It seems that certain browsers (newer Firefox browsers and their forks like Iceweasel) have problems with this setting when running on certain operating systems (Linux Mint, Debian Wheezy, Mac OS X...). Other browsers or Firefox on Windows work fine anyway.

When KeepAlive is turned on, the problem disappears. Still have no explanation for this, maybe a bug in the Firefox client? But at least we could fix it.

answered 07 Feb '14, 00:13

msh's gravatar image

msh
11114
accept rate: 100%

1

Looking at the timestamp options all packets after the three-way-handshake come in with a 'wrong' fixed TS_echo . There must be some proxy between the client and the server that is intercepting your tcp segments after the 3-way handshake and exchanges (messes up) - at least - the timestamps in the tcp options. It might be the 4s+ delay between the 3-way-HS and the POSt request that is making this fail...

As to the MSS, the client adheres to the offering of 1380 and never sends segments larger than 1368 alt text

answered 23 Jan '14, 11:00

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

0

Um, did you see that the client sends a FIN flag in its first packet after the three way handshake is complete? That is kind of a "Hello, Nevermind" behavior from the client. I am pretty sure that you can stop looking at any packet after packet 4, because basically the client declares the conversation over in packet 4. DUP Acks, Window update etc. have no meaning. You need to find out why the client establishes the session only to finish it instantly. This is not a server problem.

answered 22 Jan '14, 07:59

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Jasper, thank you for the quick answer. However, there are other examples where no FIN flag is set: http://www.cloudshark.org/captures/0c9860e1507b

Thank you for any more ideas or help

(22 Jan '14, 08:07) msh

Ok, the second trace is different. Here the server never gets anything after the Three Way Handshake, it keeps ACKing the initial SYN packet. From the timings I deduct you capture very close (or even on) the client. You now need to do a simultaneous capture at client and server to see why the client packets never get acknowledged. My guess is that they never arrive at the server.

The most common cause for the behavior in your trace is an MTU problem: small packets (Three Way Handshake) get through okay, while large packets don't. Often, routers are configured not to send "ICMP destination unreachable - fragmentation needed" to protect themselves from DoS attacks, so you do not even get a notice back that the packets are too large.

My advice: figure out if the client receives the packets at all, and reconfigure the client to stop using the TCP timestamp option, which wastes a lot of bytes but doesn't help in most situations.

Edited: I was wrong about the MSS being ignored, so I removed that part to avoid spreading wrong information. @mrEEde did it right when saying it never exceeds 1380. Obviously my math was bad last night :-)

(22 Jan '14, 08:17) Jasper ♦♦