Router Slowdown

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 19:52, 26 November 2006 (edit)
Atzekalle (Talk | contribs)
m (spam)
← Previous diff
Revision as of 23:05, 3 December 2006 (edit) (undo)
Kubanczyk (Talk | contribs)
(Added UDP timeout changes)
Next diff →
Line 15: Line 15:
To view syslog messages, [[Telnet/SSH and the Command Line|Telnet or SSH]] into your router, login and run the following command: To view syslog messages, [[Telnet/SSH and the Command Line|Telnet or SSH]] into your router, login and run the following command:
- cat /var/log/messages+<pre>
 +cat /var/log/messages
 +</pre>
Here is a brief description of what's going on : Here is a brief description of what's going on :
Line 24: Line 26:
<4>kernel: ip_conntrack: table full, dropping packet. <4>kernel: ip_conntrack: table full, dropping packet.
<4>kernel: NET: 12 messages suppressed. <4>kernel: NET: 12 messages suppressed.
 +
 +You should check if your problem is caused by TCP or UDP connections:
 +
 +<pre>
 +cat /proc/sys/net/ipv4/ip_conntrack_max
 +4096 # your max space
 +grep ^udp /proc/net/ip_conntrack | wc
 +693 10338 115245 # here UDP uses 693 entries
 +grep ^tcp /proc/net/ip_conntrack | wc
 +115 1836 20098 # and TCP uses only 115 entries
 +</pre>
