From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 05:17:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFBE416A400 for ; Sun, 18 Mar 2007 05:17:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 78F7613C43E for ; Sun, 18 Mar 2007 05:17:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HSnla-000MTV-2L; Sun, 18 Mar 2007 08:17:14 +0300 Date: Sun, 18 Mar 2007 08:17:09 +0300 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070318051709.GE82045@codelabs.ru> References: <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> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <45FCC115.1020408@elischer.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, rik@inse.ru Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2007 05:17:17 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Julian, good day. > >+.Pp > >+The packets destined to the bridging host will be seen by the filter > >+on the interface with the MAC address equal to the packet's destination > >+MAC. Be prepated to the situation when some of the bridge members are sharing > > prepated to ? > prepared for? ??? You're right, thanks for spotting the error. The corrected patch is attached. -- Eygene --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_bridge.4.diff" --- if_bridge.4.orig Sun Mar 4 15:37:22 2007 +++ if_bridge.4 Sun Mar 18 08:13:53 2007 @@ -219,9 +219,67 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table according to the packet destination address (not the MAC +address). +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. Be prepared for the situation when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). It is not possible +to distinguish between these interfaces using their MAC address, +excluding the case when the packet's destination MAC address is +equal to the MAC address of the interface on which the packet was +entered to the system. In this case the filter will see the incoming +packet on this interface. In all other cases the interface seen +by the packet filter is almost randomly chosen from the list of +bridge members with the same MAC address. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let the MAC address of the incoming packet's destination will be +.Nm nn:nn:nn:nn:nn:nn , +the interface on which packet entered the system is +.Nm vlanX +with the MAC address +.Nm xx:xx:xx:xx:xx:xx +and the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. Then if MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm vlanX +no matter if there are some other bridge members carrying the same +MAC address. But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is some of the +.Nm vlanYn , +but it is not possible to know the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. So if one wants +the filter the locally destined packets based on their interface name, +he should be aware of this implication. Such situation will appear on the +filtering bridges that are doing IP-forwarding; in this case it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf --Fba/0zbH8Xs+Fj9o--