Re: [tcpdump-workers] Hardware Timestamping Problem
Yes, the exact same packet. Am 08.06.2016 um 22:40 schrieb Guy Harris: On Jun 8, 2016, at 1:29 PM, Christian Rupp wrote: The Timestamp when tcpdump grabs the package off of the receiver is 36 seconds( +/- innaccuracy, here roughly +/- 5-10 µs) after the timestamp when tcpdump grabs the package of the sender. "The" packet in the sense that you have two tcpdumps, one running on each of the servers, and the time stamp for a single given packet captured by the tcpdump on the machine that sent it is about 36 seconds earlier than the time stamp for the *exact same* packet captured by the tcpdump on the machine that received it? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
Guenter Ebermann wrote: > Hardware timestamping of sending/receiving buffer descriptors is done > by NIC. Receiving I understand. Are you sure that the hardware is going to timestamp sent packets, and then turn around and send the back to the kernel? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
The experiments I made today actually suggest that in my case tcpdump uses the hardware clock for incoming packages and the software/unix clock for outgoing packages. I changed the System clock of one Server with date -s and then looked at the capture of Ping packages. Incoming packages on the changed server used the hardware clock while outgoing packages used the changed system clock. Is there a way to change that? Am 09.06.2016 um 15:47 schrieb Michael Richardson: Guenter Ebermann wrote: > Hardware timestamping of sending/receiving buffer descriptors is done > by NIC. Receiving I understand. Are you sure that the hardware is going to timestamp sent packets, and then turn around and send the back to the kernel? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 09.06.2016 um 15:47 schrieb Michael Richardson : > > Guenter Ebermann wrote: >> Hardware timestamping of sending/receiving buffer descriptors is done >> by NIC. > > Receiving I understand. > > Are you sure that the hardware is going to timestamp sent packets, and then > turn around and send the back to the kernel? Yes, the driver must monitor tx descriptor consumption by hardware anyways. E.g. Freescale enhanced three speed ethernet controller (eTSEC) can timestamp send buffers - it writes the timestamps to the beginning of the buffer descriptor. You use such a controller feature to implement PTP (IEEE 1588). For Linux drivers supporting hardware timestamping see [1], chapter 5.3.2. The i350-T4, handled by Linux driver igb, is also supported (igb_ptp.c). It seems it does also timestamp tx buffers. [1] http://linuxptp.sourceforge.net/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
On Jun 9, 2016, at 1:19 PM, Guenter Ebermann wrote: >> Am 09.06.2016 um 15:47 schrieb Michael Richardson : >> >> Guenter Ebermann wrote: >>> Hardware timestamping of sending/receiving buffer descriptors is done >>> by NIC. >> >> Receiving I understand. >> >> Are you sure that the hardware is going to timestamp sent packets, and then >> turn around and send the back to the kernel? > > Yes, the driver must monitor tx descriptor consumption by hardware anyways. 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? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 10.06.2016 um 00:13 schrieb Guy Harris : > > 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. They all call skb_tstamp_tx() to do this, after the hardware has transmitted the packet and time-stamped it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Hardware Timestamping Problem
On Jun 9, 2016, at 4:09 PM, Guenter Ebermann wrote: > >> Am 10.06.2016 um 00:13 schrieb Guy Harris : >> >> 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
Re: [tcpdump-workers] Hardware Timestamping Problem
> Am 10.06.2016 um 01:35 schrieb Guy Harris : > > On Jun 9, 2016, at 4:09 PM, Guenter Ebermann > wrote: > >> >>> Am 10.06.2016 um 00:13 schrieb Guy Harris : >>> >>> 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
Re: [tcpdump-workers] Hardware Timestamping Problem
On Jun 9, 2016, at 4:47 PM, Guenter Ebermann 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
