I hope someone here can help. I have seen a strange problem where our server seems to be retransmitting the segment prior to the one being requested by the Duplicate ACKs sent by the client.
The Duplicate ACK is requesting re-transmission: Acknowledgement number: 422281 (relative ack number)
Sometimes I see an ICMP packet being sent by the server after receipt of the Duplicate ACK, usually in response to the first five of these Duplicate ACKs, but can be later as well, in this particular case the last five received too :
Then the server retransmit sends the previous sequence:
This continues until the conversation peters out after about a minute. Has anyone seen anything like this before?
asked 25 Jun '12, 04:46
Where did you capture? I guess at the client side. Do you have verified the behavior by capturing on the server side as well? I suspect there's a firewall or similar device with ACLs in the communication path between client and server (the ICMP administratively prohibited indicates a "reject" rule existing somewhere).
If there is a firewall you need to verify first that the server actually gets the same TCP details that the client sent. A firewall might modify the TCP header in flight so that the server does not actually get the ACK numbers the client sent. Maybe it even removes the SACK options for whatever reason. So you need to make sure that the server sends data from before the last ACK number by verifying that behavior as close to the server as possible (but please not by capturing on the server itself, because that could give funny results, too). Don't forget to inspect and compare the SYN-SYN/ACK sequence at the beginning of the communication on both sides, because you might see that some TCP option negotiation is being influenced as well.
answered 25 Jun '12, 06:09