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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev