TCP/UDP timeout and Max Port settings?

Discussion in 'HyperWRT Firmware' started by ranpha, Nov 12, 2005.

  1. ranpha

    ranpha Network Guru Member

    How can I manually set the timeout values for TCP and UDP connections?

    There is a GUI for this setting in DD-WRT. I wonder if I can adjust these values in telnet or something. This is because lowering them seems to help me get stable connection in P2P.

    I also wants to know how to set the Max Port settings (in DD-WRT it has a GUI where I canset it up to 4096 Ports).

  2. Thibor

    Thibor Super Moderator Staff Member Member

    you can change the settings from default by putting the following in the startup_script:
    echo "4096" > /proc/sys/net/ipv4/ip_conntrack_max
    echo "300 600 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

    the default max in Hyperwrt is 2048
    of course you can change the values to whatever you prefer
  3. ranpha

    ranpha Network Guru Member

    Er... from those numbers which ones stands for TCP timeout value and UDP timeout value?

    Just want to know because I want to experiment a little with those values to find out which one is better for BT.

  4. Thibor

    Thibor Super Moderator Staff Member Member

    neither of those relate to udp timeouts, that would be a different file that is set by default to "30 180"
    the 2nd number in ip_conntrack_tcp_timeouts is the important one. Linksys by default set it to 436000(5 days) for the amount of time a stale tcp entry will remain in the connection table. i have reduced it to 4 hours in previous releases, but i will be dropping it to 10 minutes for the next one i do.
  5. RonWessels

    RonWessels Network Guru Member

    Thibor, I'm running "Hyperwrt_2.1b1_v4.70.6-Thibor, Oct. 19, 2005" (thanks for the work, by the way), but when I
    # cat /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
    I get
    1800 432000 120 60 120 120 10 60 30 120

    Over time, I've done an "erase nvram; reboot", I've done a "Restore Factory Defaults", and I've even done the 30-second reset button. What I haven't done is explicitly set the value using "echo ... > ...". Yet still I get the "old values".

    This is the case with two different routers, each flashed with that same firmware, so re-flashing the firmware can't possibly help.
  6. ranpha

    ranpha Network Guru Member

    Thanks for the info.

    Those startup script should work on tofu9 firmware right?

    Thanks again.
  7. Thibor

    Thibor Super Moderator Staff Member Member

    ranpha: yes it will work in Tofu9, Ron: i have 0 ideas how that is possible, i have used 14400 for quite a long time now.
  8. RonWessels

    RonWessels Network Guru Member

    Thibor, if there's anything that you would like me to check to help debug this, feel free to email me at RonWessels at

    I've got a spare GS that I can muck about settings with. I've specifically avoided the explicit "echo ... > ..." setting, just in case that is somehow "sticky".

    Update: Ok, I tried explicitly setting the values, specifically setting the second value to 120. I then issued a command-line "reboot" The second value went back to 432000 after the reboot.
  9. Thibor

    Thibor Super Moderator Staff Member Member

    of course it went back after a reboot, the filesystem is read only and is loaded on a flash chip, that's the point of putting it in the startup_script
  10. RonWessels

    RonWessels Network Guru Member

    Excuse me? The contents of /proc are most certainly not read-only. The only read-only filesystem is the root filesystem. However, /dev has a read-write devfs type filesystem mounted on it, /tmp has a read-write ramfs type filesystem mounted on it and /proc has a read-write proc type filesystem mounted on it.

    The "files" in /proc are interfaces into kernel data structures presented in a filesystem-like manner. These kernel data structures can take initial values from almost arbitrary mechanisms including hard-coded in the kernel source code or a configuration section of the read-write flash chip similar to nvram variables.

    And there is definitely something bizarre going on with the way the nvram variables are initialized, almost certainly buried in the Linksys code. For example, I have personally experienced, and others have reported that the clkfreq nvram variable remains at 200 even after the latest firmware is loaded and booted. In my case, it was only when I explictly set the clkfreq variable that it began to behave "normally". I'm relatively certain that an "erase nvram; reboot" sequence accomplishes the same thing.

    My guess was that something similar might have been happening with the tcp_timeouts settings, however that is not correct.

    Could anyone else running Thibor's recent firmware please chime in whether the second value in their default settings in /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts is the 432000 I'm seeing or the 14400 value that Thibor is seeing? Perhaps there's something bizarre with the Canadian vs European version of the hardware.
  11. Thibor

    Thibor Super Moderator Staff Member Member

    sorry, my mistake. the product of too much beer and too little sleep. the tcp_timeouts are read from the kernel. as i have stated before i don't understand why yours would be set to 432000(5 days). if you add the echo command into your startup_script it will change the value at boot time. there should be no regional variation of the kernel. the cpu clock setting thing i know about, there is some code in the sources to check the hardware type and then set the clock to the appropriate frequency

    **EDIT** You're correct. i just loaded 191005 and the tcp connection timeout is indeed set to 432000, my sincere apologies for the mistake. it will of course be changed for the next release.
  12. PaCkEtGrEmLiN

    PaCkEtGrEmLiN Network Guru Member

    Hi Thibor,

    I touched on the " ip_conntrack_tcp_timeouts " discussion between firmwares over here HyperWRT Forum.

    For my needs 14400 seams to work well for tcp connection timeouts. However, folks that frequent P2P may wish to offer their findings as to which value works best for them. Who knows maybe 10 min's is the magic #.

    Regards - PaCkEt
  13. Thibor

    Thibor Super Moderator Staff Member Member

    10 mins is working ok here, it shouldn't do any harm as the values are for the duration of stale connections to remain in the table.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice