Re: Hardware Timestamping Problem

[Guy Harris <guy () alum mit edu>]

On Jun 9, 2016, at 4:47 PM, Guenter Ebermann <guenter.ebermann () googlemail com> wrote:

> They are only delivered to the socket on which the packet was sent, not to all PF_PACKET sockets.

Then Christian can't get what I think he wants with libpcap - or anything else doing PF_PACKET socket capturing on 
Linux - without doing some kernel hacking.  It sounds as if he wants a program to passively watch incoming and outgoing 
traffic, and gets hardware time stamps for both types of packets.

So he's getting software time stamps on outgoing packets and hardware time stamps on incoming packets.  The 36-second 
delta is probably, as Francesco Fondelli noted, due to the software time stamps being 
seconds-since-January-1-1970-00:00:00-UTC and the hardware time stamps being seconds elapsed since January 1, 1970, 
00:00:00 *TAI*.

We need to, at minimum, update the documentation to indicate that you will *not* get hardware time stamps for packets 
sent by the machine running the libpcap-based application, and possibly to do something such as, if hardware time 
stamping is requested on a platform that can't supply hardware-time-stamped packets to libpcap, either refusing to 
allow hardware time stamping is selected and a "incoming packets only" direction specified or forcibly setting 
"incoming packets only" in that case.

(I.e., the way things currently work in the Linux kernel, hardware time stamps are useful only for a machine plugged 
into a network and promiscuously doing passive sniffing on the traffic between two other machines.)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers