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