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 - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
