What might work is another tool: Shadow. We've used that for much the same
thing, and get definitive captures. Another way to minimize some of the impact
would be to only capture packet headers and maybe some subset of the data
payload to get an idea of what's going on. You could then cover what you're
talking about, probably with less of a challenge.
An idea, anyway.
Richard Berry
berryr@xxxxxxxxxxxxxxxxxxx
Message: 2
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Guy Harris" <guy@xxxxxxxxxx>
Cc: "McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>,
<Alistair.McGlinchy@xxxxxxxxxxxxxxxxxxxxx>,
<ethereal-users@xxxxxxxxxxxx>
Subject: Re: [Ethereal-users] Three big problems
Date: Tue, 5 Nov 2002 18:31:54 +1100
From: "Guy Harris"
Sent: Tuesday, November 05, 2002 8:11 AM
Subject: Re: [Ethereal-users] Three big problems
On Tue, Nov 05, 2002 at 08:02:36AM +1100, Ronnie Sahlberg wrote:
There are reasons why it may not be a really good idea to capture for
several days at a time.
Even at reasonably slow rates such as 75Mbit/s every packet will still
add
to the state buildup inside ethereal until you reach a point where
memory is exhausted.
Only if you're reading a capture. While Ethereal is doing a capture, it
won't do that, as it's just reading the raw data of a packet, doing a
*VERY* minimal dissection of the first part of the packet so that it can
update the appropriate packet count, and writing the raw data to a
capture file (unless it's an "Update list of packets in real time"
capture - but, in that case, it's reading the capture).
But that only applies if you do not use any capture filters, right?
If you use capture filters (display filter form) in order to minimize the
amount
of captured data, [t]ethereal will do a complete dissection of every packet
and thus state information will
build up?