Date: Tue, 13 Mar 2007 12:53:00 +0300 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: freebsd-net@freebsd.org Subject: Re: [ADVICE NEEDED] if_bridge and pfil hooks behaviour Message-ID: <20070313095300.GS58523@codelabs.ru> In-Reply-To: <20070313094008.GR58523@codelabs.ru> References: <20070313094008.GR58523@codelabs.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Good day again. Sorry, hit the 'Send' button prematurely. So, we are currently trying to fix kern/109815 and the advice is needed on the current and the desired behaviour of L3 filtering on the if_bridge. We're talking about the case when the packets coming to the if_bridge interface are destined to some bridge member at the layer 2. So primarily it is the case when the bridged machine is acting as an L3 router. And the problem is about the interface the pfil hooks are seeing for such a packet. The current behaviour is the following: pfil hooks are getting the interface if the bridge for which the packet is destined (in L2). So it is not the "physical" interface on which the packet appeared, but the interface with the MAC address that is in the packet's destination field. And the current behaviour is not so good, because in the case of multiple interfaces that are sharing the same MAC in the bridge the bridge code will not be able to figure out the right one. By the way, BPF gets the "physical" interface, so the current behaviour of pfil hooks is inconsistent with the BPF. There can be alternative behaviour: pfil hooks will see the "physical" interface on which the packet appeared. And this is much better for the multiple identical MACs case, since there will be no confusion. But this will break the current (possibly erroneous) behaviour, that was introduced in a very first version of if_bridge.c that was doing the pfil hooks (at NetBSD, v 1.9: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_bridge.c?rev=1.9&content-type=text/x-cvsweb-markup). So the question is: are there some reasons to keep the current behaviour as the default one, or we can move to the alternative behaviour possibly leaving the old one in the form of additional sysctl? Thank you! -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070313095300.GS58523>