From owner-freebsd-net@FreeBSD.ORG Sat Sep 25 10:54:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06C4E16A4D0 for ; Sat, 25 Sep 2004 10:54:49 +0000 (GMT) Received: from grunt1.ihug.co.nz (grunt1.ihug.co.nz [203.109.254.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 409A543D1F for ; Sat, 25 Sep 2004 10:54:48 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-118-173-111.adsl.ihug.co.nz (lycra.luckie.org.nz) [203.118.173.111] by grunt1.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1CBACT-000180-00; Sat, 25 Sep 2004 22:54:45 +1200 Received: from 203-118-171-223.adsl.ihug.co.nz ([203.118.171.223] helo=[192.168.1.2]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.42 (FreeBSD)) id 1CBACH-0002o1-Pr; Sat, 25 Sep 2004 22:54:34 +1200 Message-ID: <41554E71.3020708@luckie.org.nz> Date: Sat, 25 Sep 2004 22:54:41 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040911 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <200409250714.RAA28547@avalon.reed.wattle.id.au> In-Reply-To: <200409250714.RAA28547@avalon.reed.wattle.id.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 10:54:49 -0000 >>This is probably a pointless optimization, as you probably relatively >>rarely have multiple BPF devices bound to the same interface receiving >>the bulk of the packets (as opposed to some daemon with a filter that >>passes only the packets it's interested in), but would there be any >>advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp >>and pass that to "catchpacket()", so that in the case where there *is* >>more than one tap, the time stamp is only fetched once? > > That makes sense and allows you to correllate packet time stamps from > a daemon collecting packets with those you see in tcpdump output when > you run that in parallel to make sure things are moving. i've generated a patch to accomplish this on FreeBSD 4.10 and submitted a PR for it just a couple of weeks ago, when i noticed a small difference between the timestamp I captured in an application compared to what i saw with tcpdump. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71711 The motivation for this patch was to obtain something resembling the timestamp closest to when a packet I generated and transmitted hit the wire, to infer a more accurate RTT with an associated response packet. I'm not sure if what I've used BPF for in this case is 'correct' in that I've not done any real study to see how the timestamp compares to what a DAG would report. There is an argument to be made for generating the timestamp just the once after it actually passes a filter, but I've not done that in my patch. Feedback appreciated. Matthew