Guy Harris wrote:
>
> > I really like the idea to have ring buffering but I also like
> > the capability to do the real time display at the same time.
>
> Unfortunately, the way the real-time display works is that, in effect,
> it reads the capture file as packets arrive - and operating with a ring
> buffer means, in effect, that packets discarded from the ring buffer are
> "un-read", and there's no provision in Ethereal for "un-reading"
> packets...
>
> ...and, given that the dissection of a frame may depend (and often
> *does* depend) on what came in the frames previous to it, it's not clear
> how one *can* make Ethereal capable of "un-reading" packets (without
> removing from Ethereal all state information in dissectors, which would
> severely limit their ability to dissect frames).
Sorry, I almost never have interest of dissectors that need to keep state
information from previous frames :-). But I agree with you. It would be
hard to "un-read" packets.
> Furthermore, if we eventually do reassembly without keeping frame data
> around in memory until the capture file is closed (this requires that
> random access to gzipped capture files be made efficient, but other
> things require that as well), "un-reading" frames would cause additional
> problems.
Yes.
> I.e., whilst it might be *nice* to have that feature, I'm not sure that
> feature can be implemented in a consistent fashion; "feature XXX is
> nice" doesn't necessarily mean "it's technically possible to implement
> feature XXX in a way that doesn't suck".
I agree, this is why I was proposing the following ... ;-)
> > So I wonder if the possibility of
> > ignoring packets (i.e. do not save them in the captured file) based on
> > the capture as well as display filter would be of interest. In such as case
> > it would be possible to track down a problem with a complex display filter
> > in real time without having disk or memory usage problem ...
>
> Tethereal *already* lets you do that - use "-R" rather than "-f" in a
> live capture. Ethereal could do the same - although the question then
> would be whether this should be implemented by
>
> 1) having a check button in the "Capture Preferences" dialog box
> that specifies whether the filer is a capture or display
> filter, which is a bit ugly
>
Or having a capture filter like now and a check button that specifies that
packet that does not pass the current display filter shall not be saved
as well ...
> or
>
> 2) having Ethereal treat it as a capture filter if it can be
> parsed as one and a display filter if it can't be parsed as a
> capture filter but can be parsed as a display filter, which
> runs the risk that the people who currently ask the Ethereal
> list "why doesn't 'ip.addr == 127.0.0.1' work as a filter?"
> instead blithely use display filters and possibly find that
> Ethereal can't keep up with the network traffic because it's
> seeing *every* packet and running the
> considerably-more-expensive display-filtering process on all
> of them.
We need both to save CPU time. I.e. a limited capture filter and a more
powerful display filter which could be on option a "second level capture
filter" in user land ...
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | laurent.deniel@xxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
