Retransmitted packet breaks TCP sequence
Troubleshooting a case where a packet is re-transmitted but the re-transmitted packet has a different size than the original one. The client keeps ACKing for the original packet but eventually tears the connection down because it never gets it. Anyone seen this behavior or a clue of what could be causing this? The server is a vmWare VM.
Size of packet is not a factor when determining if it is a retransmission:
https://www.wireshark.org/docs/wsug_h...
https://code.wireshark.org/review/git...
Frame 31 contains three pieces of TLS data, the first which matches the data in frame 20.
Right. There were 3 data segments sent:
The receiver is still ACK'ing 2050 (relative seq #), so the sender sends all 282 bytes starting from seq=2050, although I'm not sure why all 282 bytes need to be sent considering the receiver has sent the SACK 2125-2203 option in Frame 28 indicating that it only needs the 75 bytes from 2050 through 2124. So are SACK's causing the problem? We don't have the TCP 3-way handshake to know whether SACK's are even permitted or not.
Yes, SACKs are enabled at both endpoints. Will try to upload the whole conversation shortly.
If the problem is repeatable, you could try disabling SACKs, just to see if that makes any difference.