On Fri, Jul 27, 2001 at 12:42:28PM -0500, Andy Brown wrote:
> Here's the bug: When tcpdump exits due to a SIGINT or SIGTERM, the
> cleanup() function in tcpdump.c is called as the signal handler. This
> function does not do a pcap_close() before exit()ing. I'm running
> tcpdump 3.6, but verified this bug still exists in 3.6.2.
>
> The impact is this: When a BPF (filter) is used, some of the output is
> lost when written to a file. When a bpf is not used, libpcap doesn't seem
> to buffer. I'll leave this up to the experts :)
Note that "XXXXX packets received by filter", on some platforms, means
"XXXXX packets were handed to the filtering code, some of which may have
been discarded because they didn't match the filter", whilst, on other
platforms, it means "XXXXX packets passed the filter".
Systems with BPF and systems (such as Solaris) with DLPI fall into the
former category, so the fact that you have:
> 0:root@ajstats:packetstats# tcpdump -i hme1 -w test tcp & sleep 10; kill %1
> tcpdump: listening on hme1
> 83751 packets received by filter
> 0 packets dropped by kernel
>
> 0:root@ajstats:packetstats# tcpdump -n -r test | wc -l
> 42987
means only that not all of those 83751 packets were actually handed by
libpcap to tcpdump - the ones that weren't TCP packets were counted but
not handed to tcpdump.
"pcap_close()" closes the *input* stream, not the *output* stream, so
not doing "pcap_close()" doesn't mean that some packets seen by tcpdump
won't be written to the file.
"pcap_dump_close()" is what closes the output stream - but all it does
is call "fclose()" on the stream; exiting will close all open standard
I/O streams, so stuff will get written to the file.
-
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
