Wireshark · Ethereal-dev: Re: [Ethereal-dev] Next release?

[Guy Harris <gharris@xxxxxxxxx>]

On Mon, Jan 20, 2003 at 03:09:41PM +1030, Glen Turner wrote:
> Gerald Combs wrote:
> 
> >     Unified filter syntax
> 
> Hi Gerald,
> 
> What are your wishes here?  To take the current "display
> filter" syntax and write code to compile it to the capture
> p-code run by libpcap?

One shouldn't wish for that, as I suspect that's impossible - there's
stuff you can do with display filters that I don't think is *possible*
to do with BPF code.  (Note: anything that involves a loop can't be done
with BPF code, unless there's a hard maximum on the number of loop
iterations and you have enough room in the BPF interpreter to unroll the
loop, as BPF has no backwards branches, and is unlikely to have them for
a long time, given that the intent of BPF was to allow untrusted code to
safely pass BPF programs into the kernel.  No, "I trust root" isn't
enough - on some platforms you can arrange that you don't have to be
root in order to capture packets.)

A *subset* of the current display filter syntax could, however, be
translated into either:

	1) a libpcap expression (i.e., the output of the parser would be
	   a text string to be fed to "pcap_compile()");

	2) a BPF program;

	3) a parse tree that could be handed to a libpcap routine.

1) would work with existing libpcap *and* would avoid the need to
reimplement the BPF code generator.  (A fair bit of work has gone into
that code generator and continues to go into it, so I'm not at all
convinced that the Ethereal team should try to maintain their own code
generator, especially given that at least one member of the Ethereal
team has also worked on the libpcap BPF code generator and continues to
do so. :-)  In addition, any improved BPF code generator really belongs
in libpcap, so *every* application using libpcap can use it, not in
Ethereal, where only Ethereal and Tethereal can us it.)

However, it might have to worry about which particular version of
libpcap it's using, as some filter expressions might be legal with some
versions and not with others, and not all filters could necessarily be
expressed in terms of the low-level arithmetic expressions supported by
the libpcap filter language.

2) requires that the BPF code generator be reimplemented; see
parenthetical note two paragraphs up for the reason why I don't think
that's a good idea.

3) requires a feature in libpcap that doesn't yet exist.  However, I
plan to implement it at some point; the intent is to have a
"pcap_parse()" routine that takes a string as an argument and returns a
pointer to the root node of a parse-tree-like tree (or, on error,
returns NULL and fills in an error buffer also passed as an argument),
and a "pcap_install_filter()" (or some such name) that takes a pointer
to the root node of such a tree, and a pcap_t, as arguments, and
generates code and installs it as a filter.

This would allow applications with their own filter expression to have
their own parsers, generate the parse tree themselves, and install a
filter generated from that parse tree.

It would *also* allow systems that have an in-kernel filtering mechanism
that doesn't use BPF (e.g., Solaris, with its CMU/Stanford stack-machine
packet filter, or Irix, with its mask-and-compare packet filter) to use
that mechanism *if* the filter can be handled by that mechanism -
"pcap_install_filter()" on that platform could try to generate an
in-kernel filter and:

	if it succeeds, install that filter as the in-kernel filter;

	if it fails, install no in-kernel filter and do the filtering
	with BPF in userland (assuming that the code generator doesn't
	return an error).  A further optimization might be to generate,
	if possible, an in-kernel filter that will throw out some of the
	uninteresting packets and have a BPF program to throw the rest
	out.

In addition, it might let libpcap handle operators like the "vlan"
operator more cleanly.  Currently, "vlan" causes all subsequent tests to
assume VLAN-encapsulated packets, which would work for

	vlan and host foobar

but wouldn't necessarily do what you'd want for

	(vlan and host foobar) or host bletch

if the intent is to accept VLAN-encapsulated packets to or from "foobar"
and non-VLAN-encapsulated packets for host "bletch".  (One could,
perhaps, argue that "host bletch" should test for both VLAN-encapsulated
and non-VLAN-encapsulated packets - *IF* the extra code that would
require in the filter doesn't slow down the filter too much, that
*might* be acceptable, but it does mean bigger BPF programs which might
exceed the in-kernel limits of various filtering mechanisms.)

3) also obviates the need to maintain our own BPF code generator.