Date: Tue, 13 Mar 2007 00:49:26 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Roman Kurakin <rik@inse.ru> Cc: rik@FreeBSD.org, andre@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org, "Bruce M. Simpson" <bms@FreeBSD.org> Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Message-ID: <20070312214926.GK44732@comp.chem.msu.su> In-Reply-To: <45F5BD36.1070205@inse.ru> References: <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 12, 2007 at 11:51:02PM +0300, Roman Kurakin wrote: > Yar Tikhiy wrote: > >On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote: > > > >>Yar, > >> > >> > >>>>2. In the case where 802.3ad trunking is implemented, the same Ethernet > >>>>address may be used by multiple physical interfaces. > >>>> > >>>>3. As Eygene explained well: there are a number of consumers of > >>>>Ethernet frames in the stack. As if_bridge may potentially be passed > >>>>mbuf chains containing packets for these consumers first, it must > >>>>examine the destination address to determine if it should claim the > >>>>packet or not. > >>>> > >>>>Finally, because of the above points, the Ethernet destination address > >>>>cannot be regarded as a unique key in the bridge code, or indeed the > >>>>general Ethernet path, for where packets should be relayed in the stack > >>>>as a whole. > >>>> > >>>But why are we relying solely on the Ethernet destination address? > >>> > >>Probably because if_bridge is written for Ethernet, 802.11 and > >>may be some other 802 interfaces: > >>----- > >>DESCRIPTION > >> The if_bridge driver creates a logical link between two or more IEEE > >> 802 > >> networks that use the same (or ``similar enough'') framing format. > >> For > >> example, it is possible to bridge Ethernet and 802.11 networks > >> together, > >> but it is not possible to bridge Ethernet and Token Ring together. > >>----- > >> > > > >The IEEE standards don't prevent us from keeping the pointer to the > >receive interface and using it to identify the interface unambiguously. > >That's what I meant. > > > > > >>>Each frame was received via a particular interface, which is recorded > >>>in mbuf's recvif. As the frame moves between levels of abstraction, > >>>such as a physical interface, vlan, bridge, recvif can change, but > >>>at each level the pointer to an entity in the previous level should > >>>be enough, shouldn't it? > >>> > >>Excuse me, but are we talking about the problem that is cured by > >>our patch, or about some general points? If about the former, then > >>this problem shows up only for the packet that is destined for the > >>local interface at the L2. And the pfil gots the wrong interface name > >>due to the bug. > >> > > > >A patch is unlikely to be correct if it's based on wrong assumptions. > > > Read my "very long email" again. The model used by the bridge to deliver the > packet for our host is not wrong. > >>>E.g., if several vlan interfaces are > >>>bridged, if_bridge shouldn't need to know which physical interfaces > >>>are used by the vlans. OTOH, it can know which particular vlan the > >>>frame came through, although vlan MACs can be the same. > >>> > >>And who is saying that if_bridge should need to know about the > >>underlying (parent) interface for the VLAN? The word 'physical' that > >>we use here denotes the VLAN interface in which the packet showed up > >>at ether_input. And the word 'logical' means the interface that > >>the L2 packet is destined for. Perhaps it is the source of confusion? > >> > > > >Quite likely. Even pfil is confused. ;^) As I've managed to figure > >out finally, the "physical" interface (in this discussion) is the > >interface the L2 packet actually came from, and the "logical" one > >just bears the MAC address equal to that in the destination field > >of the packet. > > > >The problem is that we cannot determine the "logical" interface > >reliably in the presence of interfaces sharing the same MAC address. > >No hacks can help us with that. > > > >Assume that a host has two physical interfaces, say, em0 and em1, > >with different MAC addresses. We set up a few vlans on the former > >and a few vlans on the latter, and then bridge all vlans together. > >Now an Ethernet packet comes via, say, em0.7, with its destination > >MAC address equal to that of em1 (and its vlans). Which of em1.* > >vlans would you "logically" assign the packet to, and why? > > > This problem was described in my "very long e-mail". And yes it can not be > fixed. Only if we will try to assign the packet to every interfaces in > bridge > with the same MAC, until the rules for the one allow this packet. This > is too > heavy solution. But if we can't fix the all sides of this problem it > doesn't mean > we shouldn't try to fix one that possible. See bms_netdev, it's rather promising: with it, we won't have to do duplicate checks for the destination MAC address. Namely see lines 642-682 of //depot/user/bms/netdev/sys/net/if_ethersubr.c#9. The things may need some moving around, but all code is already there. Then the bridge_input code will be able to make use of M_PROMISC to see if it must consume the packet or just update its forwarding table. So all the tangled if()s inside LIST_FOREACH() will be gone completely from bridge_input(). > rik > >I'm afraid there is a serious flaw in the very notion of such a > >"logical" interface. If it's true, we should start by admitting > >that the support for "logical" interfaces should be a side hack for > >compatibility, and not something that can live forever on the main > >code path. > > > > -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070312214926.GK44732>