I have mentioned a few times on ethereal-dev and ethereal-users that
I am re-writing the display filter routines. I'm finally to the point
where I can show the re-write for review and suggestions.
Why re-write the routines if they already work? The grammar for the
dfilter routines was very complex, mostly because I was not experienced
in implementing compilers with yacc and lex. Ashok pointed out to me a long
time ago that I was trying to do too much work in the grammar; that's
why the grammar was convoluted and hard to follow.
Even though it was convoluted, the grammar worked. But it was hard
to extend, especially for anyone besides the original author. There's more
things that I want the dfilter language to support, but mashing new
functionality into the current grammar would have been a nightmare.
So I took Ashok's suggestion and simplified the grammar. The grammar now
only checks for grammatical correctness of the input. Another module checks
for the semantic correctness.
I also switched from using bison/yacc for the grammar to using lemon.
Lemon has a yacc-like syntax, but with a few improvements. I think the
syntax improvements make the grammar easier to read. The one really nice
thing I liked about lemon was that it is more helpful than yacc/bison
in creating a grammar which doesn't leak memory, even on a failed parse.
The lemon that is distributed here has two features the the current lemon
on the Internet does not have -- "t=" and "d=" command-line options
to specify the full path-name to the template file and to the output
directory. (I need these for the build system I use. I don't use 'make'
when developing Ethereal). The changes to lemon have been sent to the
author. He has acknowledged that he received the changes, but he has
checked the changes into his CVS repository.
The attached patch shows my current work. I need to test it more, and
enhance the error messages that a failed parse gives to the user (most
error messages are lacking still). Once I get that taken care of, and
take care of any changes that come up after this review, I'll check
the new dfilter routines into CVS.
Then the new dfilter routines follow. First, throughout the new routines
I have included support for alternations (like in Icon). The grammar
does not yet support them, but with little effort I'll be able to get
them working. This will allow an OR-like syntax as follows:
tcp.port == (80 | 8080)
Which is shorthand for:
tcp.port == 80 || tcp.port == 8080
Once alternations are in place, I'll use them to test against multiple
IP addresses from a DNS resolution. So, when a user filters via:
ip.src == www.ibm.com
the dfilter routines will see that the DNS resolves this hostname
to two IP addresses, and turns the display filter into:
ip.src == ( 204.146.81.99 | 204.146.80.99 )
Someone asked for using the name of stored filters inside a filter.
Say you have a filter called "firewall". Then you could use it
in a filter via some syntax. Let's say the ampersand, like the
syntax for a Perl subroutine:
tcp.port == 22 && &firewall
(I'm open to suggestions on the syntax)
Of course, for fields that have value_strings associated with them,
and for those that don't (like services), we should be able to use
the name instead of the number. The above could be given as:
tcp.port == ssh && &firewall
I also need to support string comparisons (but 0-terminated and
"length-prefixed" strings), and regular expressions. There have
been so many times that I really need to run a "packet grep"
when hunting down NFS problems. I need to grep for a filename in
a packet:
frame =~ /filename/
The dfilter routines also need to support time values.
Comments are welcome! More display filter language ideas are especially
welcome.
--gilbert
Attachment:
dfilter.diff.bz2
Description: Binary data
