svn commit: r303733 - head/contrib/libpcap

Jung-uk Kim jkim at FreeBSD.org
Thu Aug 4 18:08:34 UTC 2016


On 08/03/16 11:40 PM, Bruce Evans wrote:
> 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.

bt_* means BPF timestamp, not 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.

libpcap decided to "abuse" it few years ago, not to break ABI/API.

http://www.tcpdump.org/manpages/pcap-savefile.5.html

> 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.

Of course.  However, we don't maintain AIX. ;-)

> 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.

It is superceded by struct bpf_xhdr although we kept it for backward
compatibility.  New applications should avoid it.

> 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.

Note struct bpf_ts is not struct bintime.

Jung-uk Kim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20160804/e7d2cf28/attachment.sig>


More information about the svn-src-head mailing list