Date: Tue, 13 Mar 2007 08:50:29 +0300 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: rik@FreeBSD.org, Roman Kurakin <rik@inse.ru>, andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" <bms@FreeBSD.org> Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Message-ID: <20070313055029.GK58523@codelabs.ru> In-Reply-To: <20070312214926.GK44732@comp.chem.msu.su> References: <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> <20070312214926.GK44732@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar, good day. > > >>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. OK, no problem: we can keep the actual incoming interface in the mbuf. > > >>>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. Yes, it is based on the wrong assumptions that were made about 3-4 years ago in the NetBSD. And the real problem here is if we want to leave the current behaviour of locally destined packets or we want completely different thing. We asked in the list if someone uses the current behaviour, but no replies were received yet. > > >>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. Sure. And that is why all switches that can bear the IP on their interfaces have distinct MACs for each interface or/and the only one interface can have the IP. And that is why I am going to add the paragraph to the if_bridge(4) describing the current situation and giving advice on the setting IP for the bridge members and the bridge itself. Will provide the patch in a day or two. > > >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. I tried to understand this, because Bruce already gave me a patch, but I am a bit stupid: I do not see how M_PROMISC that is cleared unconditionally before BRIDGE_INPUT will help us to identify the right interface. As I see now, the BRIDGE_INPUT is called once from if_ethersubr.c, once from if_gif.c and once from ng_ether.c: http://fxr.watson.org/fxr/ident?i=BRIDGE_INPUT So there is no distinct code paths that can allow BRIDGE_INPUT to modify its behaviour based on the M_PROMISC flag. But I feel that I am wrong in some place and missing some discuission on the M_PROMISC. Can anyone point me to the right place? > So all the tangled if()s inside LIST_FOREACH() will be gone completely > from bridge_input(). But we still need to see if we want to consume the packet by the bridge or it members or to do forwarding. Am I missing something? > > >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. 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, - 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. -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070313055029.GK58523>