Retransmitted packet breaks TCP sequence

asked 2020-03-21 20:13:30 +0000

naskop gravatar image

updated 2020-03-24 18:23:41 +0000

cmaynard gravatar image

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.




edit retag flag offensive close merge delete


Size of packet is not a factor when determining if it is a retransmission:

 /* If there were >=2 duplicate ACKs in the reverse direction
  * (there might be duplicate acks missing from the trace)
  * and if this sequence number matches those ACKs
  * and if the packet occurs within 20ms of the last
  * duplicate ack
  * then this is a fast retransmission

Frame 31 contains three pieces of TLS data, the first which matches the data in frame 20.

bubbasnmp gravatar imagebubbasnmp ( 2020-03-21 21:27:32 +0000 )edit

Right. There were 3 data segments sent:

  • Frame 20: 75 bytes
  • Frame 27: 78 bytes
  • Frame 29: 129 bytes Total: 75 + 78 + 129 = 282

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.

cmaynard gravatar imagecmaynard ( 2020-03-24 18:53:36 +0000 )edit

Yes, SACKs are enabled at both endpoints. Will try to upload the whole conversation shortly.

naskop gravatar imagenaskop ( 2020-03-24 19:19:22 +0000 )edit

If the problem is repeatable, you could try disabling SACKs, just to see if that makes any difference.

cmaynard gravatar imagecmaynard ( 2020-03-24 19:34:25 +0000 )edit