Gilbert,
> 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.
That's me - throw out random suggestions but don't bother to actually
implement them :-)
> 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
This is something I am not too sure about. Why should
tcp.port==(80|8080) not be equivalent to tcp.port==8080? (bitwise OR
of the port numbers). While for ports I can understand your
decomposition, a bitwise decomposition is very useful for things like
flag registers in packets. I'd then make the case that a single
approach would be good for ports and flags, which leads me towards
saying that tcp.port==(80|8080) is not the same as 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 )
Hmmm... so that's the reason. Well, the other option is not to build
this knowledge into the grammar, but just to implement the comparison
operator against DNS domain names to return TRUE if any of the matched
IP addresses are there. This would require taking more intelligence
out of the parser and building it into the semantics. However, I
actually do like your method somewhat - maybe a different operator
instead of '|'?
> 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)
I like the idea - maybe $firewall would be slightly more intuitive for
Perl programmers. Also, how about not having any disambiguating prefix
character at all? You could forbid filter names that are known
keywords (tcp, rsvp etc.) and then have a parse state at the end that
attempts to match any unmatched keyword against a list of filter
strings. So it would look something like this
tcp.port == 22 && 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/
This rules!
-Ashok
--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387
"31337 h4x0r d00dz r00lz" - Anonymous
