Re: [ethereal-dev] Proposing some ethereal projects ...

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Sat, Jul 29, 2000 at 04:25:23PM +0200, Bert Driehuis wrote:
> Well, I know what you're getting at here. It took me quite some time to
> realize that Follow TCP Stream was just setting a display filter that I
> could clear with the button in the lower regions of the window. With my
> end-user hat on, I was looking to un-select the checkmark in the menu
> (to find there is none), then proceeded to check the Edit Filters menu.
> I didn't work it out until recently and just restarted Ethereal after
> following a stream.

The ability to quickly filter a display to show only packets in a given
TCP stream (or other connection) is useful.

However, it may be that this should be decoupled from the ability to get
the contents of such a stream displayed in a separate window.

(It may also be that the ability to get the contents of such a stream
displayed in a separate window should include the ability to do so for
non-text protocols.)

> That said, I consider this to be a minor issue. The biggest thing to me
> is the two sets of filter languages: the libpcap syntax for the capture,
> and the display filters for the rest (and that would be a biggy, if at
> all possible, to reconcile).

It would, I think, be possible to translate a *subset* of the display
filter syntax into libpcap syntax (some stuff you can do in display
filters is difficult or impossible to turn into a BPF program).

The question then would be whether we should support *only* that syntax,
or also support libpcap syntax.  We could do the latter by, if a capture
filter expression cannot be parsed by Ethereal's parser (which turns the
expression into a libpcap expression), we try parsing it as a libpcap
expression, and complain if that doesn't work, either.