From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 18 Aug 2011 09:39:41 -0700 From: Stephen Hemminger Message-ID: <20110818093941.5ebf716b@nehalam.ftrdhcpuser.net> In-Reply-To: References: <20110812154545.79d8313f@nehalam.ftrdhcpuser.net> <20110815150501.3a6cc432@nehalam.ftrdhcpuser.net> <20110818081019.4b9bb79e@nehalam.ftrdhcpuser.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [RFC] bridge: allow passing link-local multicast List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nick Carter Cc: netdev@vger.kernel.org, bridge@linux-foundation.org, Ed Swierk , David Lamparter On Thu, 18 Aug 2011 16:52:45 +0100 Nick Carter wrote: > On 18 August 2011 16:10, Stephen Hemminger wrote: > > On Thu, 18 Aug 2011 16:06:19 +0100 > > Nick Carter wrote: > > > >> Why can't we use the 802.1D specified STP group address to identify ? > >> The existing code uses that address. > >> I know you said on another thread that there are people using other addresses. > >> Who are these people ? > >> Are they following any standard ? > >> What address / address range are they using ? > > > > The group address can be reprogrammed, and it is settable on other > > routing equipment. People do it to create spanning tree domains. > > > But before the new > + if (!is_stp_bpdu(skb) && br_forward_link_local) > check, we have already checked > if (unlikely(is_link_local(dest))) { > So the frame must have a link local destination. If the reprogrammed > group address is outside of the link local range then the new code in > this patch will never be hit. If the reprogrammed group address is in > the link local range then i'd suggest my previous group_fwd_mask patch > is cleaner and more flexible. The problem is that the group_fwd_mask is specific to the address not the protocol.