[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.