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

[Guy Harris <guy@xxxxxxxxxx>]

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

The stuff you're doing should help that, in that, for example, a GUI
could get a list of all the fields at which it can look, as well as at
all the protocols it can select.

> > - 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.
> 
> You mean using an offset from the beginning of a protocol layer?
> Like,
> 	tcp[5:3] = 01:02:03
> 
> Or even with a field?
> 
> 	tr.dst[0:3] = 00:00:f6  (madge token-ring cards!)

For the display filter, the version of Netmon I have appears to require
you to select a property (its equivalent of the field-based stuff you're
doing for Ethereal display filters) in order to get at stuff at a given
byte offset in the packet, so it's not clear whether it lets you say
"are the N bytes at offset X equal to Y?").

The capture filter lets you look at bytes starting at a given offset
from either the start of the frame or from the start of the link-layer
payload.  (Unfortunately, that, address matches, and SAP/Ethernet type
matches are *all* it lets you do; for example, it appears not to have
any way, short of manually constructing it with the "bytes starting at a
given offset" stuff, to do a capture filter based on TCP or UDP port
numbers.)

> > - 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
> 
> In my scheme, the rsvp protocol dissector would attach fields to the
> logical tree. You can duplicate as many field types as you want.
> Basically, anything you can decode via C can be added to the tree. And
> then we can filter on it.

That mechanism is basically Netmon-inspired, so it should let people do
the same sort of stuff in Ethereal display filters that Netmon lets you
do in its display filters.

Ashok, are you referring to *capture* filters, or *display* filters?