Date: Thu, 4 Aug 2016 14:08:26 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r303733 - head/contrib/libpcap Message-ID: <764bf543-5f62-cc7b-1242-8beccdaecd61@FreeBSD.org> In-Reply-To: <20160804124849.Y1045@besplex.bde.org> References: <201608032008.u73K8dWe047330@repo.freebsd.org> <20160804124849.Y1045@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WPUmx6nhvLfEEqmwUK46eCPiTf309HanG
Content-Type: multipart/mixed; boundary="qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m"
From: Jung-uk Kim <jkim@FreeBSD.org>
To: Bruce Evans <brde@optusnet.com.au>
Cc: src-committers@freebsd.org, svn-src-all@freebsd.org,
svn-src-head@freebsd.org
Message-ID: <764bf543-5f62-cc7b-1242-8beccdaecd61@FreeBSD.org>
Subject: Re: svn commit: r303733 - head/contrib/libpcap
References: <201608032008.u73K8dWe047330@repo.freebsd.org>
<20160804124849.Y1045@besplex.bde.org>
In-Reply-To: <20160804124849.Y1045@besplex.bde.org>
--qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 08/03/16 11:40 PM, Bruce Evans wrote:
> On Wed, 3 Aug 2016, Jung-uk Kim wrote:
>=20
>> 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
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>>
>> --- head/contrib/libpcap/pcap-bpf.c Wed Aug 3 19:23:22 2016 =20
>> (r303732)
>> +++ head/contrib/libpcap/pcap-bpf.c Wed Aug 3 20:08:39 2016 =20
>> (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 =3D bhp->bh_tstamp.bt_sec;
>> + bt.frac =3D bhp->bh_tstamp.bt_frac;
>=20
> 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 =3D=3D PCAP_TSTAMP_PRECISION_=
NANO) {
>> + struct timespec ts;
>> +
>> + bintime2timespec(&bt, &ts);
>> + pkthdr.ts.tv_sec =3D ts.tv_sec;
>> + pkthdr.ts.tv_usec =3D ts.tv_nsec;
>=20
> 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.
>=20
> X contrib/libpcap/pcap-bpf.c: pkthdr.ts.tv_usec =3D
> bhp->bh_tstamp.tv_usec/1000;
>=20
> This is to convert for tv_usec actually being tv_nsec on AIX. If the a=
bove
> 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 */
>=20
> Banal comment. The complexities are from what sort of timestamp this i=
s.
> It is obviously a timestamp.
>=20
> This bh_tstamp is in struct bpf_hdr32 for the !BURN_BRIDGES case. Ther=
e
> 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 =3D ts.bt_f=
rac;
>=20
> This is in the !BURN_BRIDGES && COMPAT_FREEBSD32 case. Since struct
> timeval32
> always has a 32-bit tv_usec, this assignment discards the most signific=
ant
> bits in bt_frac but keeps the noise.
>=20
> X sys/net/bpf.c: hdr_old.bh_tstamp.tv_usec =3D ts.bt_frac;
>=20
> This is in the !BURN_BRIDGES && !COMPAT_FREEBSD32 case. Since tv_sec i=
n 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
--qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m--
--WPUmx6nhvLfEEqmwUK46eCPiTf309HanG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXo4SiAAoJEHyflib82/FGX0YIAI/E9KvCRHzud6RN9lLkCVeV
vPDUispwCy/6W7AndExODK759XP+L0PhB7KKovyXjs4FIcA/lRQ5ewDJJJFFbtR+
hnnXY4wQ/PXbJAE0LV8kdLTdNsab9VQ2YQQH09d2rLlE4ek4yCJymofv3WdN+pzV
eXvAKMvSc02ryCEl1iGaBEIaAw9vRb2pozLewyGNv1S21fPUO+rJ5bP0qu6DngEH
OvjV4+bPUdCdVcxg16x+EUuMSFTAxPLamOo3MbzrsSFXwOu6Q3CrySW+bnf4ZKyX
Cw2dwBBqvsqgIOkucXoLMAUulzNtIjNRHUD8kIKm8Al9VTZZvhR4yJQTQf+mMBE=
=obGg
-----END PGP SIGNATURE-----
--WPUmx6nhvLfEEqmwUK46eCPiTf309HanG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?764bf543-5f62-cc7b-1242-8beccdaecd61>