Hi! My WRT54G crashes always, when it's charged with high traffic. For instance, using P2P clients or if I stream audio data to the WAN. Reducing the MTU size makes it more stable, but even then it's not really "traffic-proof". A reset of the WRT54G and the modem "solves" the problem until the next crash. I'm connected to the internet using a cable modem (swiss ISP Cablecom). I tried different firmware types and versions, but the problem still occurs. My old internet gateway was a cheap sercomm switch, witch works without any problems. Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is EXACTLY what is happening to me, it seems everything is flowing nicely, then suddenly my DSL modem just freezes, and the router crashes, after which only a reset of them both will bring everything back to life. Same deal, lowering my MTU makes it a bit more stable, but it still craps out if have more than 1 download going.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
here it's almost the same... but the difference is that only the pppd crashes (says syslogd) and restarts a few seconds later. the router itself keeps running.
that only happens when i'm using bittorrent-clients, but then it happens almost every 10 minutes. i restricted the max. connections of it to 200, now it is a bit more stable but still crashes. so what can i do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you can get a command line on the WRT54G, run 'dmesg' and see if it says it is dropping packets. Most likely it is due to the ip_conntrack tables becoming full of p2p connections.
The workarounds are to increase the ip_conntrack_max value and to decrease the timeout period in the ip_conntrack_tcp_timeouts from 432000 seconds to something more reasonable like 3600 seconds.
------start of copy/paste------
I have several Sveasoft Satori 4.0 (free version) installations that have
worked mostly okay as wireless bridges using WDS. These WRT54Gs are not
used for QOS, firewalling, routing, DHCP, or anything besides WDS bridging.
The only problems I've run into are:
1.) a cosmetic error in the 'dmesg' list: 'kernel timer added twice at
c0019d40.'
2.) a problem stemming from p2p traffic and extremely long connection
timeout settings, showing up in dmesg, also noticeable by the WRT54G not
passing packets/not permitting new connection: 'ip_conntrack: table full,
dropping packet.' This problem creates the impression that you need to
reboot the router, however turning off the p2p program and waiting for the
timeouts to occur can also work. A better solution is to increase the
conntrack_max value from the default 1024 to 2048, 4096, or 8192, and to
lower the timeout period to 1hr (3600 seconds). Do this by running these
commands at the linux command line (or run the GUI command line submission
page):
echo #### > /proc/sys/net/ipv4/ip_conntrack_max where #### is a power of 2
number larger than 1024
e.g. echo 2048 > /proc/sys/net/ipv4/ip_conntrack_max
BTW, the same effect can be had by using sysctl some Linux systems (didn't
seem to work on Satori...r/w issues?):
sysctl -w net.ipv4.ip_conntrack_tcp_timeouts="1800 3600 120 60 120 120 10
60 30 120"
This changes the TTL for established connections to 1 hour vs 5 days
(432000 seconds) by default. This TTL counter is reset every time a packet
uses a particular connection, so an active connection or one using
keepalives will not be ended:
echo "1800 3600 120 60 120 120 10 60 30 120" >
/proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
These can be added to the rc_startup nvram variable so they run on every
reboot.
Here are other diagnostic commands related to the above that may be useful
to someone:
cat /proc/net/ip_conntrack
cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
grep "ip_conntrack" /proc/slabinfo
------end of copy/paste------
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi! My WRT54G crashes always, when it's charged with high traffic. For instance, using P2P clients or if I stream audio data to the WAN. Reducing the MTU size makes it more stable, but even then it's not really "traffic-proof". A reset of the WRT54G and the modem "solves" the problem until the next crash. I'm connected to the internet using a cable modem (swiss ISP Cablecom). I tried different firmware types and versions, but the problem still occurs. My old internet gateway was a cheap sercomm switch, witch works without any problems. Any ideas?
This is EXACTLY what is happening to me, it seems everything is flowing nicely, then suddenly my DSL modem just freezes, and the router crashes, after which only a reset of them both will bring everything back to life. Same deal, lowering my MTU makes it a bit more stable, but it still craps out if have more than 1 download going.
Same thing happens to me. I am on covad dsl. Mostly during p2p, but sometimes during heavy web browsing as well.
here it's almost the same... but the difference is that only the pppd crashes (says syslogd) and restarts a few seconds later. the router itself keeps running.
that only happens when i'm using bittorrent-clients, but then it happens almost every 10 minutes. i restricted the max. connections of it to 200, now it is a bit more stable but still crashes. so what can i do?
If you can get a command line on the WRT54G, run 'dmesg' and see if it says it is dropping packets. Most likely it is due to the ip_conntrack tables becoming full of p2p connections.
The workarounds are to increase the ip_conntrack_max value and to decrease the timeout period in the ip_conntrack_tcp_timeouts from 432000 seconds to something more reasonable like 3600 seconds.
My original posting in regards to how to fix this problem on a different firmware are here:
http://groups.yahoo.com/group/WRT54G/message/102
------start of copy/paste------
I have several Sveasoft Satori 4.0 (free version) installations that have
worked mostly okay as wireless bridges using WDS. These WRT54Gs are not
used for QOS, firewalling, routing, DHCP, or anything besides WDS bridging.
The only problems I've run into are:
1.) a cosmetic error in the 'dmesg' list: 'kernel timer added twice at
c0019d40.'
2.) a problem stemming from p2p traffic and extremely long connection
timeout settings, showing up in dmesg, also noticeable by the WRT54G not
passing packets/not permitting new connection: 'ip_conntrack: table full,
dropping packet.' This problem creates the impression that you need to
reboot the router, however turning off the p2p program and waiting for the
timeouts to occur can also work. A better solution is to increase the
conntrack_max value from the default 1024 to 2048, 4096, or 8192, and to
lower the timeout period to 1hr (3600 seconds). Do this by running these
commands at the linux command line (or run the GUI command line submission
page):
echo #### > /proc/sys/net/ipv4/ip_conntrack_max where #### is a power of 2
number larger than 1024
e.g. echo 2048 > /proc/sys/net/ipv4/ip_conntrack_max
BTW, the same effect can be had by using sysctl some Linux systems (didn't
seem to work on Satori...r/w issues?):
sysctl -w net.ipv4.ip_conntrack_tcp_timeouts="1800 3600 120 60 120 120 10
60 30 120"
This changes the TTL for established connections to 1 hour vs 5 days
(432000 seconds) by default. This TTL counter is reset every time a packet
uses a particular connection, so an active connection or one using
keepalives will not be ended:
echo "1800 3600 120 60 120 120 10 60 30 120" >
/proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
These can be added to the rc_startup nvram variable so they run on every
reboot.
Here are other diagnostic commands related to the above that may be useful
to someone:
cat /proc/net/ip_conntrack
cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
grep "ip_conntrack" /proc/slabinfo
------end of copy/paste------