On Thu, May 29, 2003 at 08:09:52AM -0400, Preston A. Elder wrote: > 752_iptables-10_confirm_fix > > Please let me know if you think one is missing I should try. no, the above one is what I was talking about. > > With a non-broken kernel it is 2 minutes, that is TIME_WAIT of a TCP > > socket. > That was not my point. My point was, for up to 5 days later, the > system still has entries in the conntrack table (listed as > 'ESTABLISHED'), which have been dead and gone for a long time, > conntrack does not realise that connection is utterly closed, and it > should drop its conntrack entry. I'm not as worried about the > lower-value timeouts, but as I said, I saw ALOT of established > connections hanging around in the conntrack table (making the > conntrack table about 200,000 entries long, give or take), most of > which were entries for connections already closed. This is exactly the behaviour shown by kernels that have not the above bug fix applied. Can you please verify that this is indeed a conntrack bug? Can you do some tcpdump capturing that actually shows that there was a connection teardown (FIN handshake or RST) and after it, conntrack state of the respective connection stays ESTABLISHED? I just want to make sure that this is really some problem about a possible conntrack bug - not some application that forgets to fully close TCP connections.. > Systems Administrator > Shadow Realm -- - Harald Welte <laforge@xxxxxxxxxxxxx> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie
Attachment:
pgp00466.pgp
Description: PGP signature
