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

[guy@xxxxxxxxxx (Guy Harris)]

(This may also be a retransmission.)

> There's another way to do this, which may or may not be
> better. Basically, each protocol implements it's own filtering
> mechanism. It has it's own dialog box for filtering where you can
> enter filtering info. For example, you can activate an OSPF filter by
> clicking on some menu item which opens an OSPF filter dialog box,
> where you can then add things like "show me all messages relating to
> area 10". This information is stored by the OSPF filtering module in
> some internal format.

As, say, a "struct header_field_info" structure, specifying that the
protocol has fields like "Area ID", of a given type (but *NOT*
specifying the offset of that field)? :-)

That's what Gilbert's changes are doing.

Particular *instances* of that field, as attached to a particular
packet, have a particular offset, but "show me all messages relating to
area 10" turns into, say, selecting a display-filter expression of type
"Field", as per my other mail (or "Property", as it's called in Netmon),
looking at the "Area ID" field of the "OSPF" protocol, and comparing it
against 10.

In fact, I have, sitting in front of me, an "Expression" dialog box from
Netmon on which I've selected precisely that.

> Now, when a packet is read into Ethereal, it basically looks to see if 
> any filters are active. If a filter is active, it simply calls the
> filtering function associated with that filter, passing it the
> packet. The function looks at the packet, does it's thing, and returns 
> TRUE or FALSE depending on whether the packet passes the filters or
> not. 

The filtering isn't done when you read packets into Ethereal from a
capture; you initially get the full unfiltered capture, and can then say
"limit the display to only packets that match this filter expression",
or can say "search for the next packet that matches this filter
expression", or "color all packets that match this filter expression hot
pink", or whatever.  (Except for the ability to select a color, that's
what Netmon offers; the "Edit Display Filter" button (the one with the
funnel on it - a nice intuitive icon, like most icons :-() lets you do
the first of those, and the "Edit Find Frame" button, "Find Next Frame"
button, and "Find Previous Frame" button (with the binoculars) let you
do the second of those.)

> The advantage of this technique is that it is somewhat distributed and 
> robust. You don't need to do this two-phase processing with the
> trees.

The two-phase processing may have other advantages; for example, it lets
you decode *all* packets, in strictly sequential order, to handle the
fact that, in many cases, you have to know What Has Gone Before in order
to understand a particular packet, without decoding each packet on a
first pass, *without* saving the results of the decode, and having to
decode them all over again if you

	select the packet in the summary pane, so you can see the
	detailed display;

	set up a display filter, which requires that all packets be
	decoded *again* to see if they match the filter (note that your
	RSVP filter will have to decode the packet...);

	set up a search filter, which requires that you decode the
	packets as you skip through them, looking for the next one to
	match the filter.

> I feel that capture filtering can be 
> quite basic (even just protocol number is fine),

"Just protocol number" (if by that you mean TCP and UDP port numbers, or
even if you mean TCP and UDP port numbers, *and* protocol numbers in IP
headers, and Ethernet types/SAPs in link-layer headers, and the like)
isn't enough; sometimes I may want to see traffic between two hosts, no
matter what the protocols are, or see traffic of a particular type
between two hosts.

I'd like, at minimum, to get the kind of filtering expressions you get
from "tcpdump" - which is, right now, the kind you get from Ethereal as
well.  Given that much of that can be done by a kernel CMU/Stanford
packet filter module such as you find in SunOS 4.x and 5.x, and it can
all be done with a BPF packet filter module such as you find in a pile
of other UNIX-flavored OSes, you can get most of that with the stuff you
have in most kernels, and it can be done in the kernel, thus avoiding
copying packets up to userland only to be thrown out by a userland
filter.

> Are you planning to include both libpcap and wiretap in the same
> image.

That's what we're doing now; "libpcap" for live captures (as "wiretap"
doesn't yet support that), and "wiretap" for reading capture files (as
it can read capture files other than "libpcap" capture files).

*However*, that doesn't mean we can't make "wiretap" do a better job of
capturing than "libpcap" can; "libpcap" doesn't, for example, use the
CMU/Stanford packet filtering stuff in SunOS - if you don't have BPF in
your kernel, you have to get every single packet passed up to userland
to be filtered there.  It also doesn't handle very well capturing from
multiple interfaces, which can be handy.

Given that, I would *NOT* recommend pulling filtering out of wiretap;
I'd recommend beefing it up, although that's not something we need to do
now, as we can use "libpcap" for now.