On Fri, Jul 02, 1999 at 01:05:57PM -0500, Ashok Narayanan wrote:
>
> 1) It should not be compulsory to register each and every
> field. Complex protocols like RSVP and SMB will essentially end up
> doubling their code size or more. There should be a default value for
> hfindex which indicates "put this in the tree here, but I don't ever
> care about filtering on it". This also gives a smooth upgrade strategy
> for the various protocols - we keep adding filter registers
> gradually, so we don't have to do the entire thing at one shot.We just
> add HF_INDEX_DEFAULT to all calls to proto_tree_add_item. We can't
> filter on these fields, but we can still decode and view them.
That sounds like a workable approach. I'll see what I can do to
implement that... then ethereal won't be crippled when this code is
checked in.
> 2) We need graphical filters which will generate these expressions. I
> can work on this one.
Yes, absolutely. Ethereal would benefit from different styles of UI for
filters. I find the NAI's DOS-based Sniffer filter interface useful.
While you can build complex expressions with it, it also has fields for
simple filters: you select the source/dest addresses you want to see
(dlc, ip, ipx), and which protocols. Very simple.
I once tried to use Sniffer Pro's filter GUI (on WinNT). The GUI was not
simple; I could not at a glance figure out to relate everything with
their little tree of ANDs and ORs. Somehow a tree of logical expressions
doesn't work in a GUI.
I've been thinking that a really net GUI for creating filters would be
an acyclic graph. I'm envisioning the graph shown in the BPF paper by
Van Jacobsen et al. The user creates relations (ip.src eq A, eth.dst eq
X), and little ovals are placed on a drawing area. The user can move the
True and False lines coming out of these ovals to connect to either
other ovals, or a final True or False.
START
|
|
+-------------+
| ip.src eq A |
+-------------+
| |
True | | False
| |
+--------------+ |
| eth.dst eq X | |
+--------------+ |
| | |
True | | False |
| | |
| | |
| \ |
| \ |
| \ |
| \ |
TRUE FALSE
It seems interesting to me, but I don't know how useful it would be to
others. I think it would be easier to understand than a GUI representing
an AND and OR tree.
> 3) BPF expression format is familiar only to people who use UNIX
> sniffers & tcpdump. C expression format, on the other hand, is
> familiar to basically everyone. How about accepting C expressions
> (i.e. (ip.version==4) && (ip.tl>120))?
It should be easy enough to relate == -> eq, && -> and, and || -> or in
my parser implementation.
thanks for the ideas!
--gilbert
