From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:37:21 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE3516A419; Tue, 28 Aug 2007 20:37:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C959B13C45B; Tue, 28 Aug 2007 20:37:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5ECC8272CE; Tue, 28 Aug 2007 16:37:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:37:20 -0400 X-Sasl-enc: W8inoUS2m9vK1hJKPdmSt1P+YXqUEV908iQTEjbUQfyn 1188333440 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BBC306BC1; Tue, 28 Aug 2007 16:37:19 -0400 (EDT) Message-ID: <46D4877E.700@FreeBSD.org> Date: Tue, 28 Aug 2007 21:37:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828135929.GA2305@sub.vaned.net> In-Reply-To: <20070828135929.GA2305@sub.vaned.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Andrew Thompson Subject: Re: multicast packets from bpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 20:37:21 -0000 Christian S.J. Peron wrote: > I think that tap(4) is a bit different since the only kind of frames it > handles are Ethernet. As Andrew points out the tapwrite check probably isn't needed now. > This is not the case for bpf(4). I wonder if it > makes sense to add this check into ether_output()? IIRC bpf will call > the network interface's output routine, in the Ethernet/bridge case it > should be ether_output(). > This approach avoids touching the device-independent paths, and, providing the check resides in the AF_UNSPEC case (as ARP resolution should do the right thing) is reasonably neat. But it doesn't handle the case where there are link-layer netgraph nodes between bpf and if_bridge, something which the first change would deal with. regards BMS