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

Shibby K24 ICMP Ping Issue

Discussion in 'Tomato Firmware' started by Azuse, Jul 29, 2012.

  1. Azuse

    Azuse LI Guru Member

    Wasn't sure where to put this, so here seems as good as any.

    I have a 54GL that's been running RAF mod for several years now. I loaded Shibbys K24 tomato-ND-1.28.5x-093-VPN onto it on Monday and since then it's been unable to correctly respond to ICMP pings e.g. this is what happened when I loaded it: [​IMG]

    Curiously it's shifted into a distinct pattern: [​IMG]

    Oh and another sever just to be sure: [​IMG]

    Now I'm no programmer but here are couple of observations.
    • It occurs with both the VNP & SD-VPN builds.
    • It occurs after clearing the nvram thoroughly and manually entering settings manually (several times) as well as after re-flashing.
    • There is no packet loss, it's just the router eating ICMP pings.
    • RAF mod had an identical issue a couple years back (when the xbox upnp broke iirc) - perhaps some underlying bug?
    • I've seen a few people with similar issues on K26
    How would I go about determining why this is happening?
     
  2. Azuse

    Azuse LI Guru Member

    Well this is interesting. It seems the IGMPproxy also won't work, with the same results in 88E as 93E.

    Code:
    Jul 30 17:08:34 router user.debug kernel: vlan1: dev_set_allmulti(master, 1)
    Jul 30 17:08:34 router user.err igmpproxy[593]: Vif #1 was already upstream. Cannot set VIF #2 as upstream as well.
    Jul 30 17:08:35 router user.debug kernel: vlan1: dev_set_allmulti(master, -1)
    Jul 30 17:08:35 router user.debug init[1]: igmpproxy terminated unexpectedly, restarting.
    Jul 30 17:08:35 router user.debug kernel: vlan1: dev_set_allmulti(master, 1)
    Jul 30 17:08:35 router user.err igmpproxy[597]: Vif #1 was already upstream. Cannot set VIF #2 as upstream as well.
    Jul 30 17:08:35 router user.debug kernel: vlan1: dev_set_allmulti(master, -1)
    Jul 30 17:08:36 router user.debug init[1]: igmpproxy terminated unexpectedly, restarting.
    Jul 30 17:08:36 router user.debug kernel: vlan1: dev_set_allmulti(master, 1)
    Jul 30 17:08:36 router user.err igmpproxy[598]: Vif #1 was already upstream. Cannot set VIF #2 as upstream as well.
    Jul 30 17:08:36 router user.debug kernel: vlan1: dev_set_allmulti(master, -1)
    Jul 30 17:08:36 router user.debug init[1]: igmpproxy terminated unexpectedly, restarting.
    
    I'm not using any vlans :(
     
  3. rokr1

    rokr1 Networkin' Nut Member

    Hi Azuse,

    Just a suggestion, have you disabled ICMP limit per second option under Advance -> Firewall
     
  4. Azuse

    Azuse LI Guru Member

    No such setting, and iirc it was the N16 that had that issue on the k26 builds. IGMPproxy is a bigger issue for me in fairness.
     
  5. Azuse

    Azuse LI Guru Member

    Ok. It appears the rate limit from the k26 builds (not present in the RAF mod, but that's a year old) has made it's way into the k24 Shibby builds - but the gui option to remove it has not. Used the solution here.

    Code:
    ACCEPT    icmp --  anywhere            anywhere            limit: avg 1/sec burst 5
    
    However that doesn't explain why the IGMPproxy isn't working

    Code:
    Jul 30 23:20:29 router user.debug kernel: vlan1: dev_set_allmulti(master, 1)
    Jul 30 23:20:29 router user.err igmpproxy[1825]: Vif #1 was already upstream. Cannot set VIF #2 as upstream as well.
    Jul 30 23:20:29 router user.debug kernel: vlan1: dev_set_allmulti(master, -1)
    Jul 30 23:20:29 router user.debug init[1]: igmpproxy terminated unexpectedly, restarting.
    
     
  6. koitsu

    koitsu Network Guru Member

    You know that IGMP is multicast, correct? And IGMP has nothing to do with ICMP. Did you enable multicast support? Do you really have a need for multicast (do you even know what it is / what purpose it serves? :) I say that sincerely not condescendingly) To me it looks like you enabled it (for reasons unknown) and likely nobody has tested this feature in a very, very long time, thus it's broken.

    I can't help debug the IGMP issue without you providing full, unedited output of ifconfig -a.

    The ICMP rate-limiting problem you've solved via the post I provided a while back. Congrats. If you'd rather have it fixed "officially" (e.g. no need for a Scripts entry), you can run one of the latest Toastman builds and there is a new checkbox that lets you actually disable the rate-limiting part of the rule entirely (Advanced -> Firewall -> uncheck Limit PPS).
     
  7. Azuse

    Azuse LI Guru Member

    I do, it just seemed better than starting a new thread.

    Code:
    br0 Link encap:Ethernet HWaddr 00:16:B6:ED:EA:E7
    inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1323955 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1737432 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:94685651 (90.2 MiB) TX bytes:1692581879 (1.5 GiB)
     
    eth0 Link encap:Ethernet HWaddr 00:16:B6:ED:EA:E7
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2222865 errors:13 dropped:0 overruns:4 frame:4
    TX packets:2107399 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1746515714 (1.6 GiB) TX bytes:1164453581 (1.0 GiB)
    Interrupt:4 Base address:0x1000
     
    eth1 Link encap:Ethernet HWaddr 00:16:B6:ED:EA:E9
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:862040 errors:128 dropped:0 overruns:0 frame:220517
    TX packets:1055655 errors:52 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:70969379 (67.6 MiB) TX bytes:666409005 (635.5 MiB)
    Interrupt:13 Base address:0x5000
     
    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
    RX packets:161 errors:0 dropped:0 overruns:0 frame:0
    TX packets:161 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:13820 (13.4 KiB) TX bytes:13820 (13.4 KiB)
     
    vlan0 Link encap:Ethernet HWaddr 00:16:B6:ED:EA:E7
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:464833 errors:0 dropped:0 overruns:0 frame:0
    TX packets:770859 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:38153990 (36.3 MiB) TX bytes:1048308071 (999.7 MiB)
     
    vlan1 Link encap:Ethernet HWaddr 00:16:B6:ED:EA:E8
    inet addr:94.193.220.10 Bcast:94.193.220.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1756411 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1334180 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1667415636 (1.5 GiB) TX bytes:115313985 (109.9 MiB)
     
  8. koitsu

    koitsu Network Guru Member

    The log indicates, based on what I can tell:

    1. igmpproxy enables the ALLMULTI flag on the vlan1 interface (the kernel itself logs when this happens)
    2. igmpproxy claims that there is already an interface (not sure which one) which has upstream set in its phyint command. I do not know what VIF#1 is, but I have to assume VIF#2 in this context refers to vlan1.
    3. igmpproxy disabled the ALLMULTI flag on the vlan1 interface.
    4. igmpproxy exits.
    5. Because of how Tomato/TomatoUSB works, certain daemons are expected to be running all the time, thus init sees the daemon having exited and restarts it. Rinse lather repeat.

    For differences between the MULTICAST and ALLMULTI flags on an interface:

    http://serverfault.com/questions/32...ulticast-and-allmulti-ifconfig-ifconfig-flags

    I'm betting you will find the mistake/issue in /etc/igmpproxy.conf, where there are multiple phyint commands being specified with the upstream parameter. I hope you're familiar with IGMP and multicasting because if you're not this is all going to be foreign to you (and in which case I question whether or not you really need multicasting).

    My guess is that some utility/tool/script/something within TomatoUSB (Shibby only? Not sure) is adding lines to /etc/igmpproxy.conf in a moronic fashion so there are multiple entries with upstream in them, thus the daemon won't behave. If this is the case, you should be able to edit the configuration file yourself, fix the problem, and let the daemon restart on its own (via init) and it'll (hopefully) work. If it works, you'll need to do this every time the router reboots. I can probably come up with an Admin -> Script fix for you if that does work around the issue, but I'm not sure if it would go in the Init, Firewall, or WAN Up section. What should honestly happen in this case is that the firmware maintainer should fix the problem in the Tomato/TomatoUSB code. :)

    Here's an example configuration from OpenWRT:

    https://dev.openwrt.org/browser/packages/net/igmpproxy/files/igmpproxy.conf?rev=6090

    From what I can tell you're going to want one interface be upstream and a different interface be downstream, and you can disable multicast on whatever interfaces you don't care about. On TomatoUSB the vlanX interfaces are probably the ones you care about the most.
     
  9. Azuse

    Azuse LI Guru Member

    What's the full name of the directory? By the permission denied messages I assume I'm poking in the wrong place.
     
  10. koitsu

    koitsu Network Guru Member

    By default it's /etc/igmpproxy.conf, but there's no promise that's where igmpproxy on TomatoUSB expects it. It looks like the configuration file path is passed on the command line to the daemon when it starts. How I determined that (note last line, re: usage syntax):

    Code:
    root@gw:/# strings /usr/sbin/igmpproxy | grep config
    configureVifs
    Found config for %s
    Unable to open configfile from %s
    Unknown token '%s' in configfile
    You must specify the configuration file.
    Searching for config file at '%s'
    Unable to load config file...
    Usage: igmpproxy [-h] [-d] [-v [-v]] <configfile>
    
    So, ps w | grep igmpproxy should show you the daemon that's running as well as all arguments, thus where the configuration file lives. I don't run igmpproxy so I can't determine where that might be.
     
  11. Azuse

    Azuse LI Guru Member

    strings /usr/sbin/igmpproxy | grep config produces
    Code:
    [RIGHT][IMG]http://router/spin.gif[/IMG][/RIGHT]
    configureVifs 
    Found config for %s 
    Unable to open configfile from %s 
    Unknown token '%s' in configfile 
    You must specify the configuration file. 
    Searching for config file at '%s' 
    Unable to load config file... 
    Usage: igmpproxy [-h] [-d] [-v [-v]] <configfile> 
    While ps w | grep igmpproxy produces

    Code:
     1610 root      1184 S    grep igmpproxy 
    when it's actually running i.e. between restarts. Frankly this is way beyond me.
     
  12. koitsu

    koitsu Network Guru Member

    You're probably going to have to set up a while loop to catch it when it runs. The problem is that it's running then immediately exiting, thus when manually doing "ps w | grep igmpproxy" it's very unlikely you'll see it (pure luck :) ):

    Code:
    while true; do ps w | grep '[  ]igmpproxy'; done
    
    Let this run while the igmmproxy GUI option is enabled, and eventually it should (hopefully!) catch something. Be aware your CPU load on your router will reach up to 1.00 (100% CPU) when running this; nature of the beast. You can press Ctrl-C to terminate the while loop.
     
  13. Azuse

    Azuse LI Guru Member

    That loop pushed the "cpu load" to 4.12. Resorted to just mashing execute until it produced /etc/igmp.conf. igmpproxy -d /etc/igmp.conf simply produces
    Code:
    Vif #1 was already upstream. Cannot set VIF #2 as upstream as well.
    which we already knew anyway :(
     
  14. koitsu

    koitsu Network Guru Member

    What we didn't know is what the configuration file path was! Now we know it's /etc/igmp.conf. Can you provide the contents of that file? The contents are probably wrong / causing the problem, which has been my theory all along.
     
  15. Azuse

    Azuse LI Guru Member

    Code:
     
    login as: root
    root@router's password:
     
     
    Tomato v1.28.0005 093 ND VPN
    root@router:/tmp/home/root# ls /etc/
    TZ              hosts          nas.conf        resolv.conf
    dnsmasq        igmp.conf      openssl.cnf    resolv.dnsmasq
    dnsmasq.conf    iptables        passwd          services
    dropbear        l7-protocols    profile        shadow
    fstab          ld.so.conf      protocols      upnp
    group          motd            qos
    gshadow        mtab            qoslimit
    root@router:/tmp/home/root# cat /etc/igmp.conf
    quickleave
    phyint vlan1 upstream
            altnet 0.0.0.0/0
    phyint br0 downstream ratelimit 0
    
     
  16. koitsu

    koitsu Network Guru Member

    Hmm. I don't particularly see anything wrong with that configuration. The issue is that the bloody daemon keeps referring to things as "Vif #x" with an arbitrary number, rather than telling me what interface it's referring to.

    Can you try running igmpproxy manually with the following parameters and provide all output? (Note -vv, not -v).

    Code:
    igmpproxy -vv -d /etc/igmp.conf
     
  17. Azuse

    Azuse LI Guru Member

    Code:
    adding VIF, Ix 0 Fl 0x0 IP 0x0adcc15e vlan1, Threshold: 1, Ratelimit: 0 
    Vif #1 was already upstream. Cannot set VIF #2 as upstream as well. 
     
  18. koitsu

    koitsu Network Guru Member

    Weird. I have no idea why the daemon is outputting that message unless there's something I'm missing. The configuration file does not indicate there are two interfaces with upstream specified -- only vlan1 has that defined -- so I am at a loss to explain this behaviour. I should note that Googling shows that other people are seeing a similar problem. Possibly it's some kind of odd logic bug/quirk in igmpproxy, but I have no real hard evidence to back up that claim.

    Sorry I can't be of more help at this point.
     
  19. Azuse

    Azuse LI Guru Member

    Well I've been playing around with several tomato builds for the past week and the only common factor I can find is multiple vlan builds. It's perfectly functional on every build that doesn't support them in the gui.

    Either there's a problem in IGMPproxy or there's a problem with the way the vlan interface configures it. Pretty much all the IGMPproxy issues I've googled are configuration errors so who knows :mad:

    On the other hand UDPxy seems to and functioned fine, although I'm a little lost as to why the default client number is so low when the limit is 5000 in the change list. The fact that it has any gui config at all makes me want to know why it received more attention than IGMP since it killing wifi should be fixed by snooping.

    Basically what are the benefits (and cons) of UDPxy over IGMPproxy?
     

Share This Page