Date: Tue, 13 Mar 2007 15:00:05 +0300 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: rik@FreeBSD.org, Roman Kurakin <rik@inse.ru>, andre@FreeBSD.org, Yar Tikhiy <yar@comp.chem.msu.su>, glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Message-ID: <20070313120005.GT58523@codelabs.ru> In-Reply-To: <45F68CD6.2030300@FreeBSD.org> References: <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <45F68CD6.2030300@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce, Tue, Mar 13, 2007 at 11:36:54AM +0000, Bruce M. Simpson wrote: > > In short: M_PROMISC exists to easily identify frames which were received > promiscuously, to prevent infinite recursion, and to simplify code which needs > to re-enter ether_input(). > > M_PROMISC is a flag introduced by NetBSD into their ethernet input path to deal > with the case where an entity in the network stack needs to receive frames > promiscuously, without necessarily passing those frames to the upper layers > e.g. IPv4. It is not documented; the code is the documentation in this > instance. > > It is cleared when an mbuf chain is passed to another entity which may consume > the frame in that mbuf chain, in case the entity re-enters ether_input() with > the same mbuf chain for local delivery (e.g. bridge, netgraph, vlan). Got the idea, thanks! > >I agree with you. That is why I patched if_bridge once again to enable > >the pfil hooks for the "physical" incoming interface. And there are > >two ways to solve the problem: > >- to give each VLAN interface the distinct MAC, as Bruce suggested, > > > I didn't suggest this. :-) OK, sorry. > >- to refuse the "logical" interfaces completely and to support only > >"physical" ones. It is what my very first (and very short) patch > >did. But this can break some existing firewall rulesets. And that > >should be discuissed -- we do not need the total breakage due to > >out changes. And you're right: the best way for this alternative is to > >leave the current behaviour as the compatibility sysctl that is turned > >off by default and move to the filtering on the "physical" interfaces > >by default. No problem, but skilled network people that are using > >FreeBSD as the bridge for VLANs should say if they are happy with it. > > > I think it is acceptable for if_bridge(4) to know about the existence of VLAN > interfaces and to deal with them accordingly as a special case, because > Spanning Tree is specified differently in the case where VLANs are present. > Therefore it is not unreasonable for if_bridge(4) to be looking at VLAN headers > in the mbuf chain. I see your point, but all if_bridge can do with the VLAN header is to identify the VLAN ID. But this will not help us in the case of multiple identical MAC addresses, when the "physical" input interface is not the L2 destination. Just because all we can do with the VLAN tag is to identify the physical incoming VLAN. But it is already passed to the bridge_input in the form of 'ifp'. Or I am missing some point here? > As such I think the behaviour Andrew Thompson and I were discussing off list > should be made the default: that is, the first 802.1q VLAN header is stripped > off and turned into an M_VLANTAG before being passed to other consumers in the > stack. So you want the if_vlan to mark the packet with the ETHERTYPE_VLAN (in-band VLAN tag) with M_VLANTAG? > The presence of M_VLANTAG makes it very easy to see that a frame was received > with a VLAN header without involving vlan(4) and reduces the amount of 802.1q > specific code across Layer 2 subsystems. Sure. But it seems to be unusable for our bug. Though maybe I am wrong. -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070313120005.GT58523>