Conntrack problem, machines freeze

Conntrack problem, machines freeze

[Lukasz Spaleniak]

Hello,

I have simple linux router with three fastethernet cards (intel , e100
driver). About two months ago it started hanging. It's completly
freezing machine (no ooops. First of all when it's booting few
messages like this appears on screen:

NF_IP_ASSERT: ip_conntrack_core.c:1128(ip_conntrack_alter_reply)

I suppose it's showing before firewall script load rules (simple nat).
After that somtimes it's working very long, sometimes it's freezing
after few seconds. One time I've logged this message before it freezes:

kernel: LIST_DELETE: ip_conntrack_core.c:302 `&ct->tuplehash
[IP_CT_DIR_REPLY]'(decb6084) not in &ip_conntrack_hash[hr].

Components that has been already replaced:
- computer hardware (twice to a new one)
- fast ethernet cards (tried with intel, realtek and 3com)
- fresh system (debian sarge)
- switches

Router and switches are connected to UPS (dedicated, also replaced).

This is a vanilla kernel 2.4.31, problem also exist with kernels:
2.4.30, 2.4.29. I tried also with grsecuriry(hoping it could help)
patch, but it wasn't.

If you have any idea what I can try to fix please let me know.

Thank you for your time.


Best regads,
Lukasz Spaleniak


-- 
spalek on zigzag dot pl
GCM dpu s: a--- C++ UL++++ P+ L+++ E--- W+ N+ K- w O- M V-
PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+

Re: Conntrack problem, machines freeze

[Patrick McHardy]

Lukasz Spaleniak wrote:
> Hello,
> 
> I have simple linux router with three fastethernet cards (intel , e100
> driver). About two months ago it started hanging. It's completly
> freezing machine (no ooops. First of all when it's booting few
> messages like this appears on screen:
> 
> NF_IP_ASSERT: ip_conntrack_core.c:1128(ip_conntrack_alter_reply)

This one can happen if the NAT module is loaded after ip_conntrack and
there are already existing conntrack entries, but it should be harmless.

> I suppose it's showing before firewall script load rules (simple nat).
> After that somtimes it's working very long, sometimes it's freezing
> after few seconds. One time I've logged this message before it freezes:
> 
> kernel: LIST_DELETE: ip_conntrack_core.c:302 `&ct->tuplehash
> [IP_CT_DIR_REPLY]'(decb6084) not in &ip_conntrack_hash[hr].

This one probably results from the above, when the conntrack is altered
it may end up in a different hash bucket, LIST_DELETE complains if it
doesn't find it on the list where it is to be removed from. Hmm .. so
the above is probably not harmless after all, when freeing the conntrack
we don't remove it from the list if netfilter debugging is enabled.

Does disabling CONFIG_NETFILTER_DEBUG make any difference?