Default Tomato timeouts break VoIP

Discussion in 'Tomato Firmware' started by Mango, Dec 27, 2010.

  1. Mango

    Mango LI Guru Member

    I spend a great deal of time on VoIP forums and it seems that I've answered dozens of posts from Tomato users that go, "Every time my ISP changes my IP address, my VoIP quits working," or "Every time I reboot my router, I don't have a dial tone after it comes back up..."

    I tell them to set Unreplied UDP Timeout to 10 and Assured UDP Timeout to 300. That typically solves the problem.

    My question is: why do I see Unreplied/Assured timeouts like 10/10 or 25/10 or the default of 30/180 recommended so often, in the context of VoIP? These will all break Linksys devices, and most will also break Grandstream, Gigaset, and Polycom devices!

    With this small configuration change, my Tomato router is the best router I have ever owned, and I am dismayed every time I see a VoIP provider rep say that people have "tons of issues with [their] service when using Tomato" that went away when they got a different router.

    Is the default of 30/180 that way for a reason that I don't know about? If not, what is involved in changing the default?

    Mango :cool:
  2. Toastman

    Toastman Super Moderator Staff Member Member

    Very valid post, thanks.

    Yes, there is of course a reason. Most SOHO routers have big issues with large numbers of connections. This happens most often with the use of P2P, which opens large numbers of connections and often fails to close them properly. The conntrack timeout settings were previously too long and often left thousands of these these unused connections open, and the router would run out of resources and crash. This is a common problem with SOHO routers, and since relatively few people used VOIP compared to the majority who used P2P, the timeout values were reduced in an attempt to improve stability of the router, which proved to be very successful.

    There have been many attempts to find compromise settings. An assured timeout of 30 seconds did seem to work for many people, but it seems that the matter needs looking at again. Because VOIP is becoming more popular this will become more of a problem in the future. Quite probably the default setting could be changed to e.g. your recommended defaults.

    But maybe there should be some guidance about this in the GUI - or perhaps some other method could be found to accommodate these different requirements, there could even be an easy to use "VOIP/P2P" selection in the conntrack page, which would set a longer timeout suitable for the majority of VOIP systems.

    What part of the VOIP procedure does the short timeout break, call setup, operation, what exactly?
  3. occamsrazor

    occamsrazor Network Guru Member

    I also had this problem when I tried to set unreplied UDP to 10 (I use UDP for SIP transport on Linksys SPA-3102). Changing it back to 30 fixed it. Actually I think 25 was OK too, but I put it to 30 just in case. Currently am running with UDP/Unreplied = 30, UDP/Assured = 60 and having no problems.
  4. Toastman

    Toastman Super Moderator Staff Member Member

    Looking around for any reports on this, trying to see what is breaking and why ... there's a lot of stuff going back years. Some of it may still be relevant. I'm going to dump some links here temporarily. I see some of mango's posts in there LOL

    So in many cases, reducing the unreplied timeout to 10 is the fix? Yuk. This is getting rather involved. What worked for Occamsrazor seems to do the exact opposite for these guys. But "timing" seems to be emerging here ...
  5. Mango

    Mango LI Guru Member

    Hello, Toastman. Thank you very much for your consideration to this.

    There are actually two problems. I apologize for being slightly long-winded, but I will describe them just so what I am talking about is clear. The first problem is to be expected and it is not a bug. If the Assured UDP Timeout is less than the NAT Keep Alive interval on the VoIP device, the VoIP device will not communicate often enough with the VoIP server, the NAT hole will be closed, and incoming calls will sporadically not arrive. Tomato's default Assured UDP Timeout of 180 is perfectly adequate for this and in my opinion this should be left as it is. All the VoIP devices I've investigated so far use an interval of 15 to 30 seconds. However, most articles I have read about timeouts for VoIP give very low recommendations such as 10 or 25, which will usually not work properly. As you quoted I usually recommend 300 but that's more to be extra conservative than anything else and Tomato's default of 180 should work fine too.

    The second problem might be a bug, but I am not knowledgeable enough to know for sure :) I have had this occur when my ISP changes my public IP address. Some people report that this issue occurs upon restarting the router, but I have not experienced this. When the entries in /proc/net/ip_conntrack are inspected it appears as if Tomato is using the wrong IP address. Since the VoIP device cannot receive a response from the VoIP server, the connection is treated as unreplied. However if the Unreplied UDP Timeout is greater than the interval at which the VoIP device communicates with the VoIP server, the entry with the wrong IPs will stay there indefinitely. If the Unreplied UDP Timeout is set to 10 seconds, then the bad connection will time out, and will be recreated (with the correct IP address) within a few seconds. This time, a response will be received from the VoIP server and it will be treated as assured.

    The last link that you posted - - is what helped me understand this one and it describes things in more detail.

    This specific post in one of the threads provides another workaround for the problem. If, when WAN UP is run, LAN traffic is blocked for the length of the unreplied timeout, the problem does not occur:

    occamsrazor, I am curious that the opposite to what solved the problem for me seemed to solve your problem. What were the symptoms to your problem? On the SIP tab of your SPA-3102, what is your NAT Keep Alive Intvl? Also, if you would permit me to ask, who is your VoIP provider?

  6. occamsrazor

    occamsrazor Network Guru Member

    Current settings:
    On SPA-3102:
    NAT Keep Alive Intvl: 30
    SIP Provider: (virtual pbx which itself registers to a number of SIP providers, my SPA-3102 only registers directly with PBXes)
    SIP Port: 36999 (or sometimes 80 or 5061)
    SIP Transport: UDP
    On Tomato:
    UDP Unreplied: 30
    UDP Assured: 60

    Mango, to be honest I can't remember the specifics of my problem, it was a while ago. For ages I had used the Tomato defaults, but then got to reading Toastman's QoS thread where (I think) it was suggested to use lower values of Unreplied=10. That was when I started having some problems, and eventually I worked out that by increasing it the problems went away.
    Sorry I can't be more specific, the previous posts are probably in the forum somewhere but I can't find them. On the other hand, my recollection of all this could well be totally wrong
  7. Mango

    Mango LI Guru Member

    I think I found the thread you're referring to. It also says Assured 10 and with your Keep Alive Intvl, that would indeed cause problems. Thanks for posting your settings - assuming you never have registration problems, now we know that a NAT Keep Alive Intvl equal to the Unreplied UDP Timeout will also work.

    The thread also says this:
    What VoIP applications require an Unreplied UDP Timeout of 25? Maybe I can do some testing with those and see if I can figure out some settings that will satisfy both these applications and the devices that I work with. I genuinely hope they're not mutually exclusive.
  8. Toastman

    Toastman Super Moderator Staff Member Member

    Mango, that warning was put there because somebody else also mailed me with a comment, he wasn't very clear on which timeout value, and his explanation may have been wrong anyway. But I thought I ought to post the warning message that you quote.

    Any tests you can do will be useful. If nothing else, at least we can bring people's attention to the fact the problem MAY occur and how to try to fix it. One of the biggest problems is that this kind of question gets answered in the forums, time passes, the answers get lost in time - and so on.
  9. Mango

    Mango LI Guru Member

    Ah, I see. If those were reversed, (Unreplied 10 / Assured 25) it would be compatible with (IIRC) Linksys, Grandstream, and Gigaset devices, but not Polycom. Perhaps he got it backwards.

    Do you have an opinion about whether the Public IP Change problem is a bug or not?

  10. Toastman

    Toastman Super Moderator Staff Member Member

    I don't know. All seems to be a bit of an accidental mess to me, exactly what the best solution is, or if there even IS a best solution, I don't know either.
  11. Toink

    Toink Network Guru Member

    In my Tomato:
    UDP Timeout: Unreplied = 30; Assured= 180

    In my Linksys SPA3102:
    Provisioning: OFF (I set mine manually)
    Proxy Fallback Intvl = 60
    Register Expires = 180
    SIP Transport: UDP
    SIP Port: 5060

    SPA3102 Firmware version:
    VOIP Provider:
  12. Mango

    Mango LI Guru Member

    Hi Toink, do you have NAT Keep Alive enabled? If so, what is your NAT Keep Alive interval? Do you ever have problems where the device fails to register, yet VOIPMyWay is working?
  13. Toink

    Toink Network Guru Member

    NAT Keep Alive is enabled on Line 1 of my SPA3102... Now for the love of me, my eyes are failing me! :eek: I can't seem to find the NAT interval in the SPA3102 settings. (would you mind pointing me at the right place). I was thinking those Proxy Fallback Intvl and Registration Expiry are already the settings for NAT...

    As far as I know, besides the settings I posted earlier and my voip credentials, everything else is at stock settings n the SPA3102.... Oh, I have also set in the
    Regional settings:

    FXS Port Input Gain: 6 and the FXS Port Output Gain: 0;
    Off Hook Warning Tone: 480@-10,620@0;10(.125/.125/1+2);
    and the daylight saving rule to: start=3/8/7/2:00;end=11/1/7/2:00;save=1

    But I don't think they would matter :biggrin:

    So far everything's working great with By the way, I'm only using Line1 and nothing connected on PSTN Line.
  14. occamsrazor

    occamsrazor Network Guru Member

    OK, so this is weird... As I mentioned before I've had no problems with SIP registrations recently using these settings:

    On SPA-3102:
    NAT Keep Alive Intvl: 30
    SIP Provider: (virtual pbx which itself registers to a number of SIP providers, my SPA-3102 only registers directly with PBXes)
    SIP Port: 36999 (or sometimes 80 or 5061)
    SIP Transport: UDP

    On Tomato:
    UDP Unreplied: 30
    UDP Assured: 60

    This is on WL-500GPv2 running Victek K24 RAF v1.28.8520 ND USB VPN. Yesterday night I reflashed to K26 RAF v1.28.8623+USB+VPN... without resetting NVRAM or changing any settings (Yes, I know about resetting NVRAM, but until someone comes up with a user-friendly way to re-enter all the info such as static IPs, QoS classifications etc, I don't have the time to do it manually every time....)

    By morning, the Linksys box had become de-registered. I pulled the power plug on the Linksys and restarted it, but the registration still failed. Only by changing the SIP Port in Line 1 tab could I get it to re-register. I've had this problem before in the past - changing the SIP port allows it to re-register, eventually it de-registers, and changing the port back gets it working again. It seems that there is something on that port to that device that is "stuck".

    What does this all mean? I've absolutely no idea but thought I should report it in case it's of help :) That said, things that spring to mind are:

    1. Isn't it only the K26 builds that have the "Other timeouts: Generic, ICMP" fields available to set? Mine are (default) Generic=600, ICMP=30. Could this be relevant? I could be wrong, but I don't remember these Generic/ICMP timeouts on K24.

    2. The above quote is from post #4 of this thread. In the spirit of this I'm going to try UDP Unreplied=30, NAT Keepalive on Linksys=60, UDP Assured=180..... and see what happens

    (EDIT) 3. I should also add that the SIP Tracking / NAT Helper is checked ON. I can't remember if I had it on in the K24 build, or whether this is relevant or not.
  15. Toink

    Toink Network Guru Member


    In my SPA3102, I only have the following in the NAT settings (Line 1 Tab):
    Nat Mapping enabled, NAT Keep Alive Message, NAT Keep Alive Enable, and NAT Keep Alive destination....

    Where exactly is "NAT Keep Alive Intvl" ?
  16. occamsrazor

    occamsrazor Network Guru Member

    Voice Tab > SIP Tab (not Line1 tab) > then all the way down to the bottom line on the right hand side
  17. Toink

    Toink Network Guru Member

    Ok, found it, thanks!... I got mine set to 15
  18. kosiko

    kosiko Addicted to LI Member

    Oh, just see you still experiencing the issue. I have the same router, GP500V2 and i loaded 1.28 K26 R1 build 54. During my previous trouble shooting I turned off SIP Tracking/NAT Helper in Tomato and I just keep it off. I rebooted my router couple times and my ATA work perfectly now.

    BTW, I used the same setting as you mentioned above, 30, 60, 180, i hope this help.
  19. occamsrazor

    occamsrazor Network Guru Member

    OK, I'm using 30,60,180 like you - but with the SIP Helper ON - so if that setup works for both of us, we should be able to assume that the SIP Helper isn't the problem. So far it hasn't de-registered.....
  20. kosiko

    kosiko Addicted to LI Member

    Good to hear. yeah, I think the major issue is the NAT interval time. And also this link explained a lot:

    If you still have problem you can try the WAN script or check /proc/net/ip_conntrack by following this link:

    The links were provided by Mango in the previous post
  21. Mango

    Mango LI Guru Member

    That's pretty classic. So now we know that the Unreplied UDP Timeout must be at least a few seconds less than the NAT Keep Alive Intvl.

    I believe those are newish. To my knowledge VoIP doesn't use ICMP, and the Generic timeout shouldn't come into play since the VoIP UDP connections do have their own timeout setting.

    Good idea. That should make things work properly.

    I don't think I have that on Teddy Bear 1.27; can anyone link me to a description of what SIP Tracking does?

    If anyone has any information about whether occamsrazor's symptoms above are a bug in Tomato, or if it's just the timeouts working the way that they are supposed to, I would be interested. Then we can decide what we should do about it.

  22. occamsrazor

    occamsrazor Network Guru Member

    If you have it it's in Advanced > Conntrack / Netfilter > Tracking / NAT Helpers
    In the latest builds there are options for:

    GRE / PPTP

    I am not sure but I think it is something like this:
  23. Badders44

    Badders44 LI Guru Member

    What a wonderful thread! I've been struggling for months to explain why my PAP2T keeps losing it's connection. The connection to the internet would stay but the line connection would drop after a while. I guess it started happening after upgrading to a firmware with shorter timeouts.

    So far, no drops :)
  24. Mango

    Mango LI Guru Member

    I'm glad to hear this thread is helping people. But what can we do to solve the problem in future releases of Tomato? Who do we have to convince?
  25. Toastman

    Toastman Super Moderator Staff Member Member

    Convince of what? We know there is an issue/conflict, that's what is important. You see, I know of several these devices belonging to colleagues that work with the default timeouts without any reported problems. The conntrack timeouts are often made short - dependent on many issues, but for the majority of users short timeouts will be of most benefit. Should they be made "long" again? I don't know. The most important things is to make sure this information is available and easy to find. Placing it on as many forums as possible will help, as will a description in the wikis
  26. Mango

    Mango LI Guru Member

    That is indeed possible. For example, it could be that they have NAT Keep Alive disabled and their provider handles Keep Alive on the server side instead at an appropriate interval. Or it could be that they have a static IP address, or their ISP changes their public IP address infrequently.

    I agree that short timeouts will be beneficial - Unreplied 10 certainly. But the default is that they are already long, isn't it? When I installed Tomato the defaults were 30/180.

    I have a question about what appears in /proc/net/ip_conntrack if you will permit me. I'm trying to understand exactly what is going on when the problem occurs. Let us consider a line like this:

    udp 17 27 src= dst= sport=5060 dport=5060 [UNREPLIED] src= dst= sport=5060 dport=5060 use=1 mark=257

    What appears after [UNREPLIED] is what we expect of return packets, correct? I notice the dst= is a 192 address. When things are working properly, this is the router's public IP address.

    Is it that the traffic is arriving, but not being routed to the VoIP device, because the router does not find a matching entry?

    Or is it that when the router sends traffic, the IP header is corrupted because the router reports the destination is, and the VoIP server cannot route traffic to a 192 address over the Internet?

    Happy new year :)

  27. Toastman

    Toastman Super Moderator Staff Member Member

    If it helps, all of them have ISP issuing IP at renewal of lease, which is generally 24 hours. Since all of them are completely non-technical, I am sure everything would be pretty much set to whatever default it had "out of the box".

    Anyway, If anything at all on the WAN side is trying to communicate with an IP of 192.x.x.x that would, to me, be in error. And presumably Tomato reported that IP as it did not yet have a WAN public IP, so this may be correctable by suitable startup timing. While the timeout value change allows things to be put right, I don't think it is the proper solution.
  28. Mango

    Mango LI Guru Member

    That sounds intriguing - how would I do that? :)

    Edit: I just remembered one user worked around this by setting up a WAN UP script that disabled vlan0 for the length of the unreplied UDP timeout. Is this what you mean?
  29. Toastman

    Toastman Super Moderator Staff Member Member

    That sort of thing, yes, but I would think that things should be arranged so that Tomato simply isn't capable of reporting the wrong address to the ISP, if that is indeed what is happening. It may just be a matter of delaying something or changing the order in which it fires up. Or a deliberate wait until a public IP is received, it really depends on the result of a proper investigation of what happens. Or, it could well be I'm talking nonsense. I'm the wrong person for this, though I'm interested in a cure, it needs someone with better knowledge of Tomato than I to look at what is happening during startup.

  30. Mango

    Mango LI Guru Member

    More information...

    Toastman gave me an idea (Thank you Toastman :)) about how to investigate what is going on in more detail.

    I used a hub and Wireshark to make some captures. I was able to cause the behaviour with one of my VoIP devices and not the other. The following captures were taken a few minutes from each other. With this one, the VoIP device could not send or receive any data from the VoIP server:

    The output of grep /proc/net/ip_conntrack:
    udp 17 16 src= dst=PBX_IP sport=5060 dport=5060 [UNREPLIED] src=PBX_IP dst= sport=5060 dport=5060 use=1 mark=257 l7proto=sip

    For reference, this is how the capture looked on the device that was working properly:

    The output of grep /proc/net/ip_conntrack:
    udp 17 31 src= dst=PBX_IP sport=5061 dport=5060 src=PBX_IP dst=MY_PUBLIC_IP sport=5060 dport=5061 [ASSURED] use=1 mark=265 l7proto=sip

    In both the Wireshark captures and /proc/net/ip_conntrack, a 192 address appears when it shouldn't, when the undesired behaviour is occurring.

    I also worked out how to reproduce the behaviour with a softphone, in case someone who is able to test this further does not have any VoIP equipment. One way you could do this is with Zoiper (I have version 2.24) and a free IP Freedom account from Callcentric.

    1. Configure Zoiper to your Callcentric or other VoIP account, making sure to disable the option "Register on Startup".
    2. Configure your Tomato router's UDP Settings to the default: Unreplied 30 / Assured 180.
    3. Configure your PC with a static IP so that it does not need to obtain an IP address with DHCP upon the router rebooting.
    4. Reboot your Tomato router.
    5. Press the Register button within Zoiper so that Zoiper will begin registration attempts before the router has finished rebooting.
    6. Once the router has rebooted and has obtained a public IP address from the ISP, inspect /proc/net/ip_conntrack to see if the issue has occurred.
    7. If desired, inspect communications between Zoiper and the VoIP server with Wireshark to see if the IP header is invalid.
    Note that if Zoiper fails to register, it may crash. So you should quit Zoiper and re-start it before testing again.

    I haven't worked out how to cause this upon changing the public IP. In this case, /proc/net/ip_conntrack reports the old IP address as dst=, not the new one. After I change the public IP address a few times, the behaviour happens, but I don't yet know how to reproduce it reliably.

    I have Tomato Firmware v1.27.8747 ND USB Std but since the issue has been reported by so many people I suspect it's not version specific.

    Many thanks to anyone who has more knowledge than me that can move further with this.

  31. Mango

    Mango LI Guru Member

    Is there any way to force the router to immediately drop all open connections? Perhaps if we set that as a WAN UP script that would do the trick.
  32. occamsrazor

    occamsrazor Network Guru Member

    Just to report back... I've been running it with:

    UDP Unreplied=30, NAT Keepalive on Linksys=60, UDP Assured=180

    ...for over two weeks now without any dropouts...
  33. Mango

    Mango LI Guru Member

    A user on the forums has just run into a new version of this issue. I told him to check /proc/net/ip_conntrack and this is what he found:

    Look at that!! Nearly an hour to go before that connection will expire! No wonder he is having problems! I had him check the nvram for any mention of 3600 to see if some other timeout was being applied, but all he found was this, which I think is probably irrelevant:

    I had him set his WAN UP script to this:

    ifconfig vlan0 down
    echo "10" > /proc/net/expire_early
    sleep 11
    ifconfig vlan0 up

    Which, on my router, drops all connections, assuming there is no incoming data from the WAN for 10 seconds, which was the case for him, but the connection remained.

    He is using: Tomato Firmware v1.28.9054 MIPSR2-beta K26 USB vpn3.6 on an Asus RT-N16.

    The user's handle is bellamr. The thread in question is and the important part starts at post #1511.

    Hypothetically, if I raised a bounty to get this fixed, who should I approach, and approximately what amount would pique their interest?

  34. Bill_S

    Bill_S Network Guru Member

    I have one of my routers running DD-WRT. I have been trying to find the same settings that I have in Tomato for UDP Timeout but all I can locate is a single setting for UDP timeout that is by default set to 120. Does anyone know if this is one of the two settings used in the Tomato firmware and if so which and where I can find the other setting in DD-WRT?
  35. Mango

    Mango LI Guru Member

    Teddy Bear, I can't seem to reply to your PM for some reason. But to answer your question, I have ADSL/DHCP and I just checked with another user who can reproduce the problem and has ADSL/PPPoE.
  36. shap123

    shap123 LI Guru Member

    I had the same problem - I found that if you turn on SIP Helper, all UDP SIP connections will get 3600 sec timeout, regardless what you specify for UDP timeouts in Tomato GUI.
  37. Mojonba

    Mojonba Network Guru Member


    I have been having a problem described here in this thread about my SP2102 not registering after a router reboot (wrt54g w/ Tomato 1.28). The only way i have found to re-register my ATA box is to change my sip server address and then reverting it back to the original. (i.e. I use and I have to change to and then to again). This is a hassle. I read about changing UDP timeout values but it also says it may affect your router stability if you use torrents. If I use torrents, what is a good compromise for this values? Isn't it better to just change the NAT Keep Alive value on the SPA2102?

  38. shap123

    shap123 LI Guru Member

    Well, as you said, in this thread this issue is fully covered. So just follow the people recommendations.
    NAT Keep Alive should be set to value between UDP Unreplied Limit and UDB Assured Limit (in Tomato). However, Keep Alive is not the only problem. You should change the "Reg. Retry. Interval" to be also in this interval - I suggest 60 sec.
  39. mister_e

    mister_e Networkin' Nut Member

    Interesting thread - I am having a similar issue with Asterisk. Anyone able to shed some light on the Asterisk side of things?

    Many thanks in advance.
  40. lfjeff

    lfjeff Networkin' Nut Member

    After experiencing timeout issues with several of our VOIP phones, I read all the suggestions in this thread and did some experimenting with settings. Here's what has been working for me for almost a week with no problems:

    Phone settings:
    NAT Keep-Alive Interval: 30
    Registration Retry Interval: 35

    Router Settings:
    UDP Timeout Unreplied: 25
    UDP Timeout Assured: 60
  41. Mango

    Mango LI Guru Member

    Great to hear things are working for you. If you don't mind me asking, what does Registration Retry Interval do? It doesn't sound like that's how often the device registers because 35 would be too short; am I correct?

    Do you have a SunRocket ATS 6011s?

  42. lfjeff

    lfjeff Networkin' Nut Member

    My phones are Cisco/Linksys SPA-941

    Here is how I understand things, based on what I have observed...

    The "Registration Retry Interval" is how long it will wait to attempt a new registration after a failed attempt.

    The length of my registration is 120 seconds (not sure where that is set, it may be under the control of my VOIP provider). When that expires, the phone will immediately re-register. If that fails, it will wait 35 seconds before it tries again.
  43. tobiastromm

    tobiastromm Networkin' Nut Member

    Hi :)

    I'm having this problem too after my router reboot.

    3CX VoIP and VPN Server -> Internet <- DD-WRT - GrandStream HT 488

    I have DD-WRT and have already change UDP timeout to 10s (but DD-wrt has only one value to change).

    After do this FXS port is working fine. But FXO port problem persist.

    FXS port after reboot:

    udp 17 3569 src= dst= sport=5062 dport=5060 packets=49 bytes=23100 src= dst= sport=5060 dport=5062 packets=33 bytes=15090 [ASSURED] mark=0 use=8

    FXO port after reboot:

    Destination is incorrect! Why?

    udp 17 3590 src= dst= sport=5065 dport=5060 packets=121 bytes=54934 [UNREPLIED] src= dst= sport=5060 dport=5065 packets=0 bytes=0 mark=0 use=2

    More information about my setup can be found and

    I apreciate any help.

    Thank You.
  44. aleko

    aleko Network Newbie Member

    A message from the future for desperate ddwrt users, struggling with the same issue.

    ddwrt GUI lacks the "Unreplied UDP Timeout" field, but you can still set it directly, e.g.

    # ddwrt default is 65
    echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

    (btw "Assured UDP Timeout" is stored in /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream)

    To persist changes after reboot, you need to add your command to crontab or "startup scripts".
    In my case I had to shove the damn assignment into crontab, because either the startup command fails sometimes or the value gets reset eventually :mad:.

    Ensure your router's "/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout" value is always less than keep-alive and re-register intervals on your phones/ATAs
    Last edited: Apr 19, 2016
  45. aleko

    aleko Network Newbie Member

  46. koitsu

    koitsu Network Guru Member

    Further expanding on this for users who want to know:

    /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout is controlled via GUI option Advanced -> Conntrack/Netfilter -> UDP Timeout -> Unreplied
    /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream is controlled via GUI option Advanced -> Conntrack/Netfilter -> UDP Timeout -> Assured

    Both of these netfilter tunables are maintained through the NVRAM variable called ct_udp_timeout. This variable is a string consisting of two unsigned integers (space-delimited): the first is Unreplied, the second is Assured. Example: nvram set ct_udp_timeout="30 180"

    The default values for these two settings is 30 (Unreplied) (not 65!) and 180 (Assured), and is hard-coded into the netfilter code as part of the Linux kernel. Proof is on lines 30-31 and 151-166:

    The netfilter tunable ip_conntrack_udp_timeout is within the base netfilter/ip_conntrack code, which is statically included in the kernel in Tomato -- it is not a module. In other words, it cannot be unloaded/reloaded by anything dynamically.

    You can see the Tomato-specific code for all of this here:

    * -- this is the GUI page itself. There is a large amount of Javascript involved. When clicking "Save", several HTTP POST params are set, which are then submit back to the tomato webserver through the "fake" CGI called tomato.cgi (keep reading). You can see that referenced as the <form> action. The code here is difficult to read/understand, sorry to say.

    * -- this is the core part of tomato.cgi. Search for "udp" -- you get to read the code yourself. The write_ct_timeout() routine is most relevant here. You can see it keys off of the ct_udp_timeout NVRAM variable.

    On Tomato, there is absolutely no need for Administration -> Scripts, or a cronjob, to manage these netfilter tunables. In fact, if you were to stick stuff into Administration -> Scripts, you would be "fighting" with the Tomato GUI. Every time you'd click "Save" in the GUI, it'd stomp over whatever you had in Scripts. To be consistent, you need to use the GUI for this.

    Hope this helps and sheds light on everything, with actual proof and code references.
    Monk E. Boy likes this.
  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