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

Tomato dropping high frequency incoming ICMP pings. How can I fix this?

Discussion in 'Tomato Firmware' started by Morac, Feb 2, 2012.

  1. Morac

    Morac Network Guru Member

    I have my Cisco E3000 running with Toastman 1.28.7495-RT-Ext setup up to respond to pings, i.e. "Respond to ICMP ping" is checked. I do this so I can run line quality tests on my home connection when I'm having problems and the like. Also so I can check to see if my connection is working correctly and check for jitter/loss while not home.

    This used to work fine on WRT54GL running an old load of toastman, but on the E3000 if incoming pings come in too quickly they are dropped. As such all line quality tests fail. This is very easy to see when using DSLReports line quality tool as you can see from these results. Pings don't even need to come in that fast as pings also fail with Network tools ping test. Basically the router drops pings that come in more often than about once a second. I don't have QOS enabled, so that shouldn't be the problem.

    This is only incoming pings. Response to outbound pings will come in as fast as I can send them out (dozens a second).

    This has been happening at least since at least Toastman 1.28.7486.2 since that's when I first noticed the problem. I've seen two other reports of the same problem with Tomato (at least one with a Cisco E3000), one person solved this problem by flashing DD-WRT so the problem is with Tomato.

    Any ideas what's wrong here or is Tomato purposely dropping incoming pings? If so how can I disable that?
     
  2. Planiwa

    Planiwa LI Guru Member

    This appears to be a problem with the RT-N16 as well, when pinging the router.

    It seems that the router responds to about 1 ping a second, no matter how many (more) pings it receives.
     
  3. kthaddock

    kthaddock Network Guru Member

    Yes, there is a limit there is 5-fast ping and then only every 1-sek.
     
  4. Planiwa

    Planiwa LI Guru Member

    Code:
    N16:root    iptables -vL |grep -i icmp
    20378 1709K ACCEPT    icmp --  any    any    anywhere            anywhere            limit: avg 1/sec burst 5
    
    So, the OP could simply make an iptables rule to delete that one, or replace it with another one.
     
  5. Morac

    Morac Network Guru Member

    I'm not familiar with iptables. What does that rule do exactly? Also why is there even a limit?

    Also there doesn't appear to be any limits on ping replys in my testing. I don't see anything in that rule that says it's specifically for echo-requests so wouldn't it block replys as well?
     
  6. Planiwa

    Planiwa LI Guru Member

    The actual rules are in /etc/iptables:
    Code:
    iptables -A WANPREROUTING -p icmp -j DNAT --to-destination 192.168.0.1
    iptables -A INPUT -p icmp -m limit --limit 1/second -j ACCEPT
    
    Burst default is 5.

    So, you could send 5 quick pings:
    Code:
    date; sudo ping -c 5 -i .1 ...; date
    Thu  2 Feb 2012 14:48:22 EST
    ...
    5 packets transmitted, 5 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 129.708/172.206/196.752/26.342 ms
    Thu  2 Feb 2012 14:48:22 EST
    
     
  7. Toastman

    Toastman Super Moderator Staff Member Member

    If you ping someone, obviously that is something you did intentionally and the replies are expected. However, if somone out there in the world decides to mount a DOS attack on your router using ICMP (quite common from China) the router's firewall limits the frequency of replies. This is quite a normal function of a router's firewall. By default, many (including Tomato) don't reply to ICMP pings at all.
     
  8. Morac

    Morac Network Guru Member

    I've been having connection problems at home so I'm using a "smokeping" service to ping periodically for packet loss and I can't tell if I'm actually experiencing packet loss or if the pings are being blocked.

    Is there a way to put in exceptions for specific ip addresses? That way the default rule will block DOS attacks, but allow pings to come in from the test site.

    I'm not at all familiar with iptable notation so any help with this would be appreciated.
     
  9. Planiwa

    Planiwa LI Guru Member

    FWIW, this is the iptables rule from /etc/iptables:
    Code:
    -A INPUT -p icmp -m limit --limit 1/second -j ACCEPT
    
     
  10. Morac

    Morac Network Guru Member

    Which is the same thing posted in post #6 and doesn't tell me how to exempt certain ip addressed from that rule.

    So no one knows how to do this?

    If I understand correctly I should be able to simply insert a rule to accept pings from whatever ip addresses I like as long as I insert it before the default rule is that correct? So for example if the ping limiter rule in #5 would the following allow unlimited pings from 4.4.3.3?

    iptables -I INPUT 5 -p icmp -s 4.4.3.3 -j ACCEPT

    Edit:

    To answer my own question, the above works. As long as the ip address doesn't change I can now run tests without the limiter kicking in for whatever ip addresses I add using the line above.
     
  11. koitsu

    koitsu Network Guru Member

    I solved this problem cleanly/correctly by placing the following under Scripts -> Firewall. I've used this with TomatoUSB (both official and Toastman builds) reliably for over a year.

    #
    # The default permit-ICMP rule has "limit: avg 1/sec burst 5" applied to it,
    # which makes a mess of ingress mtrs/traceroutes. The below replaces the
    # rule with a "non-limit" rule, allowing the kernel to limit ICMP
    # entirely via /proc tunables. The end result is that this gets us
    # ping/mtr results (ingress) that lack packet loss.
    #
    num=`iptables -L INPUT -n --line-numbers | egrep 'ACCEPT.+icmp' | cut -d' ' -f1`
    iptables -R INPUT $num -p icmp -j ACCEPT
    #
    # We also need to set icmp_ratelimit to 0 (no rate limiting) to ensure
    # that both egress and ingress mtr/traceroutes aren't affected.
    #
    echo 0 > /proc/sys/net/ipv4/icmp_ratelimit

    The first part of the script replaces (think: deletes) the default ICMP-rate-limiting rule with the exact same rule but without the rate-limiting flags. The 2nd part adjusts the Linux kernel tunable (which is really what these firmwares should be using instead of iptables for rate-limiting ICMP) since it also plays a role. You can read about the tunable by Googling for it.

    Ignore the nonsense about "people DoS'ing your router with ICMP" -- nothing stops someone from doing the exact same thing with TCP SYN, UDP, or any other kind of inbound packet. Most denial-of-service attempts today are done with one approach in mind: saturate the network connection. This can be accomplished with any kind of packet, not just ICMP.

    The only thing the ICMP rate-limiting rule does is ignore (drop) inbound ICMP ECHO once a certain rate has been exceeded. All this does is cause the kernel to not *respond* with ICMP ECHO_REPLY to the remote host. Thus, the iptables ICMP rate-liming rule really solves absolutely nothing when it comes to an inbound DoS; all it stops is the kernel from responding with ICMP ECHO_REPLY. That's all, nothing more.

    Simply put: this rule needs to be removed from the default list of rules installed by the firmware, OR ALTERNATELY, the rate-limiting values passed via --limit need to be made adjustable via the GUI (and/or the --limit flag disable-able entirely).
     
    Planiwa likes this.
  12. macfreak

    macfreak Network Newbie Member

    Hi, I'm running Tomato Version 1.28 by shibby on an ASUS RT-N12D1.
    Inserted your code in administration > scripts > firewall, pressed save and the results are still the same. Rebooted router and still the same. Do you have an idea where to look now ?
    It seems like a very good idea to just get rid of this ICMP rate limiter. One can't test whether the connection is good or bad. It's a bummer.
     
  13. Morac

    Morac Network Guru Member

    Old thread, but it doesn't look like icmp_ratelimit needs to be changed because by default that doesn't apply to echo requests.

    http://man7.org/linux/man-pages/man7/icmp.7.html

    As for limiting ping replies, with most home broadband being asymmetrical, limiting might not be a bad idea. My home connection is 100 Mbps down and 10 up. If someone sends more than 10 Mbps of echo requests (but less than 100 Mbps), with limiting I can still use my connection as it won't use any upstream bandwidth at all. Without limiting the echo responses would saturate my upstream, so something as little as 15 Mbps of ping requests would kill my connection despite having 100 Mbps downstream. Not to mention probably melt the CPU in the router which already spikes to close to 90% during speed tests.
     
    Last edited: Apr 18, 2014
  14. macfreak

    macfreak Network Newbie Member

    Well I can't even run a test on www.pingtest.net (says blocked by firewall). www.speedtest.net runs ping test for 20 seconds before anything else happens. I think that's odd. Isn't it ?
     
  15. Morac

    Morac Network Guru Member

    Pingtest.net uses outbound pings (using Java) so it's not affected by this. Something else is causing your problem. If you use NoScript or Adblock that can interfere with the test.
     
  16. macfreak

    macfreak Network Newbie Member

    If I connect my computer directly to the modem, I can do ping test just fine, so the problem must be the router, I think.
     
  17. Morac

    Morac Network Guru Member

    Do you have the option to allow incoming pings checked?

    It's the "Respond To ICMP Ping" on the Advanced -> Firewall page. By default it's not checked and the router won't respond to any incoming pings.
     

Share This Page