TCP FIN/Close 3 ACK's

[frankguthrie]

I tried to find this with/on Google but to no avail. 

I have a Ubuntu machine (192.168.0.23) on which I have used tool NPING to connect to cisco.com (104.98.129.232) on port 80 . While doing this I have run a Wireshark trace to see what happens. 

Basically a TCP session is setup up and closed down, no data is send. Thus NPING can determine if the host is listening and accepting traffic.

Opening the TCP session is as expected:

1. SYN

2. SYN, ACK

3. ACK

The TCP Close however shows me something I did not expect

1. FIN, ACK

2. FIN, ACK

3. ACK

The first ACK I can't explain. It seem that it is a duplicate of the last ACK for the 3-way handshake. Looking at the TSval, this seems to be a random number and unique, but the TSecr is identical, so is the Seq(uence), Win(ow) and Len(gth). This believes me to think this is a "duplicate" ACK.

Is this done to identify to which 3-way handshake this belongs? So for the server to know which TCP session to kill?? This is the only logical explanation I can think of. Am I right? If not please explain.

See attached screenshot.

[ADP_89]

Hello,

Hello

The behaviour is the correct one. Every TCP packet(a part from the first SYN) carries the ack flag with the value which points to the last chunk of data that it received from the other end. If there was no data in the middle it doesn't matter,  the other end will understand that this is not a duplicate ack because it receives an incremented sequence.

Section 3.5 diagram of the TCP RFC will show a similar behaviour (the only difference is the condensation of 2 packets in the your second FIN-ACK)

https://www.ietf.org/rfc/rfc793.txt

HTH,

ADP

[frankguthrie]

So I'm right.........no? yes?

The RFC confuses me even more and doesn't give me an answer on my question.......So now there are 4 ACK's in the TCP close.......

The RFC states:

1. FIN, ACK

2. ACK

3. FIN, ACK

4. ACK

So now I'm lost.

[ADP_89]

The difference beetween your capture and the RFC is that packets 2 and 3 that you find on the RFC are actually merged on your capture. It might depend on the system tcp/ip stack. You do not need to worry about if there are 2 packets reporting the same ack number as all TCP packets will do that to keep track of the connection status.

I have tried with a few linux boxes and routers and they all do the same. If I have time I will try with more OSes later..

Cheers,

ADP