TCP Previous segment not captured, Ignored Unknown Record

edit

Interesting trace with quite a few things going on.

• The trace was made near or on the client (192.168.0.6), as can be seen from the delta times between the SYN and the SYN/ACK and between the SYN/ACK and the ACK of the 3-way-handshake.

• The frame length of 2962 of some of the frames sent by the client confirms this (these large frames are caused by capturing on a host that does TCP segmentation offloading). Jumboframes are not in play as the MSS value in the SYN is 1460.

• The first interesting bit is frame 11, there is TCP data missing, but the id.ip values is one higher that the previous frame from the server. So there seems to be something weird going on on the server side.

• As the server retransmits the missing data, the TLS session is setting up fine. This can be seen by disabling dissection of frame 11 (select the frame and choose "Edit -> Ignore/Unignore packet").

• Things go well for a while where client and server are exchanging data, until frame 41. This frame is not received by the server. When filtering on ip.src==192.168.0.6, you can see that the frame is being retransmitted over and over, but no ACKs are coming back from the server side. Communication to the server side seems lost.

• Communication from the server to the client seems OK. The server is sending TCP KeepAlive packets every 30 seconds (filter on ip.dst==192.168.0.6)

• Looking closer, you can see that frames 41 and 43 were not received by the server, while frames 42 and 44 were received. You can see that in the SACK blocks in frame 49 and 52.

• Filtering again for ip.src==192.168.0.6, it shows that frame 41 and 43 were the first full-size frames sent by the client. All retransmission frames are also full-size frames. This smells like a MTU problem.

• Going back to the first data packets by the server. You can see that between frame 9 and 11, 2896 TCP bytes were not seen. Which are 2 packets with TCP segments of 1448 bytes (MSS=1460, but there are 12 bytes of TCP options, leaving 1448 bytes of data).

• Now it makes sense that the server retransmitted the data and that the TCP segment sizes are now smaller. There was a host in the path between the server and the client that could not forward the frame because of a lower MTU size (usually caused by tunnelling). The new TCP segment length is 1408, which corresponds to an MSS of 1420 and an MTU of 1460 (instead of 1500). I assume it sent an ICMP type 3 code 4 message (Fragmentation needed, but DF bit set) to the server, which triggered the server to send smaller TCP segments.

• The client either did not receive the ICMP type 3 code 4 messages (a lot of firewalls just block any ICMP ...