4

I have two captures: a sender side capture file and a receiver side capture file.

When I applied the tcp.analysis.lost_segment filter at sender side, I didn't see any frame popping up. When I applied the same at receiver end and saw the black highlighted columns matching the description as "Expert Info (Warn/Sequence): Previous segment not captured (common at capture start)".

  1. Who knows first (sender or receiver) that the packet is lost?
  2. Scrolling at the sender side. I do see frames highlighted in black with info as, "This is a TCP duplicate ACK." Is this a lost packet? But this frame is different from the one at the receiver saying, "prev seg not captured."
  3. Which capture file should be used to identity the lost packet?
  • 4
    Welcome to NE, we hope you will both contribute to and learn from this community. You could improve your question by editing it to add more details. You may find our Question Checklist helpful when editing your question. For example it would be very useful to be able to view the captures you are referencing. A great place to share your packet captures would be CloudShark. – YLearn Nov 4 '15 at 22:49
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 12 '17 at 20:38
2

Actually, in networking you never know if a packet got lost or not if you are only watching the end-points. This is due to the fact that you cannot distinguish between a lost packet (dropped by router or even corrupted on the link layer) and a extremely delayed transmission (packet is still on the wire or in a queue but is not processed).

A TCP duplicate ACK indicates: You received an acknowledgement from the server but it gives the same sequence number that the last ACK had. This means that an intermediate packet is lost (as the receiver ACKed the number twice) or extremely delay. But as you have received another ACK (the duplicate ACK) this means that the network path is not completely congested. Consequently, if you get multiple ACKs in a row, you can assume that the ACKed packet is lost as the other packets come through. Many TCP implementations then do what is called a Fast Retransmit, so that they don't wait for the retransmit timeout but instead resend the first unacked packet. This also has some implications regarding the congestion window.

The message "Expert Info (Warn/Sequence): Previous segment not captured (common at capture start)" means the following: On the receiver side you capture an outgoing ACK packet for a sequence number where you haven't seen the respective segment. This is common, as it might be possible that a segment arrived, you started the capture and afterwards your TCP stack replied with an ACK. So there was no way to see the incoming packet. This does not necessarily indicate a loss.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.