From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1484126278.23671.3.camel@sipsolutions.net> From: Johannes Berg Date: Wed, 11 Jan 2017 10:17:58 +0100 In-Reply-To: <20170109231203.GC5513@otheros> References: <20170109231203.GC5513@otheros> Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [Bridge] [PATCH net-next] bridge: multicast to unicast List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Linus =?ISO-8859-1?Q?L=FCssing?= Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Braun , "David S . Miller" , Felix Fietkau > > Exactly. My point is that this is breaking the expectation that > > hosts are actually able to drop such packets. > > [readding CCs I removed earlier] > > Ah! Thanks. I was worried about creating packetloss :D. Ah, well, no - at least not in this case. > Hm, for this other other way round, I think it does not apply for > the bridge multicast-to-unicast patch if I'm not misreading the > bridge code: > > For a packet with a link-layer multicast address but a unicast IP > destination, the bridge MDB lookup will fail. > (http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8 > #L178 >  returns NULL) > > Case A): No multicast router on port: > -> bridge, br_multicast_flood(), will drop the packet already >    (no matter if multicast-to-unicast is enabled or not) > > Case B): Multicast router present on port: > -> The new patch does not apply multicast-to-unicast but just floods >    packet unaltered >    ("else { port = rport; addr = NULL; }" branch) Ah, interesting. This is different then - the mac80211 code is not L3 aware at all. johannes