[LEDE-DEV] netifd: "bridge: disable IGMP snooping by default"

[Dave Täht]

On 1/20/17 2:37 AM, Linus Lüssing wrote:
> Hi,
> 
> Is there any further information regarding this commit somewhere?
> 
> "bridge: disable IGMP snooping by default"
> https://git.lede-project.org/?p=project/netifd.git;a=commitdiff;h=52541140f8138e31958cdc3d7e42a4029fa6bbc9

This is probably my fault. At the time I was seeing multicast traffic
coming in from "somewhere" in bridge mode and pointed a finger at this
and the multicast-unicast code. So felix disabled it. (Unless he has
more reports from elsewhere?)

My problems ended up having nothing to do with this code. I think.

What was *really* happening to me was:

1) Mucho hacking and debugging later I was told that odhcpd does not
respect the ignore setting in /etc/config/dhcp ( there's an url for this
behavior I was just given ) You have to explicitly disable all
the dhcpv6 options there to turn it off.

2) The odhcpd-pd implementation is badly broken: It stops doing ras
after being hit 3 times by a dhcp-pd request by another lede router
inside the network, thus taking the ipv6 portion of the net up and down
for 30-60 seconds every other minute... (see bug 388). Apparently
odhcpd has been borked this way since a point release of CC.

3) The edgerouters dhcp-pd implementation interacts with this really
badly, sending a flood of packets (which seemed to appear from
everywhere) and rapidly fork-bombing itself into death, while taking out
the lede router per item 2, and stopping forwarding anything...

(the culmination of this was the near complete, and repeated collapse of
my producton network after the edgerouters went down, merely by adding a
single new lede router to the network). And it only takes 3 packets to
trigger, about 2 minutes, tops....)

Observing the debris, my gut said "broadcast/multicast storm".

4) before fiddling with dhcp-pd, I was seeing  excessive jitter and
latency on an heavily apple'd (mdns-heavy) network through the new wifi
code, and tons of multicast coming from places I'd not expected it from.
(but, see 1)

5) I was also seeing udhcp(v4) packets from a "c.h.i.p" entering the
network from its usb0 device when it was only supposed to come out of
wlan0 - I *think* this is a bug in udhcp where it doesn't lock the
output to the given interface (it's a single setsockopt),

Since after from digging myself out of that, I think I can no longer
blame the igmp or multi-cast bridging code for anything! it's probably
safe to re-enable.

but: I have not got around to retesting igmp snooping, multicast-unicast
personally, because I frantically went around turning it off everywhere,
and I'm still too scarred by these events to fiddle with 'em whilst I
try to fix bug 388.

I do note that I have a bias towards leaving multicast alone and for
that matter enabling stp by default on bridges. Especially in complex
networks. And I loathe the idea of "reliable multicast" on wifi on
typical networks with more than, say 3 stations, but I've ranted about
that elsewhere.

But - as it had been enabled for a year for everybody else with no
problems, (unless nbd did it in regard to someone else other than me?),
goferit. I'll take the time to poke into 4 and 5 with more structured
tests (uftp, maybe, or mdns-flooding) at some point after 388 yields to
a full scale attack.

It's just odhcpd that sucks rocks through a straw.

> Regards, Linus
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>