Router Slowdown

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 06:55, 17 May 2007 (edit)
Gnassar (Talk | contribs)

← Previous diff
Revision as of 06:57, 17 May 2007 (edit) (undo)
Gnassar (Talk | contribs)
m
Next diff →
Line 90: Line 90:
The full list of files in the /proc/sys/net/ipv4/netfilter/ directory that one can populate to get the same effect on v23 SP2 and later firmwares is: The full list of files in the /proc/sys/net/ipv4/netfilter/ directory that one can populate to get the same effect on v23 SP2 and later firmwares is:
 +<pre>
/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
/proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
Line 102: Line 103:
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
 +</pre>
==AIM, ICQ and other IM programs== ==AIM, ICQ and other IM programs==

Revision as of 06:57, 17 May 2007

Contents


Slowdown

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. Especially BitTorrent DHT feature sends thousands of UDP packets that quickly overflow this table.

Routers affected with this issue are Linksys WRT54G, Linksys WRT54GL, Linksys WRT54GS or just any other machine running DD-WRT.


Diagnosis

Even if this occurs and the router doesn't respond to pings nor HTTP, you still can check what's going on:

  • Close all your P2P/network applications and wait a few minutes for connections to be freed.
  • Try to telnet or SSH into your router. If that's not possible, reboot.
  • Check to see if your problem is caused by TCP or UDP connections:
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
4096                                       # your max space
grep -c ^udp /proc/net/ip_conntrack
3693                                       # here UDP uses 3693 entries
grep -c ^tcp /proc/net/ip_conntrack
115                                        # and TCP uses only 115 entries
  • You may also view syslog messages
cat /var/log/messages
  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.

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): 3600 to 90 (decrease if you have many TCP connections)
    • UDP Timeout (s): 3600 to 90 (decrease if you have many UDP connections)

alt IP Filter Settings at DD-WRT v23

  • Save Settings and then Reboot Router
  • Check via command line if it worked:
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
90
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
90
  • This causes your inactive connections to be dropped after 90 seconds.


Popular, but outdated solution -- and the modern equivalent

The following command is often recommended, but only applies to older versions of the DD-WRT firmware:

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

Note: This method for resolving slowdown issues does apply for DD-WRT v23 SP2 firmware and beyond. Furthermore, this command only applies to TCP traffic issues only, not for UDP issues. The related command for UDP issues has been cited as:

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

The 2.4.23 kernel ignores these files. The correct files are located in /proc/sys/net/ipv4/netfilter/ as shown above.

How It Works

Few people know what this line actually does. It is a list for all possible TCP states and their timeouts in seconds. See the 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

The full list of files in the /proc/sys/net/ipv4/netfilter/ directory that one can populate to get the same effect on v23 SP2 and later firmwares is:

/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
/proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream

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 TCP timeout to 300 or 600 to help them stay connected. As this may cause hangups when you're dealing with very heavy P2P traffic, you might want to experiment with these values.

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

When running DD-WRT micro v23sp2 on a WRT54G v5 the clock speed can be adjusted by logging into the router via SSH or Telnet and executing the following commands:

nvram set overclock=216
nvram commit
reboot

After rebooting the router you can confirm that the new clock speed has applied by checking the Status page of the DD-WRT GUI or by logging in via Telnet and executing the following:

nvram get clkfreq

Solution 4

For P2P applications, and especially Bittorrent, the problem can be an overwhelming number of incoming connections. Try setting a limit to the number of peers/incoming connections to around 100 or so. See Azureus page regarding this.

Known issues

  • When using Steam (of Valve) and when you refresh your server list it might cause your router to reboot since it opens many connections.


---3/23/07--