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

Greetings sniffer warriors,

I have a strange TCP retransmission recovery error on an HTTPs exchange and I don't know who the culprit is, the client or the server.

All goes well (handshake, crypto, some data), then the client sends a TCP Zero Window with an ACK of a PARTIAL sequence. For example simply to illustrate, server sending:

[1-100 ] Seq 100

[101-200] Seq 200

[201-300] Seq 300

[301-400] Seq 400

At some point after this, the client sends: TCP Zero Window, ACK 263 (right smack somewhere in the middle of packet Seq 300)

It does that a few times, then sends a window size update, followed with a regular "ACK 263". The server doesn't seem to know how to send this "mid packet" 263 segment, so it restarts by sending segment 300. The client sends what is interpreted by Wireshark as Dup Acks, still for 263 and the server keeps sending packet Seq 300. After all the previous in-flights die, the trace shows that back and forth behavior packet by packet. Ack 263 ->, <- Seq 300. Eventually a RST kills all this off.

One wrinkle: SACK_PERM is not enabled. This is not something I control so I'm concentrating on explaining the behavior we see.

Question: Who's at fault?

TCP Zero Window and Update is a normal process, but is it normal / ok for the client to request that the server resume at a point that is not at the boundary of a previously sent packet?

If yes, is it the server's fault for not providing a retransmission starting at the requested sequence position rather than on a previous packet border?

Would Selective ACK help in this recovery process?

Thank you :)

asked 15 Feb '17, 06:07

Delstar's gravatar image

accept rate: 0%

Hello Delstar

and welcome to I agree with you, that the zero window and window update is the root cause. The server should either send the last frame (with Seq 200) or restart with Seq 263.

Selective acknowledgements would allow the receiver to signal just the missing bytes.

Is it possible, that you have a device between sender and receiver, that modifies the TCP stream? The device might be transparent. Potential culprits are bandwidth management systems, WAN optimizers or misbehaving firewalls.

By the way, is either the sender or the receiver a virtual system?

Good hunting

permanent link

answered 15 Feb '17, 11:54

packethunter's gravatar image

accept rate: 8%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 15 Feb '17, 06:07

question was seen: 1,413 times

last updated: 15 Feb '17, 11:54

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