From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 16:06:22 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 61EE216A400; Sun, 4 Mar 2007 16:06:22 +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 147E213C491; Sun, 4 Mar 2007 16:06:21 +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 1HNtE3-000NBh-Js; Sun, 04 Mar 2007 19:06:20 +0300 Date: Sun, 4 Mar 2007 19:06:14 +0300 From: Eygene Ryabinkin To: freebsd-net@freebsd.org Message-ID: <20070304160613.GN80319@codelabs.ru> References: <45E9F1E8.2000802@inse.ru> <20070304062203.GL80319@codelabs.ru> <45E9F1E8.2000802@inse.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070304062203.GL80319@codelabs.ru> <45E9F1E8.2000802@inse.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, glebius@FreeBSD.org, andre@FreeBSD.org, thompsa@FreeBSD.org Subject: 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, 04 Mar 2007 16:06:22 -0000 Good day, the freebsd-net readers. Perhaps someone can look at the kern/109815 and provide some feedback. Citing my PR: > >When if_bridge is used to gather multiple vlan interfaces that have > >the same physical parent (I will call such vlan interfaces the 'vlan > >group') the interface identifier that will be passed to the > >pfil_hooks will be sometimes wrong. For all packets coming from the > >'vlan group' and destined to some local interface the incoming interface > >passed to the pfil_hooks will be the last interface in that group > >regardless of the actual incoming interface. The 'last interface' is > >the interface that was added to the if_bridge at the very last 'addm' > >command. > > > >The problem is lying in the fact that MAC addresses of the 'vlan group' > >are just the same and they are equal to the MAC address of the parent > >interface. And the check for the unicat packet that is destined for > >'us' in the if_bridge.c:bridge_input() is walking by the list of the > >if_bridge-attached interfaces and compares the MAC addresses to the > >packet's one. Once match is found the interface in the packet header > >will be rewritten to the found list entry's one. Apparently such > >code flow will select the last added interface from the 'vlan group' > >because FreeBSD list macros are adding list members to the beginning > >of the linked list. > > > >BPF will receive the right interface, because it is tapped before > >bridge_input (in if_ethersubr.c). Roman Kurakin suggested that the patch can break some things: Sun, Mar 04, 2007 at 01:08:40AM +0300, Roman Kurakin wrote: > The idea behind current code could be that in case of bridge the > interface for which this packet in?nded is much more important > than the physical interface it is arrived from. > If this is the case, than it would be much better do the same logic > for ifp and in case it is not that interface to check the list. > This will fix the problem in case of vlans and will leave the old > behavior for the other cases. > > Any comments? I've slightly elaborated his idea and commented on it: Sun, Mar 04, 2007 at 09:22:03AM +0300, Eygene Ryabinkin wrote: > > So, you're saying the following: let us have two interfaces in the > bridge ifA and ifB with the MAC-A and MAC-B. In the current situation > packet coming from the physical interface ifA but destined to the > MAC-B, then the interface seen by the packet filter will be ifB and > not the ifA. Right? > > In principle, this situation can be used for something. But then we > should at least teah BPF to behave this way, because as you remember > from spending three hours before the console with me and trying to > diagnose the problem with tcpdump we were amazed to see the discrepance > between bpf and pfil. So it should be at least documented. > > But as I understand, my patch will let the described situation to > work as usual -- packets will still be delivered to the ifB, but > packet filter will see the physical incoming interface. The patch > should not break the delivery of the packet since all I do is the > change of the rcvif. Or I am wrong? I traced the current if_bridge.c behaviour to the NetBSD's if_bridge.c 1.9. This was the first version in that the firewall hooks were introduced. And the assumtion that the MAC identifies the physical interfaces was used in this first version. And a question: can anyone say if my patch will break some known good behaviour and if the current behaviour of if_bridge is based on some logic I am currently failing to understand. Thank you! -- Eygene