Analyzing TCP Connection Issues: Unexpected TCP Keep-Alive After Four-Way Handshake

Background

This case comes from a group member’s sharing, asking about TCP Connection issues, reflecting that after completing the FIN interaction, the TCP connection is not closed normally. It looks strange, and it is also an uncommon case. Let’s share a brief analysis.

Problem Information

The screenshot information of the question is as follows

At first glance, it seems to be just as described in the problem. After No.8 – 10 completed four TCP handshakes, No.11 – 13 interactive data packets were still generated, as if the TCP connection was not closed normally.

The brief information of the trace file provided is as follows. There is no other special warning information except for the expert TCP Keep-Aliveinformation .TCP ZeroWindow

λ capinfos test.pcapng
File name:           test.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   13
File size:           1996 bytes
Data size:           1059 bytes
Capture duration:    4.542063 seconds
First packet time:   2022-03-17 14:51:32.055157
Last packet time:    2022-03-17 14:51:36.597220
Data byte rate:      233 bytes/s
Data bit rate:       1865 bits/s
Average packet size: 81.46 bytes
Average packet rate: 2 packets/s
Strict time order:   True
Capture hardware:    Intel(R) xxx
Capture oper-sys:    64-bit Windows 7 xxx
Capture application: Dumpcap (Wireshark) 3.4.12 (v3.4.12-0-g398502390084)
Number of interfaces in file: 1
Interface #0 info:
                     Name = \Device\NPF_{xxx}
                     Description = 本地连接
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Time resolution = 0x06
                     Operating system = 64-bit Windows 7 xxx
                     Number of stat entries = 1
                     Number of packets = 13
Number of resolved IPv4 addresses in file: 2

λ

Problem Analysis

First, we analyze the No.8-10 packets by expanding the TCP Seq, Next Seq, and ACK. We can confirm that it is a standard TCP four-wave process, which is completely normal.

Next is packet No.11 TCP Keep-Alive. Why does Wireshark judge this ACK as a TCP Keep-Alive packet? It is mainly based on the following rules.

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and none of SYN, FIN, or RST are set.

Compared with No.9, No.11 has a Seq Num of 150, which is exactly one byte smaller than No.9 Next Seq 151. In addition, other conditions are also met, so it is marked as a TCP Keep-Alive packet.

But after the TCP four handshakes seem to have been completed, why does the server still send the so-called TCP Keep-Alive data packet to keep the connection alive? Isn’t this a contradiction?

Finally, the No. 12 packet TCP ZeroWindowhas a similar reason and is judged based on the following rules

Set when the receive window size is zero and none of SYN, FIN, or RST are set.

The Win of No.12 is obviously 0, and naturally the other conditions are also met, so it is marked as a TCP ZeroWindow packet.

In summary, No.8 – 12 seem to be a series of interactions between the client and the server. Wireshark also performs relevant analysis and judgment based on the actual data packet fields. So where is the problem? Why does the server have such a weird sending behavior of No.11? Is it its problem?

Let’s expand the fields for a full analysis, add an IP ID column, and look at the packet sorting, where we find the problem.

What’s going on? IP ID 36508 of No.11 is smaller than IP ID 36509 of No.9. Isn’t this out of order? But why doesn’t Wireshark mark it Out-Of-Orderas TCP Keep-Alive instead? Is it a problem with Wireshark?

Of course not in this case. It can only be said that in this very special case, the position of No.11 out of order is very coincidental. The complete rules of TCP Keep-Alive are as follows, that is, when the conditions of TCP Keep-Alive are met, it will replace Out-Of-Order, which means priority.

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and none of SYN, FIN, or RST are set. Supersedes “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.

So the real problem is that the data packets are out of order . The rearranged data packets No.1-11 are as follows, which is the normal interaction process.

The arrival of out-of-order packet No. 11 causes the client in the TIME_WAIT state to reply with an ACK packet with Win=0, and the server naturally responds with RST.

Summary of the problem

Although it is always said that anything can happen in the world of data packets, most of these phenomena still have inevitable reasons for their existence.