TCP - Overlapping Retransmission
Hey folks,
Happy new year 2021. I hope it started well for all of you.
I've found an (for me) unusual behavior in one of the captures in this forum, and I want to ask if anybody can explain me what this behaviour is related to. The behaviour has nothing to do with the issue itself. That's why I started a new question.
The user had an issue with a connection from a client (192.168.0.1) to a web server (10.10.10.1). The TCP handshake was successfull but after some data packets the ACKs from the client seems to be blocked on the way to the server. My question is about the retransmisson in packet #12. It's an retransmission of the last packet from the server (#8), which contained 1144 bytes payload. But due to the sequence number the retransmission packet has been filled up with additional payload of packet #7 to reach the full MSS of 1460 bytes. Is this a expected behavior for any type of TCP functionality? I've never seen this before.
Jas Man
Is there another site this capture file can be shared that doesn't require a login?
Ooops, sorry. My fault. The link should work now without a login.
OK, that seems to be
tcp.stream eq 12from the test dell knet.pcapng capture file attached to the Dell Knet issue question, although it looks like the IP addresses have been randomized and a snaplen applied so reassembly is no longer possible. I noticed that too, but couldn't make any sense of it.The retransmission in Frame 12 is really curious because it implies to me that there was an ACK received for only part of the TCP segment sent in Frame 7. Frame 7's TCP SEQ # is 2921 and 1460 bytes were sent, so the next expected SEQ # is 4381; yet Frame 12's TCP SEQ # is 4065, meaning that 1144 bytes of the Frame 7 data was ACK'd, which is ... odd.
Now Frame 8 does contain 1144 bytes, which is curious, but the SEQ # is 4381, which is already past the SEQ # of ...(more)
Yep, this is the stream from the named capture. I've anonymized it because it's not my capture/data and I've removed the payload because I think it's not important for my question. I guess the frame #4 is the last one that has been received by the server, because the server start from the beginning in frame #15 (TCP SEQ = #1). Means that the server didn't get an ACK for any of the send data and so he thinks that all frames since frame #5 have been lost during the transmission to the client. Also the server ACKs the TCP SEQ #518 in all of his following packets, even though the client has sent some more data in frame #11. As I mentioned in my question, I don't think that the connection issue is the root cause of the overlapping retransmission in frame #12 ...(more)
Odd indeed. Haven't see anything like this. could there be any "smart device" in between source adn dest, that tampers with the packets? Just a wild guess....