https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5931
Summary: Random older ring buffer files not deleted, accumulate
until manually deleted
Product: Wireshark
Version: 1.4.6
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: TShark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: stcrye@xxxxxxxxx
Build Information:
TShark 1.4.6 (SVN Rev 36706 from /trunk-1.4)
Copyright 1998-2011 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (32-bit) with GLib 2.22.4, with WinPcap (version unknown), with libz
1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8, with c-ares
1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3, with Gcrypt 1.4.6,
with
MIT Kerberos, with GeoIP.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008).
Built using Microsoft Visual C++ 9.0 build 21022
--
Although this problem was mentioned in passing in Bug 3333, it will also happen
with high consistency using tshark.
Because I use tshark to capture Cisco ERSPAN GRE encapsulated traffic with a
libcap input filter, and because it is not possible to also use a display
filter (even with a chain of piped tshark instances), I'm forced to do
post-processing of ring-buffer files with tshark, editcap and mergecap. I
typically look at 20-100 Mbps packet streams from remote sites, and have to
sift through them in semi-real time for law enforcement purposes, looking for
particular MAC addresses or Apple UDIDs. When I get a "hit" I have the system
send me a text.
Because the data rates vary wildly from almost zero to 100 Mbps, schemes based
on using time to size the ring buffer files will fail. So, I configure ring
buffers of 5-10 files about 20-100 MB in size, copy them to a working folder,
apply the display filters, then merge and remove duplicates. I then delete the
contents of the working folder copy the ring buffer files to the working folder
and repeat.
The older ring buffer files that are not deleted accumulate at the rate of
about 3 per hour. Because the GUI is not running, the explanations and
work-arounds of Bug 3333 do not apply. Because the post-processing batch files
have to work on all the files in the ring buffer, as the older ring buffer
files accumulate the post-processing takes longer and longer, and eventually
cannot keep up with the newest ring-buffer files. My work around is to manually
delete the ring buffer files every hour or so, but this defeats the purpose of
the automatic monitor.
The problem happens at about the same rate on any computer I use, ranging from
slow to very fast with lots of RAM.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.