Wireshark-users: Re: [Wireshark-users] Monitoring
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Fri, 21 May 2010 11:30:41 +0200
On Fri, 21 May 2010 04:18:31 -0400, Kevin Cullimore <kcullimo@xxxxxxxxxx>
wrote:
> 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

True. I've done that in a hospital network for months, without a glitch.

> -you can NOT montor/watch the packets using wireshark without
> 1. collecting packet data
> 2. building up state

True. As anyone who (accidentily) left Wireshark running while capturing
knows.
 
> Do inaccuracies lurk within that set of statements?

I don't think so.
So there's a gap which is filled by the other mentioned tools. 

Thanks,
Jaap