 | 1 | initial version |
Doing this from a screenshot is suboptimal at best, especially without packet numbers, but let's try. If I get it wrong I'm sure @SYN-bit and @Packet_vlad will correct me :-)
One thing is easy: packet #12 has a higher sequence number than packets #14 and #15, so there's a gap before it and that leads to the symptom "previous segment not captured".
This also makes both #14 and #15 either a retransmission or out-of-order, because they both should have arrived before #12 (and still #14 before #15). Wireshark has some logic to determine if a packet arriving late is a retransmission or just switched places during travel across the network. Basically it tries to determine if the sender could have known that a packet was lost or not, and that's depending on the initial round trip time (iRTT). We don't know the RTT here because it's just a screenshot, so it's either that 14 and 15 arrived faster than iRTT, or arrived within a couple of milliseconds after where they should have arrived.
So no, 1st concern assumption is not correct. #14 coming before #13 is not the problem. Both #14 and #15 should have arrived before #12.
2nd concern: the symptom in #12 means both #14 and #15, not just #15. Wireshark sees that a sequence number in #12 is higher than what's expected, so it states "previous segment not captured", which may be a bit misleading in this case - it should be "previous segment(s) not captured")
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
