On Wed, 3 Aug 2016, Jung-uk Kim wrote:
Log:
Support nanosecond time stamps for pcap_dispatch(3) and pcap_loop(3).
Modified:
head/contrib/libpcap/pcap-bpf.c
Modified: head/contrib/libpcap/pcap-bpf.c
==============================================================================
--- head/contrib/libpcap/pcap-bpf.c Wed Aug 3 19:23:22 2016
(r303732)
+++ head/contrib/libpcap/pcap-bpf.c Wed Aug 3 20:08:39 2016
(r303733)
@@ -1008,7 +1028,25 @@ pcap_read_bpf(pcap_t *p, int cnt, pcap_h
if (pb->filtering_in_kernel ||
bpf_filter(p->fcode.bf_insns, datap, bhp->bh_datalen,
caplen)) {
struct pcap_pkthdr pkthdr;
+#ifdef BIOCSTSTAMP
+ struct bintime bt;
+
+ bt.sec = bhp->bh_tstamp.bt_sec;
+ bt.frac = bhp->bh_tstamp.bt_frac;
The names are very confusing since bt_sec and bt_frac are only misnamed as
sec and frac in struct bintime.
+ if (p->opt.tstamp_precision ==
PCAP_TSTAMP_PRECISION_NANO) {
+ struct timespec ts;
+
+ bintime2timespec(&bt, &ts);
+ pkthdr.ts.tv_sec = ts.tv_sec;
+ pkthdr.ts.tv_usec = ts.tv_nsec;
And this abuses tv_usec to hold nanoseconds.
Old code is even more confusing, and at least partly wrong.
X contrib/libpcap/pcap-bpf.c: pkthdr.ts.tv_usec =
bhp->bh_tstamp.tv_usec/1000;
This is to convert for tv_usec actually being tv_nsec on AIX. If the above
works with no conversion, then it might work for AIX too.
X sys/net/bpf.c: struct timeval32 bh_tstamp; /* time stamp */
Banal comment. The complexities are from what sort of timestamp this is.
It is obviously a timestamp.
This bh_tstamp is in struct bpf_hdr32 for the !BURN_BRIDGES case. There
is also struct timeval bh_timestamp in struct bpf_hdr. This header is
bogusly marked Obsolete.
X sys/net/bpf.c: hdr32_old.bh_tstamp.tv_usec =
ts.bt_frac;
This is in the !BURN_BRIDGES && COMPAT_FREEBSD32 case. Since struct timeval32
always has a 32-bit tv_usec, this assignment discards the most significant
bits in bt_frac but keeps the noise.
X sys/net/bpf.c: hdr_old.bh_tstamp.tv_usec = ts.bt_frac;
This is in the !BURN_BRIDGES && !COMPAT_FREEBSD32 case. Since tv_sec in a
normal timetamp is bogusly long, this accidentally preserves all of the bits
in bt_frac on 64-bit arches. On 32-bit arches, it loses the signal as for
the COMPAT_FREEBSD32 case.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
