lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Sep 2011 02:16:43 +0200
From:	David Lamparter <equinox@...c24.net>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	Nick Carter <ncarter100@...il.com>,
	David Lamparter <equinox@...c24.net>, eswierk@...switch.com,
	netdev@...r.kernel.org,
	Michał Mirosław <mirqus@...il.com>,
	davem@...emloft.net
Subject: Re: [PATCH] bridge: mask forwarding of IEEE 802 local multicast
 groups

On Wed, Aug 31, 2011 at 01:49:04PM -0700, Stephen Hemminger wrote:
> On Wed, 31 Aug 2011 21:41:26 +0100
> Nick Carter <ncarter100@...il.com> wrote:
> 
> > On 15 August 2011 19:25, Stephen Hemminger
> > <shemminger@...ux-foundation.org> wrote:
> > > On Mon, 15 Aug 2011 17:27:12 +0100
> > > Nick Carter <ncarter100@...il.com> wrote:
> > >
> > >> On 28 July 2011 16:41, Stephen Hemminger
> > >> <shemminger@...ux-foundation.org> wrote:
> > >> > On Wed, 27 Jul 2011 13:17:15 +0200
> > >> > David Lamparter <equinox@...c24.net> wrote:
> > >> >
> > >> >> On Fri, Jul 15, 2011 at 06:33:45PM +0200, David Lamparter wrote:
> > >> >> > On Fri, Jul 15, 2011 at 06:03:57PM +0200, David Lamparter wrote:
> > >> >> > > On Fri, Jul 15, 2011 at 04:44:50PM +0100, Nick Carter wrote:
> > >> >> > > > On 12 July 2011 12:36, David Lamparter <equinox@...c24.net> wrote:
> > >> >> > > > > On Mon, Jul 11, 2011 at 08:27:55AM -0700, Stephen Hemminger wrote:
> > >> >> > > > >> I am still undecided on this. Understand the need, but don't like idea
> > >> >> > > > >> of bridge behaving in non-conforming manner. Will see if IEEE 802 committee
> > >> >> > > > >> has any input.
> > >> >> > > > >
> > >> >> > > > > The patch doesn't make the bridge behave nonconformant. The default mask
> > >> >> > > > > is 0, which just keeps the old behaviour.
> > >> >> >
> > >> >> > P.S.: I'd like to once more stress this. In my opinion the patch should
> > >> >> > be merged because it provides desireable functionality at a small cost
> > >> >> > (one test, one knob) and __does not change any default behaviour__.
> > >> >>
> > >> >> Stephen, anything new on this?
> > >> >
> > >> > No.
> > >> > Don't like adding yet another hack user visible API which will have
> > >> > to be maintained for too long. But on the other hand I don't have
> > >> > a better solution at my finger tips. If better idea doesn't come
> > >> > along, then we can go with yours.
> > >> >
> > >> I have not noticed any other proposals and this thread has been open
> > >> for quite a while.  Have we waited long enough ? If so can this patch
> > >> be taken ?
> > >>
> > >
> > > I am testing an alternative. The problem with your proposal is that
> > > it relies on the multicast address. It turns out there are people using
> > > other addresses for the STP group address, so using that as a identifier
> > > is incorrect.
> > If the chosen STP group address is in the local multicast group range
> > this patch will handle it.
> > 
> > David Lamparter has reviewed this patch and asked for it to be merged.
> >  This patch has at least two real world uses.  Ed needs this patch to
> > forward LLDP frames and I need this patch to forward 802.1X frames.
> > 
> > This patch has been out for review for 9 weeks and it still looks like
> > the best solution.
> 
> I prefer the netfilter solution because it is more general. We already have
> a firewall solution why shouldn't this case be part of it?

Nick's patch *IS* the netfilter solution. Check where it jumps to:

forward:
	switch (p->state) {
	case BR_STATE_FORWARDING:
		rhook = rcu_dereference(br_should_route_hook);
		if (rhook) {
			if ((*rhook)(skb)) {
				*pskb = skb;
				return RX_HANDLER_PASS;

This calls ebt_broute, which returns true if the BROUTING chain says
"DROP", which means "don't bridge, deliver on physdev" in this context.

Your patch reinvents the wheel - new ebtables chain - and does not
allow any control without bridge-netfilter in kernel.

Nick's patch allows rudimentary control (enough for most cases i'd say)
when bridge-netfilter is disabled and full same-as-other-multicast
control when bridge-netfilter is enabled/loaded.


-David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