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

2017-01-28 Thread Felix Fietkau 
On 2017-01-26 21:38, Linus Lüssing wrote:
> Hi Felix, thanks and I really appreciate your efforts to create a
> successful, stable and first LEDE release :). So if it's going to
> be disabled in that first LEDE release, that'd be fine by me.
> 
> Nevertheless, Jow or Felix, could you forward the tickets which
> seemed related to bridge multicast snooping to me? So I can check
> whether it should be disabled in Gluon, too. (we took some
> precautions with a robustness variable of 3 instead of 2 and way
> lower querier intervals in Gluon, but not sure what kind of issues
> were reported for LEDE)
Hi Linus,

here's a ticket that just confirms issues with the IGMP snooping patch:
https://bugs.lede-project.org/index.php?do=details_id=253#comment1477

Please follow up with the bug reporters there and let me know if you
need any help.

Thanks,

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2017-01-26 Thread Linus Lüssing 
On Tue, Jan 24, 2017 at 04:28:52PM +0100, Felix Fietkau wrote:
> On 2017-01-20 11:37, 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
> Sorry, I forgot to put some context in the commit message. jow pointed
> out to me that we have a whole bunch of different tickets and reports
> that point at issues with multicast. Some of them are clearly wireless
> related, but others seemed to go away when disabling IGMP snooping. This
> is really hard to pin down and we decided to make this feature opt-in
> instead of opt-out for now until things settle down a bit more.

Hi Felix, thanks and I really appreciate your efforts to create a
successful, stable and first LEDE release :). So if it's going to
be disabled in that first LEDE release, that'd be fine by me.

Nevertheless, Jow or Felix, could you forward the tickets which
seemed related to bridge multicast snooping to me? So I can check
whether it should be disabled in Gluon, too. (we took some
precautions with a robustness variable of 3 instead of 2 and way
lower querier intervals in Gluon, but not sure what kind of issues
were reported for LEDE)

Regards, Linus

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2017-01-24 Thread Felix Fietkau 
On 2017-01-20 11:37, 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
Sorry, I forgot to put some context in the commit message. jow pointed
out to me that we have a whole bunch of different tickets and reports
that point at issues with multicast. Some of them are clearly wireless
related, but others seemed to go away when disabling IGMP snooping. This
is really hard to pin down and we decided to make this feature opt-in
instead of opt-out for now until things settle down a bit more.

I think it makes sense to have another go at enabled-by-default when we
move to a newer kernel and use the latest version of the patch.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2017-01-21 Thread Daniel Dickinson 
On Sat, 21 Jan 2017 03:50:50 +
Eric Luehrsen  wrote:

> Dave,
> 
> May I quote you for pull requests to achieve "dnsmasq: make DHCPv6
> work in standalone dnsmasq installation":
> https://github.com/lede-project/source/pull/704
> https://github.com/lede-project/source/pull/674
> 

Is there any interest / any effort to use the ISC DHCP server instead
of either dnsmasq and/or odhcpd on bigger devices?  Certainly one of my
back burner projects has the been the whole 'maximum user choice'
thing with things like being able to use the same configs with one's
preferred DNS/DHCP as well as the GNU coreutils and other 'full'
commands instead of busybox for that that wish it.  Basically where
there are other options in open source, allowing users to choose their
poison (since no one solution is perfect for all situations).  Ideally
one could also substitute systemd or openrc.d for procd based init if
one so chooses.  Basically instead of LEDE/OpenWrt being a
one-size-fits-all solution, I'd like to see it be more a build system
that allows you to choose your solutions. (Which is what LEDE name
implies vs. a distribution; LEDE/OpenWrt as a distribution is a
particular set of choices in my view and is actually a separate
project).

Regards,

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2017-01-20 Thread Eric Luehrsen 
Dave,

May I quote you for pull requests to achieve "dnsmasq: make DHCPv6 work in 
standalone dnsmasq installation":
https://github.com/lede-project/source/pull/704
https://github.com/lede-project/source/pull/674

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

Eric

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

2017-01-20 Thread 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@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

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

2017-01-20 Thread Linus Lüssing 
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

Regards, Linus

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev