conntrack full with TIME_WAIT on tcp passive close site

[Vladimir Ondrus]

Hi,

We have a setup with many tcp connections, which are after short time
activelly closed from remote site.
However we have our nf_conntrack table full with connections in TIME_WAIT state.
Output from netstat shows no connection in TIME_WAIT state, which we
think is correct, because we are passive close site, so connection
should not go through TIME_WAIT state.

Why tcp connection in conntrack table goes through TIME_WAIT, even we
are pasive close site in tcp?

Regards,
Vladimir Ondrus

suf-ins:~ # uname -a
Linux suf-ins 3.0.58-0.6.6-default #1 SMP Tue Feb 19 11:07:00 UTC 2013
(1576ecd) x86_64 x86_64 x86_64 GNU/Linux
suf-ins:~ # lsmod | grep conntrack
nf_conntrack_ipv4 14856 4 iptable_nat,nf_nat
nf_conntrack 91963 4 xt_state,iptable_nat,nf_nat,
nf_conntrack_ipv4
nf_defrag_ipv4 12729 1 nf_conntrack_ipv4
suf-ins:~ # modinfo nf_conntrack
filename:
/lib/modules/3.0.58-0.6.6-default/kernel/net/netfilter/nf_conntrack.ko
license: GPL
srcversion: BAAB16A923443DCF4CD66A3
depends:
supported: yes
vermagic: 3.0.58-0.6.6-default SMP mod_unload modversions
parm: tstamp:Enable connection tracking flow timestamping. (bool)
parm: acct:Enable connection tracking flow accounting. (bool)
parm: expect_hashsize:uint
suf-ins:~ #
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jozsef Kadlecsik]

Post by Vladimir Ondrus
We have a setup with many tcp connections, which are after short time
activelly closed from remote site. However we have our nf_conntrack
table full with connections in TIME_WAIT state. Output from netstat
shows no connection in TIME_WAIT state, which we think is correct,
because we are passive close site, so connection should not go through
TIME_WAIT state.
Why tcp connection in conntrack table goes through TIME_WAIT, even we
are pasive close site in tcp?

Conntrack reflects the state of the communicating party which sent the
last packet, processed by conntrack. In this case it's in the TIME_WAIT
state.

Best regards,
Jozsef
-
E-mail : ***@blackhole.kfki.hu, ***@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Vladimir Ondrus]

Hi,

lets have an example
1.
###
# server
###
suf-pgw:~ # netcat -l -p 10001


###
# client
###
suf-ins:/tmp/vlado # netcat 219.1.90.101 10001
^C punt!


2.Client close TCP session
###
# server
###
suf-pgw:~ # netstat -n | grep 10001
suf-pgw:~ # cat /proc/1/net/nf_conntrack | grep 10001
ipv4 2 tcp 6 104 TIME_WAIT src=219.1.90.100 dst=219.1.90.101
sport=59410 dport=10001 packets=4 bytes=216 src=219.1.90.101
dst=219.1.90.100 sport=10001 dport=59410 packets=2 bytes=112 [ASSURED]
mark=0 zone=0 use=2
suf-pgw:~ #

###
# client
###
suf-ins:/tmp/vlado # netstat -n | grep 10001
tcp 0 0 219.1.90.100:59410 219.1.90.101:10001 TIME_WAIT
suf-ins:/tmp/vlado # cat /proc/1/net/nf_conntrack | grep 10001
ipv4 2 tcp 6 88 TIME_WAIT src=219.1.90.100 dst=219.1.90.101
sport=59410 dport=10001 packets=4 bytes=216 src=219.1.90.101
dst=219.1.90.100 sport=10001 dport=59410 packets=2 bytes=112 [ASSURED]
mark=0 zone=0 use=2
suf-ins:/tmp/vlado #

Kernel tcp stack has TIME_WAIT only on client side -> output from netstat
Why conntrack has TIME_WAIT state on both sides ? -> nf_conntrack listing

Regards,
Vladimir Ondrus

Post by Jozsef Kadlecsik

Post by Vladimir Ondrus
We have a setup with many tcp connections, which are after short time
activelly closed from remote site. However we have our nf_conntrack
table full with connections in TIME_WAIT state. Output from netstat
shows no connection in TIME_WAIT state, which we think is correct,
because we are passive close site, so connection should not go through
TIME_WAIT state.
Why tcp connection in conntrack table goes through TIME_WAIT, even we
are pasive close site in tcp?

Conntrack reflects the state of the communicating party which sent the
last packet, processed by conntrack. In this case it's in the TIME_WAIT
state.
Best regards,
Jozsef
-
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungar

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Vladimir Ondrus]

Conntrack "sits" between the two communicating parties. It has no
knowledge that one of it is the same machine it's running on.

Best regards,
Jozsef
-
E-mail : ***@blackhole.kfki.hu, ***@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html