> Date: Sat, 25 Oct 2003 07:56:48 +1000
> From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
> Subject: Re: [Ethereal-dev] Display filter as stop condition
> To: <sford@xxxxxxxxxxxxx>, <ethereal-dev@xxxxxxxxxxxx>
> Message-ID: <011301c39a79$b9886570$6501010a@C5043436>
> Content-Type: text/plain; charset="iso-8859-1"
>
> VERY COOL.
> This is something Tethereal really really would need.
>
> However, I have some comments:
>
> While display filters are very powerful, they also require allk the packets
> to be fully disected.
> This si slow and it also starts consuming more and more memory while
> tethereal runs.
>
> On the other hand, capture filters does not require the packets to be
> dissected, neither do they cause
> the internal state in tethereal to start building up.
>
>
> Therefore, so that it will be possible to capture at much higher speeds and
> for much longer intervals,
> could you consider changing it to use capture filters instead of display
> filters?
>
>
>
> From: <sford
> Sent: Saturday, October 25, 2003 5:23 AM
> Subject: [Ethereal-dev] Display filter as stop condition
>
>
> > I've added a "Halt" feature to tethereal that uses a display filter as
> > a stop condition. It is supplied as a string argument to "-H". It
> > can be very useful for troubleshooting to see what led up to a
> > particular condition (kindof like setting a breakpoint with an
> > emulator). Combined with ring buffer, you can just start it, come
> > back the next morning and have a good snapshot.
> >
> > I appologize for not adding the same feature to GUI ethereal (I
> > wouldn't even know how to start), but for my purposes, this is
> > exactly what the doctor ordered (capturing on a text-only box,
> > analyzing with a GUI). I've tested it on Linux (RedHat 8.0) and
> > Windows (2K).
> >
> > I'm not familliar with the code (I downloaded and saw it for the first
> > time this morning), but a few hour's examination led to the following
> > patch. Hopefully it is not too much of an abomination.
> >
> > Steve
>
>
Well, that stop capture thing was on my to do list for quite a while now, happy that someone started this issue, as I'm not familiar with the capturing details :-)))
I would love to add this feature into the GTK part (ethereal capture dialog), but I 'm currently busy of changing other GTK things, maybe I will find some time in the near future for doing this.
IMHO: The best solution of using capture or display filters for this is to be able to use both, and let the user decide which one to choose, as the capture filters are much faster, but the display filters are much more flexible, especially when you want to debug application protocol things.
Some addtions things to think about:
-Give the ability to start an external program (to ring a bell, trigger some hardware, ...) when condition appears.
- Capture some more data (let the user decide how much), after trigger condition appears (to be able to do some post trigger analysis)
So maybe it should be called "trigger" and not "stop condition" ?!?
Don't get me wrong, all the things I have mentioned are things for the future.
I think you have added an INVALUABLE feature, (t)ethereal misses for a long time... :-)
Regards, ULFL
______________________________________________________________________________
Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) -
bei der Stiftung Warentest - ein Doppelsieg! http://f.web.de/?mc=021184