Posted: Sat Nov 15, 2008 4:39 Post subject: Disabling SPI Firewall breaks WAN connectivity on N routers
Disabling the SPI Firewall causes all outside connections to fail on my two N-routers. The same setting works normally on my G-routers. This problem is 100% reproducible on both my Netgear WNRD3300 and Linksys WRT150n. I had the same problem with earlier builds, but this is the first chance I've had to really isolate the problem.
All tests were done with each router individually wired to a MacBook Pro. A cable modem was wired to the router's WAN port. Power was toggled on the cable modem when switching routers.
Steps:
1. 30-30-30 reset
2. Load NEWD build r10923 mini (reset to defaults)
3. `erase nvram && reboot` via telnet
4. Connect to router, set login/password
5. Load web pages
6. Uncheck all and disable SPI Firewall on router
7. Attempt to load web pages again
8. Attempt to load web GUI pages over next 2-5 minutes
Results:
ASUS WL-520GU - no problems
Linksys WRT54GS v1.1 - no problems (used VINT instead of NEWD)
Linksys WRT150N v1.1 &
Netgear WNDR3300 - Total failure to reach any outside pages after 10-20 seconds. DD-WRT's web GUI worked initially, then after a few minutes it started experiencing long but intermittent page-loading delays or failure. Re-enabling the firewall did not bring back WAN connectivity. GUI reset to factory defaults restores outside connections. Both of these routers report using a 264 MHz Broadcom BCM4704 r9 CPU.
Posted: Sun Nov 16, 2008 5:27 Post subject: more specifically, igmprt kills my WAN
joemaller wrote:
Steps:
1. 30-30-30 reset
2. Load NEWD build r10923 mini (reset to defaults)
3. `erase nvram && reboot` via telnet
4. Connect to router, set login/password
5. Load web pages
6. Uncheck all and disable SPI Firewall on router
7. Attempt to load web pages again
8. Attempt to load web GUI pages over next 2-5 minutes
...
Turns out it wasn't the firewall exactly.
After more fiddling, I've nailed this down to the Filter Multicast checkbox. All the other default enabled options on the page, as well as the SPI firewall itself can be disabled without breaking WAN connectivity. Unchecking Filter Multicast will break WAN whether SPI is enabled or not.
This seems to be related to an older problem from this thread: igmprt kills my WAN
If I telnet in and kill igmprt, WAN connectivity is immediately restored. Toggling the Filter Multicast checkbox also restores connectivity after a few seconds, regardless of the SPI Firewall setting.
Yes, if I disable the Filter Multicast checkbox on either of my BCM4704 r9 CPU-based routers it breaks WAN connectivity. Re-enabling multicast filtering restores connectivity.
Confusingly, the igmprt process only appears to be running when that checkbox is not checked.
Confusingly, the igmprt process only appears to be running when that checkbox is not checked.
That makes sense, since multicast packets will not automatically propagate from the WAN to LAN through a NAT device. The igmprt process listens for multicast packets on the WAN port and rebroadcasts them to each LAN client. igmprt has been broken for quite some time (at least a year, according to the tickets on the bugtracker). I recommend filing a bug, and/or voting for #406 (http://svn.dd-wrt.com:8000/dd-wrt/ticket/406).
That makes sense, since multicast packets will not automatically propagate from the WAN to LAN through a NAT device....
Thanks for your explanation. But there is still the interface inconsistency that initially threw me off. The Filter Multicast checkbox still has an effect after the SPI Firewall setting had dimmed it. If the checkbox is dimmed and can't be changed, shouldn't it default to off? Which other settings that seem to be SPI Firewall options are also running despite the firewall setting?
Wow, I thought I was the ONLY one experiencing this. I have exactly the same problem with my WRT300N v1. I isolated the Filter Multicast a long time ago but I thought it was just me.
Joined: 04 Jan 2007 Posts: 11564 Location: Wherever the wind blows- North America
Posted: Sat Jul 11, 2009 18:20 Post subject:
I saw other issues due to Multicast being turned off. If I remember correctly the igmprt process would run away causing the CPU usage to peg at 100% and the load average was in the 4.0 range when filter Multicast was unchecked.
This is the main reason the wiki was changed for Repeater and Repeater Bridge modes...to leave this one checked before turning off the SPI.
I am pretty sure it was reported...I may do some searching for it in TRAC.
redhawk _________________ The only stupid question....is the unasked one.
Posted: Mon Nov 04, 2013 10:48 Post subject: Igmprt == Heisenbug
OMG. This bug has been known for years and I just wasted so many hours of my life reading through the wiki and trying every permutation to get DD-WRT working. All I knew was that, no matter what change I made, when I clicked on Apply from the Basic setup page, my network would mysteriously start working again, only to break the next time I rebooted. Maddening!
Only after I killed each process one by one and tracked it down to the igmprt process did I make any headway, and even then the dd-wrt wiki for igmprt doesn't mention where in the UI to find the box to disable the service, much less warn that it is pathologically broken (but, because of the fun nature of this bug, you probably won't notice the breakage until the next reboot.)
Can this option's label please be changed from "Filter Multicast" to "Uncheck this box if you want to run the known buggy igmprt daemon which will cause you to lose your network connection."
Or, less tongue-in-cheek, could the option just be removed and a more obvious one labeled "Multicast Proxy Daemon [BUGGY!]" replace it under the "Services" instead of "Security" menu.