Q: why do people have disconnects ? i think this not only affect dd-wrt but also hyperwrt. (Talking about the latest releases.) I posted about this on the bugtracker but it seems people didn't really get what i was saying or dont see that this problem is MAJOR. Just to doublecheck i just resetted my router to factory defaults to check what the router does at DEFAULT setting. (ANd, yeah i have a fix at the end of this posting) There is misconception about certain things and "fixes" were done which have a negative effect. () for testing i am establishing a connection to IRC. This could also be a conection to AIM, P2P, whatever. ~ # cat /proc/net/ip_conntrack | grep 6667 tcp 6 3247 ESTABLISHED src=192.168.1.101 dst=85.25.x.xx sport=4385 dport=6667 src=85.25.x.xx dst=24.14.xx.xx sport=6667 dport=4385 [ASSURED] use=1 rate=43 8 mark=0 ^^^^^ connection on IRC port 6667 is established. the value "3247" in the first line is the TTL for a normal, established TCP connection in secs. the default is 3600 (1hr). You can see this value counting down. Once it reaches ZERO (in about one hour) this TCP connection will be GONE. Means: Your ftp transfer will stop, your aim will kick you off, yiour IRC will be closed. I dont know how apps like bittorrent etc handle closed connections - SOME apps might just retry and re-open a closed connection. ANYWAY this is wrong. You also can NOT set this timing values in the GUI (dd-wrt) since the max. allowed value in the GUI is 3600. ---> this TTL (time to live) value *usually* (for firmware without a 'p2p fix') is set to 5 days timeout which causes OTHER problems because this ip_conntrack table will get full in time - especially with MANY p2p connects going on. BTW this whole thing is NOT a specific firmware issue but rather a linux kernel issue. Its NOT a solution to set this otherwise 5 days value down to 10 mins - because then you run into other problems. YES - your ip_conntrack table will not get full anymore after a few days - but all TCP connections will timout and kick you off So....what would be a "solution" ? As for me running dd-wrt V23 final and looking what i do on my PC i say that i can tolerate a TWO day "established" value since i do NOT have connects going for so long. (Your mileage may vary). What i did: In DD-WRT/administration/diagnostics/command-shell/RUN have one custom FIREWALL (!) script which i paste into the text-box and then save as "save firewall". The reason i use "firewall" is that using "save startup" does NOT work ! [I guess "startup" gets applied earlier in the boot-process and then later overwritten by WRONG values). I have: echo 172800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses in there. Line 1 is the important one, line 2 and 3 just block icmp garbage. Yhe other known "p2p tweaks" are (AFAIK) already applied by hyperwrt/dd-wrt. The value 172800 equals TWO days. Your mileage may vary. You can also use the older, known 432000 value if you THINK you're better off with 5 days..but then risk your table getting full and other problems. Telnet to your router and just doublecheck is the rc_firewall is written ok... ~ # nvram get rc_firewall echo 172800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses ~ # and check whether the above line is in there. FIXED ! You will NOT disconnect every hour anymore. PS i found this by having a longer ftp transfer going which i was unable to complete...reason that the connect was lost after an hour or so. This is (to my VERY Limited knowledge about linux/kernel interna) the reason for all other disconnect/p2p etc. problems. Btw. otherwise i do NOT have any problems with dd-wrt...but i make it a habit to put this in my firewall first thing after a flash.