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
