As Guy Harris said:
>
> A display filter, to limit which of the packets are shown in the summary
> view, can be constructed out of, among other things, relational
> operations on properties - depending on the type of the property,
> different relational operators are possible, such as "equals", "doesn't
> equal", "greater than", etc.. One could, for example, say "show all ARP
> packets where the 'Opcode' property equals 1", or "show all NFS ops
> where the 'Filename' property equals 'hello_sailor.c'". (Well, one
> could if it let you specify a string value; it's not clear that it
> does....)
(what's the "it" in "if it let you specify a string value"? libpcap?)
This is an important point. The display-filter language can be more
powerful than the capture filter language. Right now ethereal uses the
filtering available in libpcap for both capture and display filters.
Libpcap uses BPF instructions to do filtering; this BPF filtering is
limited to the type of fields it can read and to which fields it actual
reads. For example, no one is going to write a string-comparison test in
BPF bytecode. And only certain fields in each packet header are known to
libpcap (I hope to increase the number of filterable fields in wiretap, but
wiretap will only know about fields that are pertinent to capturing
packets).
By separating the display-filter language from the capture-filter language,
we suddenly have the ability to [display] filter on any field in the packet
header, including strings. We could even have a regular-expression matching
function.
Separating the two filter languages is a good thing to do. Syntacticaly,
the capture filter can be a subset of the display filter, if you're worried
about learning new filter syntaxes. But with the right GUI interface, the
differences between the 2 syntaxes can be hidden.
--gilbert
--
Gilbert Ramirez Voice: +1 210 358 4032
Technical Services Fax: +1 210 358 1122
University Health System San Antonio, Texas, USA
