1.3 Wireless behavior

[spriseris]

wow i upgraded my linksys wrt54g from 4.20.7 official to HyperWRT2.1b1 tofu11.. my connected peers and seeds have SKYROCKETED and sustained on a torrent i've been running for 2 days (11 gigs of japanese tv)!!! not to mention my web surfing and other internet usage is making it through my router now without seeming like i'm on a 9600 baud conneciton. i love this new firmware. i was skeptical but now i'm a believer..

btw, this is the script that the readme for tofu's hyperWRT recommends putting in the startup for p2p applications:

echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1

echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

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

i figured why not, and use it.

[Firon]

Actually, there's one thing I wouldn't recommend using

echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1

echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

You should take those out, those can actually make things worse. The rest are good though, I use 'em since I haven't upgraded to tofu11 yet (tofu11 is supposed to have it integrated but I'd probably use the startup script anyway).

But in all honesty, that simple change does wonders for the router. It's why I added it to the FAQ, in bold even.

If you know of any Linksys WRT54G/GL/GS users, you should probably tell them to do similarly.

http://utorrent.com/faq.php#Special_note_for_users_with_Linksys_WRT54G_GL_GS_routers

Should give all the instructions needed.

[spriseris]

i'm not sure what those 3 lines do, can you explain them? for some reason tofu11's zip file has those included in the "recommended startup script for P2P users"

[Firon]

They control the thresholds for the router to cleanup the open connections. The defaults for gc_thresh1 2 and 3 are a better idea to keep. tofu's readme is a bit outdated in regards to that.

You may not even want to use

echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max

Experiment with and without it I guess.

[Primus]

Since we're just throwing this script around as a solution (which it is), I figured I'd do a little explaining of what each of the options in that script does and why it's a Good Thing.

echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max

This sets the number of total connections the router will keep track of to 4096. You shouldn't go over this number, as it's already pretty large for a device with 16MB of RAM. Typically the formula used to determine the ip_conntrack_max size is [ (RAM in MB) * 64 ] / 1 or 2, with 1 if it's a 32-bit system and 2 if it's a 64-bit one.

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

This tells the router to ignore ICMP echo broadcast packets, as well as any out-of-protocol-spec ICMP errors. These are protections against DoSes and other evil network things.

echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1

echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2

echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

These three settings control the size and behavior of the router's ARP (address resolution protocol) table. The ARP table keeps tabs on local network hosts only, not on remote hosts. So raising the values of the ARP tables above their limits is only needed if the router is servicing a large number of hosts on its internal network(s), and will have no positive effect on most home P2P users. In fact, it may actually have a detrimental effect as you're taking memory away from the other processes running and locking it up in the kernel ARP tables.

As for the three values, thresh3 is the hard max limit of the ARP table. It will never grow higher than the thresh3 value. thresh2 is the soft limit. When this limit is hit, the table starts garbage collection until the number of entries hits the thresh1 value.

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

Several different values are being set here, corresponding to the different states of a TCP connection. I'll run these down in series (all values are in seconds):

600 - NONE
1800 - ESTABLISHED
120 - SYN_SENT
60 - SYN_RECV
120 - FIN_WAIT
120 - TIME_WAIT
10 - CLOSE
60 - CLOSE_WAIT
30 - LAST_ACK
120 - LISTEN

The ESTABLISHED one is important, that's the one that's being set to 5 days by default in the Linksys firmware and is causing the problems. I won't bore folks with the other flags and what they do, that's just being pedantic and any decent TCP/IP reference will have that information.

[1c3d0g]

Primus, excellent post...thank you for explaining that to us.

[spriseris]

wow much appreciated Primus and Firon.

*bump*

[bibber]

By the way, did you patch TCPIP.sys? Or raise net.max_halfopen (especially without patching it)? Check the event log (eventvwr.msc) and see if there's any event 4226...

You should still change the firmware though.

OK. I've upgraded my WRT54G to DD-WRT 23 (12-12-2005). Great firmware, although I nearly bricked my router. Several tries with the reset button brought it back to live.

I have not patched my TCPIP.SYS (should I?) and net.max_halfopen is at its default of 8. I do have an occasional 4226 event, but not often and not at times uTorrent is failing.

Back to uTorrent 1.3: I have loaded 10 torrents currently of which 4 are suffering of a bad tracker. Manually updating the other 6 trackers still gives me timeouts on them. So nothing changed much, I'm afraid. These are the timeout settings for DD-WRT by the way:

~ # cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

3600 3600 120 60 120 120 10 60 30 120

I was wondering: has anyone actually tried to repeat this? Loading 10 or so torrents, wait a bit and then manually updating them? Because it seems so consistently related to version 1.3, I cannot imagine I'm the only one suffering. :/

[Firon]

I started 6 torrents at once on one tracker, and 5 for another. All but one worked (boxtorrents is really overloaded and goes down a lot, so not a surprise), and the one that timed out worked on the next announce. Manually updating all of them at the same time worked several times without a hitch.

[1c3d0g]

Bibber: I still feel you should patch your TCPIP.sys file. Many people have reported a great increase in speed...besides, you've got nothing to lose.

[bibber]

Just a moment ago I found out the following: without uTorrent running I can do a 'telnet localhost 8080' (that proxy again) and get a connect and response instantly. With uTorrent running it can take anywhere between 0,5 and 10 seconds to get the connection...

That together with your advice convinced me to patch my TCPIP.sys to 50. Next I upgraded to uTorrent 1.3 again and set net.max_halfopen to 30. So far it looks like my problems are solved. With or without uTorrent running I get instantaneous connects with my local proxy, I can do manual updates without timeouts etc.

Many thanks guys! Will let you know if it stays like this.

Edit: browsing the web with uTorrent 1.3 running is still a bit flaky. Already increased the TCPIP.sys limit to 100, but that doesn't seem to help. I noticed the ip_conntrack_max being set at 512 by default by the DD-WRT firmware. I might try changing that to see if it helps.

Edit2: increased ip_conntrack_max to 4096 as recommended on this forum and web browsing has been ultrafast since. I even increased my upload cap from 50KB/s to 75KB/s (1024Kbps upload)! So far, so good.