This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP Previous segment lost - Bug?

0

Hi, I've come along some strange behavior of Wireshark. During a couple of captures, a lot of warnings appeared saying [TCP Previous segment lost]. Normally, this could occur is packets get lost or something, but you would suspect that the missing packets would be retransmitted some time later on (after the number of bytes in the send window are send and the first (missing) packet is not acknowledged by that time). Looking in the capture file I see the following (exported to CSV to make it clear text):

1611    21.736.504  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] 445 > 1641 [ACK] Seq=1387288 Ack=7262 Win=65535 Len=1380    1387288 1380    1388668 
1612    21.736.620  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] 445 > 1641 [ACK] Seq=1388668 Ack=7262 Win=65535 Len=1380    1388668 1380    1390048 
1613    21.736.718  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1361068 Win=65535 Len=0   7262    0   7262    
1614    21.736.769  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] 445 > 1641 [ACK] Seq=1390048 Ack=7262 Win=65535 Len=1380    1390048 1380    1391428 
1615    21.736.877  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] 445 > 1641 [ACK] Seq=1391428 Ack=7262 Win=65535 Len=1380    1391428 1380    1392808 
1616    21.736.992  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] 445 > 1641 [ACK] Seq=1392808 Ack=7262 Win=65535 Len=1380    1392808 1380    1394188 
1617    21.737.116  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] [TCP Previous segment lost] 445 > 1641 [ACK] Seq=1396948 Ack=7262 Win=65535 Len=1380    1396948 1380    1398328 
1618    21.737.232  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] [TCP Previous segment lost] 445 > 1641 [ACK] Seq=1403848 Ack=7262 Win=65535 Len=1380    1403848 1380    1405228 
1619    21.737.349  10.98.18.127    10.74.37.2  TCP 445 1641    [Continuation to #1590] [TCP Previous segment lost] 445 > 1641 [ACK] Seq=1413508 Ack=7262 Win=65535 Len=1380    1413508 1380    1414888 
1620    21.737.889  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1373488 Win=65535 Len=0   7262    0   7262    12
1621    21.737.891  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1376248 Win=65535 Len=0   7262    0   7262    14
1622    21.737.894  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1380388 Win=65535 Len=0   7262    0   7262    17
1623    21.737.896  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1384528 Win=65535 Len=0   7262    0   7262    20
1624    21.737.897  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1388668 Win=65535 Len=0   7262    0   7262    23
1625    21.737.899  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1392808 Win=65535 Len=0   7262    0   7262    27
1626    21.737.903  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1396948 Win=65535 Len=0   7262    0   7262    29
1627    21.737.904  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1401088 Win=65535 Len=0   7262    0   7262    ?
1628    21.738.779  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1405228 Win=65535 Len=0   7262    0   7262    30
1629    21.738.781  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1407988 Win=65535 Len=0   7262    0   7262    ?
1630    21.738.783  10.74.37.2  10.98.18.127    TCP 1641    445 1641 > 445 [ACK] Seq=7262 Ack=1412128 Win=65535 Len=0   7262    0   7262    ?
1631    21.738.785  10.74.37.2  10.98.18.127    TCP 1641    445 [TCP ACKed lost segment] 1641 > 445 [ACK] Seq=7262 Ack=1416268 Win=65535 Len=0  7262    0   7262    ?
1632    21.738.787  10.74.37.2  10.98.18.127    TCP 1641    445 [TCP ACKed lost segment] 1641 > 445 [ACK] Seq=7262 Ack=1419811 Win=65535 Len=0  7262    0   7262    
1633    21.738.789  10.74.37.2  10.98.18.127    SMB 1641    445 Read AndX Request, FID: 0x400d, 61440 bytes at offset 1413120   
1634    21.739.728  10.98.18.127    10.74.37.2  SMB 445 1641    Read AndX Response, FID: 0x400d, 61440 bytes        

Frame 1616 would suggest that the next sequencenr would be 1394188, but it's 1396948 so indeed it seems like a packet is missing. However, in frame 1627 sequence 1401088 is acknowledges meaning that all bytes before are received correctly. But I cannot find any (re)tranmission of the frame with sequence 1394188 so what's going on here? Is this a bug in Wireshark?

Hope someone can answer this for me

asked 07 Jan '11, 03:00

lutetia's gravatar image

lutetia
1112
accept rate: 0%

edited 07 Jan '11, 03:06

Is wireshark showing any packet drops on capture? Also are you using a teaming NIC that might be load-balancing (and some packets are travelling across the other physical NIC)?

(07 Jan '11, 03:36) martyvis

3 Answers:

0

I'm curious if it is possible that either the traffic rate was to fast for Wireshark to deal with or if there was some other path that that packet could have taken. The receiver certainly received 2 frames that would follow 1616 as indicated by the non-duplicate ack's that follow. This looks to me like wireshark some how is not getting all of the packets.

answered 07 Jan '11, 03:28

Paul%20Stewart's gravatar image

Paul Stewart
3018
accept rate: 6%

0

Hi Paul,there was no other path, and I've seen this in five or six captures I've made. I've used a Dell laptop with a 1 Gbps Broadcom network interface on a spawnport of a 3750 Cisco switch, to monitor all traffic on another 1 Gbps link on that switch. In the Capture options I've filtered one IP address to capture (10.74.37.2 in this case). That PC was attached to a 100 Mbps link so it's hard to believe that my laptop couldn't see all traffic from that PC. So to me it looks like some bug in Wireshark.

Regards

John Lasschuit

answered 07 Jan '11, 03:38

lutetia's gravatar image

lutetia
1112
accept rate: 0%

1

If you span 1 Gbit link, you will get both RX and TX frames, resulting in 2 Gbit/s of traffic on a fully utilized link. This will oversubscribe the spanport. Filtering on one specific IP addres takes place on the capturing host after the switch has dropped packets due to the oversubscription. It does not matter that the filtered host only has a 100Mbit, unless you are able to filter before aggregating the two 1 Gbit/s flows to a 1 Gbit/s port.

You can verify this by checking the counters on the destination span port.

(07 Jan '11, 05:30) SYN-bit ♦♦

Of course it would be easier to span the 100 Mbit/s server port to your 1 Gbit/s monitor port :-)

(07 Jan '11, 05:33) SYN-bit ♦♦

SYNbit, I think you're right. The ports appeared to be configured as fixed 100 Mbps FD (not Gigabit) however, the same you've pointed out applies. Unfortunaly the counters are only five minute intervals so they're gone. On Monday we try to configure the main and span port as auto sensing, hoping that the real port (connection to provider) will come up as 100 Mbps FD and the span port as 1 Gbps FD (because the laptop is 1 Gbps). Let's see if Cisco supports this :-)

(07 Jan '11, 09:24) lutetia

The drop counters don't use 5 min moving weighted average. So if you look the counters, you'll see the drops. This is why I presented a case like this in Sharkfest 2010. It is possible to infer a lot by looking at the traces. Looking at IP ID can help you gather some information etc. But to me, it looks like the span dropped it.

(07 Jan '11, 13:29) hansangb

I agree with and second what hansangb is stating. Those drop counters will not reset or loop every 5 minutes. They may reset when the interface bounces though. It certainly looks like Wireshark does not have a complete view. This is one drawback of aggregating 2 direction traffic into a span port that does not have 2x the output capacity.

(08 Jan '11, 08:48) Paul Stewart

0

Clear the 3750 interface counters and then do a

"show interface counter errors"

to check for drops on the span target port.

answered 10 Jan '11, 06:43

erics's gravatar image

erics
462
accept rate: 0%