ip_conntrack locks up hard on 2.4.0 after about 10 hours
Subsystems (2)
It seems that for one reason or another, ip_conntrack totally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output
Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1
when=0x1fa85, caller=c01a6bf1
This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset ip_conntrack and i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not an ip_conntrack bug and rather something that has
changed that i havn't read about, help would be nice. :) i have been
using iptables since it came out though and ip_conntrack has only been
bad once before, on test5 when it wouldn't kill old dead socket
connections and eventually starved itself of free sockets.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Setiathome 3.03 and 3.x most likely causes the ip_conntrack errors which
quickly brings the system to a screetching network halt. I suggest nobody
run setiathome on their firewall/gateway/router if they're using iptables
with 2.4.x. Not sure how it causes this error nor would it matter to me
since i wouldn't be able to recode the client anyway. I'm sure there are setiathome developers (at least one) paying attention to this list. The client is broken.
Quoted 29 lines · safemode
It seems that for one reason or another,
ip_conntracktotally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg outputJan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5b2f, caller=c01a6bf1 Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x56bb, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x217db, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x2363e, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x21b64, caller=c01a6bf1 Jan 6 06:40:10 icebox kernel: reset_xmit_timer sk=c17fd040 1when=0x1fa85, caller=c01a6bf1
This makes it impossible to make any sort of network socket connection and all prior connections died. As i said you cannot remove the module to reset
ip_conntrackand i'm not sure what could have caused this as it did work up until i woke up this morning, with a total running time of about 10 hours or so. I'd consider this bug rather important, if anyone thinks this is not anip_conntrackbug and rather something that has
changed that i havn't read about, help would be nice. :) i have been
using iptables since it came out though andip_conntrackhas only been
bad once before, on test5 when it wouldn't kill old dead socket
connections and eventually starved itself of free sockets.
Date: Sat, 06 Jan 2001 10:37:54 -0500
From: safemode <[email protected]>
Jan 6 06:18:10 icebox kernel: reset_xmit_timer sk=c17fd040 1 when=0x5d9e, caller=c01a6bf1
I posted a fix for this on Linux-kernel yesterday, had you tested it you would have seen at least this part of your problem report go away. I'm reposting the fix for your convenience:
ipv4/tcp_input.c renamed from ipv4/tcp_input.c.~1~ +1 -2
@@ -1705,7 +1705,7 @@if ((__s32 )when < (__s32 )tp->rttvar) when = tp->rttvar; -tcp_reset_xmit_timer (sk,TCP_TIME_RETRANS , when); +tcp_reset_xmit_timer (sk,TCP_TIME_RETRANS ,min (when,TCP_RTO_MAX )); } } -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In message <[email protected]> you write:
Quoted 3 lines
It seems that for one reason or another,
ip_conntracktotally locks (not removeable) after about 10 hours of continued use. All i found were these messages in my dmesg output
What was the contents of /proc/net/ip_conntrack?
Being unremovable can happen if someone is holding a packet, which the below fix (by Xuan Baldauf) will often alleviate, but connection tracking doesn't DROP packets (NAT and packet filtering do).
Hope that helps,
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
net/ipv4/ip_input.c +7 -0
@@ -225,6 +225,13 @@nf_debug_ip_local_deliver (skb);#endif /*CONFIG_NETFILTER_DEBUG*/ +#ifdef CONFIG_NETFILTER +/* Free reference early: we don't need it any more, and it may +hold ip_conntrack module loaded indefinitely. */ +nf_conntrack_put (skb->nfct); + skb->nfct =NULL ; +#endif /*CONFIG_NETFILTER*/ +/* Point into the IP datagram, just past the header. */ skb->h.raw = skb->nh.raw + iph->ihl*4 ;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/