Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Monitoring

From: Kevin Cullimore <kcullimo@xxxxxxxxxx>
Date: Fri, 21 May 2010 04:18:31 -0400
On 5/20/2010 5:15 PM, Jaap Keuter wrote:
On Thu, 20 May 2010 10:23:39 -0500, "mike@xxxxxxxxxxxx"
<mike@xxxxxxxxxxxx>  wrote:
  My suggestion/comment was based upon the notion that the bulk of the
  resources responsible for ultimately grinding a system to a halt are
  consumed not by the act of capturing, but by the act of analyzing a
given
  packet/set of packets to provide the "what's going on" information (an
  action which i'm informally equating with the term "decoding"). If this
is
Don't know, I only know that on a 4GB memory server, it eventually tells
me it is out of memory and wireshark dies. That's if I just leave it
running while going off on something else.

  in fact accurate, this would be the wrong tool to implement in an
attempt
  to provide insight without consuming resources.
I understand, just wondered if there was an option to monitor without
capturing.
Hi,

And I still don't know what you mean by 'not capturing'?

Definitions:
  capture: to acquire and collect network frames.
  monitor: to passively observe a phenomenon.

So, how do you monitor and network without capture?
What I think you mean is '...to monitor without dissection resulting in
state being build up eventually exhausting my platform resources." (phew)

So there you have it, you need capture, but can't have statefull detailed
dissection.
That's where tools like CACE Pilot, or ntop and the like come in. Or
devices which spit out netflow or sflow info.

Allow me to explicitly restate the assumption (based upon the posts of others within other threads) that motivated me to post to this thread: -you CAN capture (collect packet data) without "state being built up" via dumpcap or similar tools
-you can NOT montor/watch the packets using wireshark without
1. collecting packet data
2. building up state

Do inaccuracies lurk within that set of statements?
Thanks,
Jaap
___________________________________________________________________________
Sent via:    Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
              mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe