Re: timestamp in pcap/tcpdump

[Cheng Cheng <ccheng.leo () gmail com>]

Hi Guy,

Then I have another question regarding timestamp in pcap.

In order to get the accurate receiving timestamp of a packet on the NIC
device not supporting hardware timestamping, can I modify the NIC device
driver code to update skb_shared_hwtstamp struct by using TSC in RX routine?

Will pcap support to retrieve such timestamp from skb_shared_hwtstamp?

Thanks!
Cheng


From: Guy Harris <guy <at> alum.mit.edu>
> Subject: Re: timestamp in 
> pcap/tcpdump<http://news.gmane.org/find-root.php?message_id=%3cB1CE4965%2d2B23%2d4C5B%2dAC57%2d9CE147FDA99D%40alum.mit.edu%3e>
> Newsgroups: gmane.network.tcpdump.devel<http://news.gmane.org/gmane.network.tcpdump.devel>
> Date: 2012-11-25 10:13:35 GMT (22 hours and 30 minutes ago)
>
> On Nov 24, 2012, at 9:50 PM, abhinav narain <abhinavnarain10 <at> gmail.com> wrote:
>
> > hi,
> >  I am looking for timestamp provided by pcap header and later used by
> > tcpdump.
> > Seems like some of wireless drivers do not provide the mac tsf timestamp.
> > I can't figure out the timestamp meaning in pcap.
> > Its surely not the time when packet arrived at the driver (referring to
> > tsft).
>
> It's the time that whatever part of the networking stack, including the packet capture mechanism (BPF,
> PF_PACKET sockets, WinPcap driver, DLPI, etc.), or possibly the network adapter itself, decides to
> time-stamp the packet.
>
> > Looking at old pcap (not using mmap), it seems this is got by ioctl system,
> > which is a deprecated mechanism ( I suppose) and not many drivers provide
> > ioctl implementation.
>
> Not all ioctls go to the driver.
>
> In the case of Linux, packets come from skbuffs, and skbuffs get time-stamped at various points in the
> receive path.  (Yes, I'm too lazy to go looking for them. [image: :-)]) When a packet is read from a PF_PACKET socket 
> by
> a recvmsg() call, the packet's time stamp is copied to the socket's time stamp, and the ioctl returns the
> time stamp from the socket, so it returns the time stamp from the last packet read.  (At least as of the 3.0.4
> kernel, that's done in a sock_recv_ts_and_drops() call in packet_recvmsg(); it might be different in
> other kernel versions.)
>
> > On the other hand, I don't have any idea how the mmap code is getting the
> > packet timestamp !
> > Can someone throw light on this ?
>
> See tpacket_rcv().  It does, for example (again, 3.0.4 kernel, which is the last version I downloaded to my
> Linux kernel source pile):
>
>       switch (po->tp_version) {
>       case TPACKET_V1:
>
>                       ...
>
>               if ((po->tp_tstamp & SOF_TIMESTAMPING_SYS_HARDWARE)
>                               && shhwtstamps->syststamp.tv64)
>                       tv = ktime_to_timeval(shhwtstamps->syststamp);
>               else if ((po->tp_tstamp & SOF_TIMESTAMPING_RAW_HARDWARE)
>                               && shhwtstamps->hwtstamp.tv64)
>                       tv = ktime_to_timeval(shhwtstamps->hwtstamp);
>               else if (skb->tstamp.tv64)
>                       tv = ktime_to_timeval(skb->tstamp);
>               else
>                       do_gettimeofday(&tv);
>               h.h1->tp_sec = tv.tv_sec;
>               h.h1->tp_usec = tv.tv_usec;
>               hdrlen = sizeof(*h.h1);
>               break;
>       case TPACKET_V2:
>
>                       ...
>
>               if ((po->tp_tstamp & SOF_TIMESTAMPING_SYS_HARDWARE)
>                               && shhwtstamps->syststamp.tv64)
>                       ts = ktime_to_timespec(shhwtstamps->syststamp);
>               else if ((po->tp_tstamp & SOF_TIMESTAMPING_RAW_HARDWARE)
>                               && shhwtstamps->hwtstamp.tv64)
>                       ts = ktime_to_timespec(shhwtstamps->hwtstamp);
>               else if (skb->tstamp.tv64)
>                       ts = ktime_to_timespec(skb->tstamp);
>               else
>                       getnstimeofday(&ts);
>               h.h2->tp_sec = ts.tv_sec;
>               h.h2->tp_nsec = ts.tv_nsec;
>
>                       ...
>
>               break;
>       default:
>               BUG();
>       }
>
> which is processing an incoming skbuff and copying the appropriate time stamp from the skbuff to the
> memory-mapped ring buffer (or, if there is no time stamp, setting it to the current time).
>
> > The ioctl could be traced to another function call on struct sock *, but I
> > have not been able to comprehend the meaning of the timestamp provided.
>
> The meaning is "some time more or less related to the time of arrival of the packet, but, unless it's a
> hardware time stamp, don't rely on it being set to a time that's as close to the actual arrival time of the
> packet as you might like". [image: :-)]  For example, don't assume you can time network events down to the nanosecond
> with the time stamps from libpcap/WinPcap unless it's on an OS that supports hardware time stamping with a
> libpcap that can get those time stamps from the OS (which I think means "Linux and FreeBSD") and with a
> network adapter that supports hardware time stamping (I don't know if any 802.11 adapters do) and that has
> a driver for your OS that supports hardware time stamping and the program doing the capture and the system
> doing the capture are set up to do hardware time stamp
>  ing.
>
> _______________________________________________
> tcpdump-workers mailing list
> tcpdump-workers <at> lists.tcpdump.orghttps://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers