From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 20:22:12 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 EA43116A41A; Tue, 28 Aug 2007 20:22:12 +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 BAF6213C428; Tue, 28 Aug 2007 20:22:12 +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 4089227271; Tue, 28 Aug 2007 16:22:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:22:12 -0400 X-Sasl-enc: gDOl1TDpDenI3N0tEdobsOTyma1I7Oa0H1QJV8VqVEws 1188332531 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 BF2292330B; Tue, 28 Aug 2007 16:22:11 -0400 (EDT) Message-ID: <46D483F2.2040207@FreeBSD.org> Date: Tue, 28 Aug 2007 21:22:10 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Andrew Thompson References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> <20070828103110.GA43049@heff.fud.org.nz> In-Reply-To: <20070828103110.GA43049@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current 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:22:13 -0000 Andrew Thompson wrote: > I had originally started to put it there but realised that I need a > pointer to the ifnet to read if_broadcastaddr, I didnt think it was > worth changing the function parameters when the check can also just go > in bpfwrite. I dont mind moving it if its the more correct place to put= > it. > =20 It's already got a switch..case breakout for the DLTs and knows how to=20 grok the 802.11 header format which can have up to 6 (yes, 6) 802.3=20 style MAC addresses, all of which mean different things depending on=20 whether you are STA, AP, Mesh Portal, Mesh AP... :-) So it seems like the right place. bpf_movein() is static and referenced=20 once within its translation unit, so it is a candidate for inlining; I=20 would change ifp-=BBif_mtu to ifp in the call. > Is the tapwrite patch still needed? The mbuf is passed to ether_input > which should do the right thing. > =20 Good point. A casual reading suggests it *may* no longer be needed since = my pass over ether_input(), but seeing as we're due to branch and all,=20 I'll leave garbage collecting the 10 lines in tapwrite() to someone=20 else. :-) > I could go with this but it seems wrong to be passed a mbuf which has > incorrect flags, there may be other places in the stack that look for > M_*CAST that also have quirks. > =20 Yup. Someone could potentially drive a netgraph stake between the=20 producer and the if_bridge consumer... Thank you for looking at this btw. regards, BMS