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

[guy@xxxxxxxxxx (Guy Harris)]

(This may be a retransmission; it might've gotten lost inside NetApp.)

>  > 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.
> 
> Yeah, but I'm leaning towards a per-protocol GUI filter. The reason is 
> that I don't feel that all possible useful filters can be expressed in 
> simple fields.

Yes, but it might be nice to have the code to handle those filters that
*can* be expressed simply by relational operators on fields be common
code, so each protocol doesn't have to implement *everything* - for
example, the IP code doesn't need to know how to filter for "IP source
address = 192.9.200.1", that can be handled by common code.  The common
code would know that the protocol "IP" has a field "source address", of
type "IP address" (where the type says it's 4 bytes and big-endian, and
that routine XXX can be used to convert the value to a string and
routine YYY can parse a string and either turn it into an IP address
value or return an error; those routines *themselves* might be part of
a particular protocol decoder, but the common code would know how and
when to call them).

This wouldn't mean you *couldn't* have protocol-specific filters; to use
the Netmon example, the "Expression" dialog box would have, in addition
to a tab for "Protocol" (to select packets of a particular protocol
type) and "Field" (to select based on the value of a particular field
for a particular protcol - Netmon calls this "Property"), and perhaps
one for "Address" (Netmon has that - it selects on the contents of the
address fields of the summary display, letting you select traffic
between two addresses, or traffic from one address to another but not in
the opposite direction, and is a bit of a convenient alternative to
selecting, for example, two expressions for "source IP address" and
"destination IP address"), there'd be one to select protocol-dependent
expressions.

Note that your example:

> - 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.

could probably be done by the mechanism Gilbert's putting in.  An object
in RSVP might, say, be done as an item with subfields:

	Length

	Class-Num

	C-Type

	one or more subfields for the object contents

If Class-Num is STYLE, the subfields might be:

	Flags

	Option Vector

with Option Vector further decoded as bitfields.

If (unlike Netmon, from what I can tell) we allow display filters to
look at particular bitfields, we could look for, say, all packets where
"Sharing control" was 01 and "Sender Selection control" was 001 (I'm
inferring, from page 85 of RFC 2205, that

      The low order bits of the option vector are determined by the
      style, as follows:
   
              WF 10001b
              FF 01010b
              SE 10010b

means that WF means binary 10 001, i.e.  sharing control is binary 10
and sender selection control is binary 001.

Even if you *can't* look at particular bitfields, and can only look at
"Option Vector" as a whole, a hex value of 0x000101 for that vector
appears, from what I've looked at just now of RFC 2205, to mean WF.

Such a match *wouldn't* look at a particular offset in the packet; it'd
look at all the fields in the packet that were "Option Vector" and match
them against 0x000101, or at all the fields that were "Sharing control"
and match them against binary 10 and all the fields that were "Sender
selection control" and match them against binary 001.

(If they're enumerated bitfields, you could match them against "Distinct
reservations" and "Wildcard", respectively.)

And, yes, you have to parse the packet to do this; the display filters
could look at the *result* of the parsing, not just at the raw packet
data at particular offsets - that's the intent behind Gilbert's changes.

>  > 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.)
> 
> And I feel this is not a bad thing. IMHO, capture filters should be
> really simple and fast.

I agree.

However, BPF filters are, I have the impression, reasonably fast
(although I guess you could perhaps speed them up a little more by
having the kernel packet-filtering code take the BPF program and compile
it into a lump of machine code - it'd have to be careful not to assume
that N-byte fields are aligned in situations where they might *not* be
aligned, of course - in case they're not fast enough), *and* they offer
a fair bit more power than Netmon's capture filter.

I like being able to filter on TCP or UDP port numbers, as well as on IP
addresses; I can do that with BPF (or even with the CMU/Stanford packet
filter that SunOS 4.x and 5.x have and that "snoop" uses), but I can't
do that with Netmon.