Why TCP TIME-WAIT State is present at both ends after a connection termination?

Question

I am reading how the TCP states work and especially the connection termination part.

All of the books or online material I read, shows that for the termination procedure these states are followed from the side initiated (active) the connection termination:

ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, CLOSED

And these from the receiving (passive) side:

ESTABLISHED, CLOSE-WAIT, LAST-ACK, CLOSED

Now here comes the question: I have modprobed the nf_conntrack_ipv4 module to both sides to check the connection states in /proc/net/ip_conntrack.

To my surprise, when the connection is terminated, both the initiator (active) and the receiver (passive) goes to the TIME-WAIT state.

I would expect only the initiator to go through this state, and the receiver just close the connection.

Can someone explain why this is happening?

UPDATE: How do I perform this test

I have a virtual machine with IP 10.0.0.1 (Ubuntu 12.04) and I start two ssh connections to 10.0.0.2 (Debian 6) from it (10.0.0.2 is a VM as well). I check the ip_conntrack of both ends and this is what I get.

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431997 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 431944 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=206 bytes=19191 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=130 bytes=18177 [ASSURED] mark=0 secmark=0 use=2
tcp      6 431947 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=16 bytes=4031 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=17 bytes=3741 [ASSURED] mark=0 secmark=0 use=2

So far everything looks fine. Now I disconnect one of the ssh connections from machine2 and this is what I get:

root@machine1:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 431989 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 [ASSURED] mark=0 use=2
tcp      6 117 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 [ASSURED] mark=0 use=2

root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1
tcp      6 432000 ESTABLISHED src=10.0.0.1 dst=10.0.0.2 sport=53925 dport=22 packets=211 bytes=19547 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53925 packets=133 bytes=18925 [ASSURED] mark=0 secmark=0 use=2
tcp      6 115 TIME_WAIT src=10.0.0.1 dst=10.0.0.2 sport=53924 dport=22 packets=31 bytes=5147 src=10.0.0.2 dst=10.0.0.1 sport=22 dport=53924 packets=25 bytes=4589 [ASSURED] mark=0 secmark=0 use=2

Answer 1

The Linux TCP stack and conntrack have two different visions of the TCP connection. What you're seeing in /proc/net/ip_conntrack is different from what the kernel sees. The kernel state is stored in /proc/net/tcp and /proc/net/tcp6 and can be displayed with netstat.

As seen here: https://serverfault.com/questions/313061/netstat-and-ip-conntrack-connection-count-differ-by-order-of-magnitude-why both counts differ. I presume that if you look at netstat's output you will only see one end in TIME-WAIT

Answer 2

This is to prevent a new connection getting stale segments still floating around in the 'net from the old connection messing it up.