I was wandering if anyone came across the same TCP traffic behaviour. I have filtered my packet captures on specific TCP conversation and after downloading it into Wireshark can see following:
There are some lost packets which are followed by ‘TCP previous segment lost packets’ (TCP packet arrives with a sequence number greater than the "next expected sequence number’) however they are never retransmitted.
The peer doesn’t send either TCP duplicated ACKs requesting retransmission of the lost packets.
I believed that in TCP connection needs to ACK every single packets and lost packet will always be retransmitted.
Could anyone please advise.
‘TCP previous segment lost packets’ is a wireshark intrepretation of the packet sequence number.
It could be wireshark/winpcap/libpcap which did not succeed to capture ALL packets.
It is not mandatory to ACK every packet.
You ack the next expected sequence number.
E.g, if multiple packets come quickly, you ack only the last one (if they come in the good order and there is no lost packets).
On application level there has been reported loss of couple of messages. I am not sure if the messages were lost/not generated on apllication level before they were encapsulated in TCP packets. There is no unique ID of the message on which I could trace in which TCP packet this message has been transported over the network. I have been looking in this traffic for any symptoms of packets drops but here I am not sure what is happening. Additionally, this lost segment packets are happenign all the time , even when application is not loosing any messages.
Before, everytime I have seen packet drops/discards there were TCP Duplicated ACKs/ Retransmissions/ Fast retransmissions.
Please see below example from traffic captures:
1.Packet from X host: TCP: Seq number:9493, Next Seq number:9750, ACK number:1 (257)
2.Packet from X host: TCP: Seq number:9750, Next Seq number:9989, ACK number:1 (239)
3.Packet from X host: TCP: Seq number:11437, Next Seq number:12885, ACK number:1 (flaged by Wireshark as a: Previous Segemnt lost; here I would expect to see packet with Seq number 9989) (1448)
4.Packet from Y host: TCP: Seq number:1, ACK number: 9989(Y host is saying I would like to receive now packet with Seq no 9989; please not that this is not duplicated ACK)
5.Packet from X host: TCP: Seq number:12885, Next Seq number:13205, ACK number:1 (320)
packet from Y host: TCP: Seq number:1, ACK number: 12885 (if the packet 9989 was lost , here I would expect to see Dup ACK with ACK number of 9989 - which would be request of retransmission this packet intead we have ACK:12885)
The packets seems to be coming in right order.
I think that Wireshark is decoding correctla as I looked into original packet captures decoded by Netscout and examine same packet as abovesent from X host.
Packet from X host: TCP: Seq number: 2135860316
Packet from X host: TCP: Seq number: 2135860573 (257)
3.Packet from X host: TCP: Seq number: 2135862260 (1687) - this packet was 1448 Bytes long (1687 - 1448 = 239 bytes are missing) - this is the same what Wireshark has decoded. There has been lost packet worth of 239 bytes
Netscouts are usually very good in capturing traffic and it would be first time that I see that the Netscout is not manging to to copy all traffic from a switchport espacially that traffic volumes were not high.
When wireshark looses packets during capture, it is supposed to be displayed into status bar (“Dropped: XXX”).
Idem for tcpdump, there is a print at the end.
1st sequence
Is it possible that Y host is sending packet 4 at the same time that X host is sending packet 3 ?
I did not understand what is exactly the 2nd sequence ?
Same sequence captured at another place ?
Try also Wireshark-users mailing list (wireshark.org/lists/).
If your capture is not sensitive, you can provide it to the Wireshark-users mailing list.