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.
safemode wrote:
> 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.
>
--------------3A78CA90B6BA2BB3C2A6F3E0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
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.
safemode wrote:
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=c01a6bf1This 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.