> 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).
And if you have Ethereal keep around the state added as a result of
dissecting a frame, even if you "un-read" the frame, that means that
re-reading the capture won't give you the same information you got when
you originally did the capture, which may be considered rather
counter-intuitive.
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.
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".
> 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
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.
