Ask Your Question

TCP Previous segment not captured, Ignored Unknown Record

asked 2022-12-09 15:36:56 +0000

stk gravatar image

updated 2022-12-09 15:56:08 +0000


I have some trouble with a MFD doing scan to mail. It stoopped working from one day to another.

As far as I can see, there is a problem with the TLS 1.2 handshake. It always shows "TCP Previous segment not captured, Ignored unkown record" (Packet 2755).

I uploaded the trace here

I am not sure whether I unterstood that properly. Normally there shoul be a "Server Hello" and it´s not captured, because something went wrong. Is that right?

Does anybody have an idea, why that happens?

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2022-12-09 23:40:29 +0000

SYN-bit gravatar image

Interesting trace with quite a few things going on.

  • The trace was made near or on the client (, 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==, 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==

  • 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==, 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 ...

edit flag offensive delete link more


Thanks for the deep analysis, which helped me a lot to understand that capture and that I was on the wrong foot expecting TLS is the problem. To be honest I don´t think, I can solving it as the firewall guys from the client will take care about that issue now.

stk gravatar imagestk ( 2022-12-13 16:46:33 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2022-12-09 15:36:56 +0000

Seen: 5,181 times

Last updated: Dec 09 '22