4

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:

Wireshark capture of TCP termination

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?

3

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.

| improve this answer | |
0

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:

Same packet capture as above

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.