Thanks for the quick reply. > > I know this problem was discussed before on the list (msg: > > http://www.tcpdump.org/lists/workers/2001/07/msg00001.html), and we tried > > that, but we still have the same problem. > > Tried what? > First we tried enabling the real time clock support for RH and rebuilt the kernel and the libpcap from the source, but that only provided a partial solution. The timestamps became more accurate, but still seemed to be taking "slices" of time and not down to the usec. > Using an unmodified libpcap and tcpdump from tcpdump.org, as per my > followup to the cited message: > > http://www.tcpdump.org/lists/workers/2001/07/msg00002.html > > If so, then, as per the aforementioned followup, the problem is probably > in the Linux kernel's time-stamping code. As such, I'd take this up > with Red Hat, as it appears not to be a problem with tcpdump.org's > libpcap code; the code we use to get the time stamp on Linux is > > if (ioctl(handle->fd, SIOCGSTAMP, &pcap_header.ts) == -1) { > snprintf(handle->errbuf, sizeof(handle->errbuf), > "ioctl: %s", pcap_strerror(errno)); > return -1; > } > Cool. That's what I was afraid of - might be more of a RH kernel issue. Looks like it's time to poke around the kernel and see what's going on there. Thanks again for the help, Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.nist.gov =============================================================== - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
