Wireshark · Ethereal-dev: [ethereal-dev] Suggestions

[Ashok Narayanan <ashokn@xxxxxxxxx>]

Hi, folks. As a relative newcomer here, (though I've been using
Ethereal with my RSVP extensions for a little while now), I have some
suggestions. These are things I'd really like to see in Ethereal, and
if nobody else is doing them I'd like to work on them myself.

1) Coloring

I've seen some traffic in the mailing list archives recently about
having different protocols colored differently. I have some ideas
about this (and have written some hacks to do it). Is anybody actively 
working on this? 

So, my thoughts are:

- I think we should have a mechanism where we can specify the colors
we want for each protocol. We can also have a default color map which
a user can select, which will assign colors to common protocols in
accordance with some well-known coloring scheme we'll code in. This
satisfies both camps of users - those who want to specify colors, and
those who don't.

- I think storing coloring information in .Xdefaults is not a good
idea. Also, putting it in .ethereal/prefs may not be best because you
can easily come up with 50-60 lines of color preferences and you don't 
want to bloat that file. Maybe a new file, .ethereal/colors?

- To implement something like this, we need a central "list of
protocols" to specify colors for etc. The simplest way would be to put 
'em all in a header file (at least those you are interested in
coloring for). Any better suggestions?

2) Protocol filtering

- The wiretap filtering grammar looks to be an excellent improvement
on BPF grammar, since it's extendable. I'll help out there if help is
needed. 

- We need GUI extensions for filtering (this is not news to you, I'm
sure). 

- A useful filtering scheme would be to filter on all packets in which 
a particular set of bytes match a particular pattern. Even more useful 
would be if you could select these. For example, you click on a
packet, expand it, click on a protocol, expand it, click on an object
within that protocol and select it (so it gets highlighted in the hex
dump). Now, you go to the menu and say "Find all packets in which
the selected bytes have the same value". Voila, it finds all those
packets. This is a really useful technique and folks in my group use it
all the time in Netmon (though they have to do a little more work
there to get this functionality). I'm halfway through writing it; but
if somebody has an equivalent or better solution, I'm all ears.

- There's also a set of filtering constraints which cannot be
expressed in byte-offset primitives, but which are protocol
specific. For example, in RSVP (my protocol of choice :-), a useful
filter would be to find all WF-style reservation messages. Now, what
defines a "WF-style" message cannot be expressed as an absolute byte
offset. The message has a number of objects, one of which is a style
object. So you need to parse the message to make this determination.

Where I'm getting with this is, we can make arbitrarily complex
filters by implementing an extension to the filtering mechanism. We
create new predicates (e.g. rsvp.resv.style) in the filter grammar,
and associate a function with this predicate. If this predicate is
found in the filter string, we call the function associated with the
subject of this predicate, for every applicable packet in the packet
stream. The function attempts to evaluate the predicate against the
packet, and returns TRUE or FALSE. If the function returns FALSE, the
packet did not match the predicate and should be thrown away. If the
function returns TRUE, the packet matches the predicate and expression 
evaluation should continue on this packet. There are a couple of
tricks you can use to optimize this so it's not so expensive. For
starters, you could call all relevant protocols at the start of every
packet so they can pre-parse and cache relevant information. Then the
predicate evaluation function would be quite fast.

Thoughts?
-Ashok

-- 
--- Ashok Narayanan ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387