> Am 10.06.2016 um 01:35 schrieb Guy Harris <g...@alum.mit.edu>: > > On Jun 9, 2016, at 4:09 PM, Guenter Ebermann > <guenter.eberm...@googlemail.com> wrote: > >> >>> Am 10.06.2016 um 00:13 schrieb Guy Harris <g...@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?
They are only delivered to the socket on which the packet was sent, not to all PF_PACKET sockets. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
