On Mon, Jul 02, 2001 at 08:56:48PM +0000, [EMAIL PROTECTED] wrote:
> OS: Redhat 7.1 (kernel 2.4.2-2),
> libpcap: 0.6.2.
> tcpdump: 3.4-39.
>
> libpcap is returning usecs in timestamp where the 3 least
> significant digits are not changing (until reboot, where the
> value changes).
libpcap returns what it gets from the packet capture mechanism it uses;
the tcpdump on your system isn't running with a vanilla tcpdump.org
libpcap:
> Here is the tcpdump output:
> # /usr/sbin/tcpdump -i ppp0
> Kernel filter, protocol ALL, TURBO mode (575 frames), datagram
> packet socket
(ours doesn't put out that message). "TURBO mode" means it's using the
memory-mapped capture buffer mechanism in 2.4[.x] kernels, which means
the time stamp is probably being put into that memory-mapped buffer by
the kernel.
> Notice the "678" digits repeated in the timestamps. Is this a
> libpcap problem or a kernel 2.4.2-2 problem?
You should probably ask Red Hat about this; it's probably either
1) a failure of the code in the kernel that's putting the time
stamps there to get a valid high-resolution time stamp
(either because the code isn't correctly requesting a
high-resolution time stamp or because the code it's calling
to do so isn't correctly generating a high-resolution time
stamp)
or
2) an error in the libpcap with which the tcpdump on your system
is built.
> Problem can also be seen when running Snort (NIDS) and my own
> development code PasTmon.
...which rules out a tcpdump problem.
You might want to download an unmodified libpcap *and* tcpdump from
tcpdump.org, put their source directories under the same source
directory, and then build libpcap and then tcpdump, to ensure that you
have an unmodified tcpdump that's built with an unmodified libpcap
("ldd", when run on that tcpdump, should *NOT* report that it's
dynamically linked with "libpcap"!), and then try that one; that will
make sure that it's *not* using the libpcap that came with your OS, and
that it's not using the "turbo mode" code. (It should *NOT* print out
any message of the sort that the Red Hat tcpdump did - not even if it
says something different.)
If it has the same problem, it's probably a kernel problem with Red
Hat's version of 2.4.2.
If it doesn't have the same problem, then it's probably either
1) a problem with the "turbo mode" time stamp code
or
2) a problem with the Red Hat libpcap's way of fetching time
stamps.
(Another experiment might be to build a new kernel, with the "Packet
socket: mmapped IO" option - CONFIG_PACKET_MMAP - disabled, and boot
that kernel; then try the OS's tcpdump - it should now *not* report
"TURBO mode" - and see if the problem persists. If it does, the problem
is *not* specific to the "turbo mode" code. If it doesn't, it's
probably a bug in the "turbo mode" code in the kernel.)
-
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
