1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

the source of many problems (AIM, P2P, IRC, FTP disconnects)

Discussion in 'DD-WRT Firmware' started by flexy, Jan 13, 2006.

  1. flexy

    flexy Network Guru Member

    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= 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.
  2. flexy

    flexy Network Guru Member

    [this is more for the coders]

    also, i want to add some thoughts there.

    The doc to iptables is very interesting - i still should read more. They're talking about optimum CONNTRACK table size and optimum HASHSIZE.

    I always hear the recommendation to increase it to 4096.

    But according to:

    For a 32 bit pc with 512Mb of RAM this would be:

    CONNTRACK_MAX = RAMSIZE (in bytes) / 16384
    = RAMSIZE (in MegaBytes) * 64
    = 512*64
    = 32768 (simultaneous netfilter connections by default)

    (It is mentioned that this depends on the pointer size so that on a
    64Bit system the CONNTRACK_MAX is twice the size of that of a 32 system)

    = RAMSIZE (in bytes) / 131072
    = RAMSIZE (in MegaBytes) * 8
    = 4096 buckets (# of linked lists in the hashtable)

    i really wonder what is actually a GOOD value for a little router with barely 16MB ram ?

    Maybe 4096 is much too high ? Maybe 2048 is better, maybe even only 1024 ?

    You cannot just write some wishful fantasy value in there and havea BIG conntrack table when you dont have enough memory !

    I do NOT KNOW whether the above formula also applied for a ROUTER ! If it WOULD then the max. size for a 16MB ram router would be 1024 !!!! 4096 would already be WAY to much !

    ALso...if you read the doc to iptables....you MIGHT want to tweak the hardcoded value for hashsize (see above)

    As is my UNDERSTANDING the CONNTRACK handling is dynamic and basically old connections "delete" themselves when the table gets full. So...it wouldnt matter whether a TTL for "established" is at 432000 (5 days) since the table will NEVER get full and choke up memory - ASSUMING the max_conntrack and hassize is optimally tweaked for the available ram !

    In other words: All "p2p tweaks" would not be needed anyway !

    If you want 8192 max. tracked connects in ip_conntrack...well get real and look at your router and memory. Maybe it would be much better you use 1024 max and 128 for hashsize. You cant do 8192 or 4096 , you just dont have the memory !

    my $0.2
  3. g412b

    g412b Network Guru Member

    Hmm nice theory you have there but i did a quick check.
    On my irc connection the timer never reaches 0 , it always varies between 600 and 500.
    It seems like something (data traffic ?) resets the timer.
    gonna do a few more checks later
  4. meff

    meff Network Guru Member

    Yes, the timer gets renewed. This is not a proper solution to set the TTL up way high.

    Neither is it a 'linux bug'.

    This is standard TCP/IP, after awhile the TTL gets renewed.. Some connections renew earlier, some later. You just need to adjust it to your particular connection.

    If what you said is true, explain please how I can have 5 ssh sessions open for over a week?

    Or if I used NFS would all my clients disconnect after the TTL..?

  5. Nimdae

    Nimdae Network Guru Member

    Any connection which has a relatively short keepalive "ping" will have no problem. For example, I've not noticed a problem with my IRC connections, as the keepalive "pings" are between 90 and 180 seconds, and this is controlled by the server. AIM, on the other hand, either has a very long keepalive "ping", or none at all. I've noticed with some AIM clients, I'll disconnect once a day, so it's likely it has a 24 hour keepalive "ping", or, as I said, none at all.

    I'd say make this timeout 25 or 26 hours and see how it goes. IMO, 2 days is still too long.
  6. phinn

    phinn Network Guru Member

    I don't know about any of these suggestions because V23 stayed broken on my router.

    HyperWRT + tofu12 solved all my problems.

    I'd be like to use DD-WRT again in the future as I love the interface but right now its broken
  7. flexy

    flexy Network Guru Member

    well then how do you explain that when i have an ftp upload going and the particular value is at, say, 10 mins...the upload stops and teh connection is gone. (Once the counter reaches zero !)

    I am never idle since i am uploading.

    and yeah g412b...if you make some tests let me know the results because i wanna knwo too. I just speak of my experience with ftp and i have SEEN it dropping and wondering why on earth i cant upload a longer file !
  8. g412b

    g412b Network Guru Member

    hmm flexy
    are the disconnecets happening when you are using wireless ?
    if so it might be related to the "cpu / memory not fast enough bug"

    Or it might be the problem i have ...
    I myself am experiencing disconnects to but it seems like my itables is crashing from time to time (all my custom made settings are gone)
  9. ceevee

    ceevee Guest

    Does this have anything to do with httpd process using all of the cpu? Sometimes the httpd process uses 99.9% cpu on my wrt54gs 2.1 with dd-wrt v23 final. The only way to get rid of this is by resetting.

    I have 4096 max connections, 300 for tcp and udp timeouts but do these settings get rid of my 99.9% cpu problem?
  10. Sjowhan

    Sjowhan Network Guru Member

    Nice to read, i think that's the solution. On my connection, every 4 hours irc disconnect on every server..

    When reflashing to the original; no problem at all.

Share This Page