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

TCP Retransmission Recovery SNAFU: Who’s at Fault?

0

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

Delstar
6112
accept rate: 0%


One Answer:

0

Hello Delstar

and welcome to ask.wireshark.org. 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

answered 15 Feb '17, 11:54

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%