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, CLOSEDAnd these from the receiving (passive) side:ESTABLISHED, CLOSE-WAIT, LAST-ACK, CLOSEDNow 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 testI 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.1tcp      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=2tcp      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=2root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1tcp      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=2tcp      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=2So 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.1tcp      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=2tcp      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=2root@machine2:~# cat /proc/net/ip_conntrack | grep 10.0.0.1tcp      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=2tcp      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
Why TCP TIME-WAIT State is present at both ends after a connection termination?
linux;networking;linux kernel;tcp;protocols
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