Wireshark-users: Re: [Wireshark-users] Continuous/circular in-memory tracing?

From: Sake Blok <sake@xxxxxxxxxx>
Date: Sat, 22 Dec 2007 14:51:38 +0100
On Sat, Dec 22, 2007 at 02:38:24PM +0100, Jaap Keuter wrote:
> Jay Levitt wrote:
> > On 12/22/2007 4:01 AM, Sake Blok wrote:
> >> On Fri, Dec 21, 2007 at 10:10:45PM -0700, Stephen Fisher wrote:
> >>> On Fri, Dec 21, 2007 at 10:00:54PM -0500, Jay Levitt wrote:
> >>>
> >>>> As far as I can tell from searching the forum, there's no good way to
> >>>> keep Wireshark up and running and capturing to an in-memory circular
> >>>> buffer,
> >>> Correct.
> >> But... Wireshark comes with a utility called 'dumpcap'. Although
> >> this utility does write to disk instead of memory, it does not
> >> keep session-information. This means that it doesn't hog your
> >> memory while capturing for long periods of time. I have a system
> >> running with dumpcap for a few weeks now, it has captured almost
> >> 2 billion packets by now in a ring buffer of 1024 files of 16MB.
> >> (and the laptop on which it is running is still happy :-)  ).
> > 
> > Could you expand on "does not keep session information"?  I assumed that 
> > the only difference between doing it with dumpcap and doing it within 
> > Wireshark was the lack of a loaded GUI.
> 
> Wireshark is a multi-layered application. Below is a capture driver 
> interfacing with the OS to get packets, aka libpcap. On top of that is 
> the capture engine handling packet retrieval and storage, aka dumpcap. 
> On top of that is the dissection engine, one text mode variant, aka 
> tshark, and a GUI variant, aka wireshark.
> 
> So running dumpcap to capture and store packets forgoes the dissection 
> part, which can become processing and memory intensive.

The memory intensive part comes from the fact that Wireshark (and Tshark)
likes to keep track of things to be able to interpret things that follow.
For example, to be able to decrypt SSL traffic, it follows the key
negotiation and uses the user provided private key to build the
master keys for the communication. This info is kept in memory and
will never be cleared. Not even when a new file is opened in the
ringbuffer (otherwise it will lose the capability to decrypt the
continuation of the SSL session in the next file.

In short, there is conversation info that is building up which will
eat up your memory, slow things down and bring everything to a...

...stop! :(

Dumpcap does not interpret what it sees, it sole purpose in life is to
grab packets of the wire(less) and to drop them to disk. And it is 
quite happy to do so for you :-)


> >> The syntax I used is:
> >>
> >> dumpcap -i <interface> -s 1518 -w <file.cap> -b filesize:16384 -b files:1024
> >>
> >> How's that for catching an intermittent problem :-)
> > 
> > That's pretty darn intermittent! :)
> 
> Well, I've a similar setup running, started somewhere in June this year, 
> and still going happily about its business, on the platform handling 
> call control for a hospital. I _never_ would use wireshark for that, but 
> dumpcap is ideal.

:-)


Sake