Unnecessary ACK in closing TCP connection

Question

I was learning about the process of closing TCP connection and the process differs in many sources I've come across. In official Cisco cert guide (100-105) the process is as follows:

1) ACK, FIN ---->
2)          <---- ACK
3)          <---- ACK, FIN
4) ACK      ---->

I just don't see the purpose of ACK in 3) as there is already an acknowledgement in 2). Also, in older Cisco study materials, the process goes without 2) as well.

On top of that, I have this WireShark capture that made me even more confused:

Basically the same thing, what is the extra ACK in packet #38 for? Acknowledgement was already sent in #37. And both also have the same Ack number.

Could someone give me a little insight if all those are possible in certain situations or which one is correct?

score 3 · Accepted Answer · answered Jul 07 '16 at 13:37

The ACK flag is set when the acknowledgment number is valid. It is therefore set on all packets in a TCP flow except for the initial SYN packet, so by the time you are sending FINs, all packets will be ACKs. You don't need to worry abut it.

An acknowledgement isn't a one-time thing, subsequent packets will all acknowledge the same data if no more has been received (by the end that sends the ACK). This works in both directions.

score 0 · Answer 2 · edited Apr 13 '17 at 12:57

The TCP Close sequence is actually:

1)      FIN ---->
2)          <---- ACK
3)          <---- FIN
4)      ACK ---->

Just like in the TCP Initiating sequence, there are four events happening. One side indicates they are done sending data with the FIN, the other side acknowledges reception of the FIN. Then when the other side is done sending data (often right after, but it doesn't have to be) it sends its own FIN, and the first side acknowledges it.

Often, #2 and #3 are combined in the same packet.

Also, often the FIN in #1 is also accompanied by an ACK to acknowledge reception of the last received data from the other side.

You are seeing this in your packet capture as well:

Packet 38 is the initial FIN
Packet 39 is the responding ACK and the other side's FIN
Packet 40 is the final ACK.

Notice, packet 39 took care of both steps 2 and 3 in the sequence above.

What is odd about your capture is the duplicated ACK. Notice the ACK in packet 37 and packet 38 are acknowledging data sent prior using acknowledgement# 22951. Looking at just those 5 packets, I am not sure why this would be. I did see a ~5s delay between packet 37 and 38, and am wondering if that plays into it somehow.

Unnecessary ACK in closing TCP connection

2 Answers2