Re: Hardware Timestamping Problem

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

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

> > Am 10.06.2016 um 00:13 schrieb Guy Harris <guy () alum mit edu>:
> >
> > But that doesn't mean that the packets time stamped by the hardware when transmitted will be delivered to the 
> > PF_PACKET sockets used by libpcap *with the hardware time stamp as the time stamp*.
> >
> > In order make that happen, if hardware transmit time stamping is enabled for a PF_PACKET socket:
> >
> >      dev_queue_xmit_nit() will *NOT* deliver, to that socket, packets queued for transmission;
> >
> >      when the hardware says "I've transmitted these packets" (and time-stamped them), the driver will take those 
> > packets and deliver them to all PF_PACKET sockets with hardware transmit time stamping enabled?
> >
> > If those aren't done, then code processing packets from a PF_PACKET socket will get a mix of packets with software 
> > time stamps (packets sent by the machine on which that code is running) and hardware time stamps (packets received 
> > by that machine).
> >
> > I don't see any obvious code in dev_queue_xmit_nit() to avoid delivering packets to sockets that have requested 
> > hardware time stamping, so the first of those statements doesn't appear to be true; is the second one true?
>
> Perhaps I am wrong, but it seems the drivers deliver the sent packets, including the hardware-timestamp, to the error 
> queue of the socket.

And those don't just get delivered to the socket on which the packet was sent, they get delivered to *all* sockets, 
including the PF_PACKET sockets used for traffic capture?

If not, then the second statement doesn't appear to be true, either.

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers