Post by Rod Gasso » Sun, 27 Jan 2002 20:37:25

Hi all,

I'm not sure if this is the right place to ask, but I have a problem that I
hope someone can help with.

For the last 6 months or so I've been running a self-compiled kernel 2.4.2
without any problems (198 days uptime).

Over Xmas I figured it was about time to upgrade it in order to fix the FTP
connection tracking bug/exploit, and also the buggy loopfs  (both known
problems).  Alas, every version that I've compiled & tried (from 2.4.3 up to
2.4.17) has caused me no end of grief in that after what seems to be a
random time period (from a few minutes, up to a couple of days) the system
totally freezes, with a reboot the only way out.

The only real clue I have as to the cause is this line from the syslog file:

Jan  3 21:49:36 helga kernel: LIST_DELETE: ip_conntrack_core.c:165
`&ct->tuplehash[IP_CT_DIR_REPLY]'(c5563e64) not in &ip_conntrack_hash

The above was using version 2.4.8 with the connection tracking being loaded
as modules.

If it is of any help, the last version I tried was 2.4.17 with the
connection tracking stuff built into the kernel (rather than as loadable
modules). The system stayed up for a little over 24hrs before I got:

Jan 10 00:05:51 helga kernel: LIST_DELETE: ip_conntrack_core.c:165
`&ct->tuplehash[IP_CT_DIR_REPLY]'(cbe6d224) not in &ip_conntrack_hash

I am not a C programmer, so all of this is virtually meaningless to me - all
I know for sure is that this is the last thing in the logs before the
machine freezes.  I've performed several searches on GOOGLE in the hopes of
making sense of all of this, and although I did find a couple of newsgroup
postings reporting identical problems, I haven't found a thing in regards to
a solution.

I've tried patching my original kernel (2.4.2 -> 2.4.3) and I also did a
totally 'fresh' download of the 2.4.8 & 2.4.17 tar balls.  The problem

Does anyone have any ideas as to the cause, and more importantly, is there a

I'm currently back to using 2.4.2 (which I also recompiled, just to be sure
the problem didn't lie somewhere other than the kernel source) and it is
just as stable as it was before this fiasco started.

Just in case it's relevant, I am using the GCC version 2.96 compiler.

If there's any more info required that you think may help, please let me
know, and I'll supply what I can.



1. Possible bug in ip_conntrack on ip change

Did you apply the pending/submitted patches from patch-o-matic?
There's a known bug in conntrack in kernel 2.4.20 that can make old
connections still hang around. It's fixed in the latest 2.4.21-pre

Or you can download patch-o-matic and patch your 2.4.20 kernel.
And then execute ./runme --batch pending

And there's an entry about this problem with MASQUERADE and old
connection hanging around in the netfilter bugzilla, it's not
neccessarily the same bug as the one that's fixed in later kernels.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. printer install

3. fix modify-after-free bug in ip_conntrack

4. UFS max file size?

5. ip_conntrack & timing out of connections

6. (t)csh output rediirect

7. Logging ip_conntrack and/or NAT mappings?

8. xWindows Question

9. [Fwd: Question with printk warnings in ip_conntrack with 2.4.20.]

10. bridging fw + ip_conntrack didn't work

11. Connections in /proc/net/ip_conntrack I didn't expect

12. Userspace packet queuing with libipq: ip_conntrack does not defragment?

13. circular dependency in netfilter headers (ip_conntrack.h)