I am receiving 2 following tcp packets:
9000 → 34967 [PSH, ACK] Seq=803864717 Ack=348117840 Win=28960 Len=28 TSval=863760043 TSecr=0
9000 → 34967 [ACK] Seq=803864717 Ack=348117840 Win=28960 Len=0 TSval=863760043 TSecr=0
Why does this happen? How can this not be considered a retransmission?
Only data packets can be retransmissions and the second packet does not contain data, so it can't be a retransmission. But it is interesting to see why this packet was sent, as there is no reason for it to be sent. It ACKs the same data as the previous packet ACKed.
One possible explanation would be that the packets switched order underway. Then the second packet (which was sent first) was a bare ACK and the first packet (which was sent second) is new data. Could you check the ip.id of the packets? Or post a pcap of these packets with about 10 previous packets and the next 10 packets of these two packets somewhere to have a look at?
Glad my hunch was right!
If possible, could you send me the pcap (anonimized, see the link in my answer) of the whole TCP session? I use these kind of examples in my trainings and they are hard to reproduce. My email is [email protected] :-)
Adding an expert info is complicated because RFC 6864 officially says not to analyze it that way https://datatracker.ietf.org/doc/html... "The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly." So performing sequence number analysis on it perhaps is not appropriate by default, even if in practice it can be helpful.
Asked: 2024-06-04 05:49:26 +0000
Seen: 261 times
Last updated: Jun 04
