[Bug 49] TCP conntrack entries with huge timeouts

bugzilla-daemon@netfilter.org bugzilla-daemon@netfilter.org
Sat, 15 Feb 2003 20:32:25 +0100


https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=49

korn-netfilterbugs@chardonnay.math.bme.hu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|other                       |Debian GNU/Linux



------- Additional Comments From korn-netfilterbugs@chardonnay.math.bme.hu  2003-02-15 20:32 -------
I'm also experiencing the problem.

Running the following command produces lots of conntrack entries with huge timeouts:

#!/bin/sh

ulimit -n 8192
ulimit -c unlimited
ulimit -s unlimited

nmap --max_parallelism 10 -oM /tmp/xdmcp.log -sU -p 177 some-subnet.1-253

The interesting thing is that this produces ESTABLISHED but UNREPLIED
connections with nonexistent boxes, like for example:

tcp      6 431983 ESTABLISHED src=192.168.0.1 dst=192.168.0.23 sport=43465
dport=80 [UNREPLIED] src=192.168.0.23 dst=192.168.0.1 sport=80 dport=43465 use=1

192.168.0.23 doesn't exist on the network, so I certainly can't have established
a TCP session with it. The timeout is about 5 days, so I guess it's the normal
timeout for established TCP sessions. I'm just compiling a new kernel  with a
lower timeout to test this.

On a different box, I see lots of connections like these:

tcp      6 109291 CLOSE_WAIT src=foo.63 dst=some-ip.144 sport=2465 dport=4000
src=some-ip.144 dst=foo.63 sport=4000 dport=2465 use=1 

The timeout of about 30 hours doesn't resemble anything I've seen in
ip_conntrack_proto_tcp.c. (tcp port 4000 is a listening port on some-ip.144, so
this was an incoming connection.)

Or let's look at this one:

tcp      6 19038066 CLOSE src=foo.26 dst=some-ip.144 sport=20933 dport=40768
[UNREPLIED] src=some-ip.144 dst=foo.26 sport=40768 dport=20933 use=1 

Not bad, a whopping 220+ days! I wonder how that came to be...?

Both kernels are 2.4.20-wolk4.0s-pre10 (which include most of the iptables
patch-o-matic). I removed Jozsef Kadlecsik's connection tracking enhancement
patch from the kernel on the first box; otherwise, everything is identical.

Andrew



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.