Date: Mon, 12 Mar 2007 23:51:02 +0300 From: Roman Kurakin <rik@inse.ru> To: Yar Tikhiy <yar@comp.chem.msu.su> 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: <45F5BD36.1070205@inse.ru> In-Reply-To: <20070312165145.GF44732@comp.chem.msu.su> References: <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F5BD36.1070205>