Line 34: Line 47:
**'''TCP Timeout (s)''': 90 or 120 **'''TCP Timeout (s)''': 90 or 120
**'''UDP Timeout (s)''': 90 or 120 **'''UDP Timeout (s)''': 90 or 120
- 
-==Screenshot== 
[[Image:Ipfiltersettings.JPG|alt IP Filter Settings at DD-WRT v23]] [[Image:Ipfiltersettings.JPG|alt IP Filter Settings at DD-WRT v23]]
 +*Save
 +*Reboot
 +*Check via command line if it worked (on some routers it doesn't!)
 +<pre>
 +cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
 +300 600 120 60 120 120 10 60 30 120 # "600" is important for you
 +cat /proc/sys/net/ipv4/ip_conntrack_udp_timeouts
 +65 180 # "180" is important for you
 +</pre>
 +
 +
 +The line used to correct timeouts manually
 + echo '600 1800 120 60 120 120 10 60 30 120' > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
 +is often recommended in forums, but precious few know what it really does. Here is the explanation.
 +
 +It is a list for all the possible TCP states and their time outs in seconds. See my table below (they are in the correct order):
 +
 + State Timeout value
 +
 + NONE 10 minutes
 + ESTABLISHED 30 minutes (default is 5 days)
 + SYN_SENT 2 minutes
 + SYN_RECV 60 seconds
 + FIN_WAIT 2 minutes
 + TIME_WAIT 2 minutes
 + CLOSE 10 seconds
 + CLOSE_WAIT 60 seconds (default is 12 hours)
 + LAST_ACK 30 seconds
 + LISTEN 2 minutes
==AIM, ICQ and other IM programs== ==AIM, ICQ and other IM programs==
If you're using certain IM clients such as ICQ or AIM (or other applications which do not send frequent keep-alive packets), you should set timeout to 300 or 600 to help them stay connected. As this will decrease the router's performance when you're dealing with heavy P2P traffic, you might want to experiment with these values. If you're using certain IM clients such as ICQ or AIM (or other applications which do not send frequent keep-alive packets), you should set timeout to 300 or 600 to help them stay connected. As this will decrease the router's performance when you're dealing with heavy P2P traffic, you might want to experiment with these values.
 +==UDP-related slowdown==
 +This is often caused by BitTorrent DHT traffic. To manually fix UDP-related slowdown issue:
 +<pre>
 +echo '30 60' > /proc/sys/net/ipv4/ip_conntrack_udp_timeouts
 +</pre>
=Solution 2= =Solution 2=
Line 70: Line 115:
=Extra Information= =Extra Information=
-The line 
- echo '600 1800 120 60 120 120 10 60 30 120' > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts 
-is often recommended in forums, but precious few know what it really does. Here is the explanation. 
- 
-It is a list for all the possible TCP states and their time outs in seconds. See my table below (they are in the correct order): 
- 
- State Timeout value 
-  
- NONE 10 minutes 
- ESTABLISHED 30 minutes (default is 5 days) 
- SYN_SENT 2 minutes 
- SYN_RECV 60 seconds 
- FIN_WAIT 2 minutes 
- TIME_WAIT 2 minutes 
- CLOSE 10 seconds 
- CLOSE_WAIT 60 seconds (default is 12 hours) 
- LAST_ACK 30 seconds 
- LISTEN 2 minutes 
- 
-You can check what your router is set to by printing the same device used above. (I recommend checking the values on your router before you change them): 
- cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts 
- 300 600 120 60 120 120 10 60 30 120 
[[Category:English documentation]] [[Category:English documentation]]

Revision as of 23:05, 3 December 2006

Contents


A lot of people have issues with their router, some symptoms can be

  • Slow web-interface
  • Slow transfer of data, e.g. browsing
  • Not responding to ping
  • Crash or even rebooting

Usually these people are running P2P software like Emule, Bittorrent, Shareaza or something else. These programs require a lot of connections which could cause the ip_conntrack-table to get full.


Diagnosis

Even if it happens the router doesn't answer pings anymore and no more HTTP, you still can check what's going on through syslogd.

To view syslog messages, Telnet or SSH into your router, login and run the following command:

cat /var/log/messages

Here is a brief description of what's going on :

  1. First, you'll see 'full, dropping packet.' messages followed by 'messages suppressed.'
  2. Eventually, it will get verbose and you'll see logs similar to the following :
<4>kernel: ip_conntrack: table full, dropping packet.
<4>kernel: NET: 15 messages suppressed.
<4>kernel: ip_conntrack: table full, dropping packet.
<4>kernel: NET: 12 messages suppressed.

You should check if your problem is caused by TCP or UDP connections:

cat /proc/sys/net/ipv4/ip_conntrack_max
4096                                       # your max space
grep ^udp /proc/net/ip_conntrack | wc
693   10338  115245                        # here UDP uses 693 entries
grep ^tcp /proc/net/ip_conntrack | wc
115    1836   20098                        # and TCP uses only 115 entries


Solution 1

  • Go to the Web-Admin and log in
  • Go to 'Administration'
  • Go to 'Management'
  • Enter the following values at 'IP Filter Settings'
    • Maximum Ports: 4096
    • TCP Timeout (s): 90 or 120
    • UDP Timeout (s): 90 or 120

alt IP Filter Settings at DD-WRT v23

  • Save
  • Reboot
  • Check via command line if it worked (on some routers it doesn't!)
cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
300     600     120     60      120     120     10      60      30      120       # "600" is important for you
cat /proc/sys/net/ipv4/ip_conntrack_udp_timeouts
65     180                                                                        # "180" is important for you


The line used to correct timeouts manually

echo '600 1800 120 60 120 120 10 60 30 120' > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

is often recommended in forums, but precious few know what it really does. Here is the explanation.

It is a list for all the possible TCP states and their time outs in seconds. See my table below (they are in the correct order):

State		Timeout value

NONE		10 minutes
ESTABLISHED	30 minutes (default is 5 days)
SYN_SENT	2 minutes
SYN_RECV	60 seconds
FIN_WAIT	2 minutes
TIME_WAIT	2 minutes
CLOSE		10 seconds
CLOSE_WAIT	60 seconds (default is 12 hours)
LAST_ACK	30 seconds
LISTEN		2 minutes

AIM, ICQ and other IM programs

If you're using certain IM clients such as ICQ or AIM (or other applications which do not send frequent keep-alive packets), you should set timeout to 300 or 600 to help them stay connected. As this will decrease the router's performance when you're dealing with heavy P2P traffic, you might want to experiment with these values.

UDP-related slowdown

This is often caused by BitTorrent DHT traffic. To manually fix UDP-related slowdown issue:

echo '30 60' > /proc/sys/net/ipv4/ip_conntrack_udp_timeouts

Solution 2

DD-WRT has an inbuild proxy feature that allows rewriting of HTML content to filter ActiveX cookies, etc. As this is load-intensive, you may want to disable this feature. This should be done under Security->Firewall.

Unfortunately this function has 3 bugs:

  • Though all 4 checkboxes are unchecked the rewriting proxy is still running (you might have to reboot)
  • It drops connections if under heavy load
  • It probably runs haywire checking traffic on other ports than 80, hence the slowdown with P2P applications (unconfirmed)

The only solution is to totally disable the firewall (which I do not recommend) in Security->Firewall. This fixes all slowdowns.

This behavior has been seen in v22 and v23. Please report this to the maintainer and put it in the bug database.


Solution 3

Apparently there is a bug in the WRT54GS v2.2. The bug involves a fatal memory access error due to a difference in the CPU clock speed and the clock speed on the memory bus. This bug causes connections to be dropped when transferring large files. New versions of the Linksys firmware overclock the CPU to 216 MHz. This can be fixed by logging into the router via SSH or Telnet and executing the following commands:

nvram set clkfreq=216
nvram commit
reboot

Extra Information