> Why not implement the colors as filter actions with a default set
> loaded?
Yes, I'd been thinking that we should let you assign colors based on
arbitrary expressions, not just protocol types.
Network Monitor has two different types of filters - a "capture filter",
which controls which packets get saved on a live capture (similar to the
filter handed to "libpcap" on a live capture, although the NetMon ones
aren't as powerful as the BPF ones), and a "display filter", which
controls which packets get shown on a capture you've gotten from a file
or finished doing live. The latter type of filter expression can also
be used to search forward or backward in a capture; we could use them to
assign colors as well.
The NetMon "display filter" is much fancier than even a BPF-style
capture filter - you can filter based on source or destination
addresses, based on protocol types (so you don't have to, say, construct
some expression involving the port number just to say "DNS packet"), or
based on particular packet fields for particular protocols. Gilbert's
working on some infrastructure changes that would make the last of those
easier to do:
> Date: Mon, 31 May 1999 09:49:52 -0500
> From: Gilbert Ramirez <gram@xxxxxxxxxx>
> To: ethereal-dev@xxxxxxxx
> Subject: Re: [ethereal-dev] NetBIOS continuations and unknown SMBs
>
> On Sat, May 29, 1999 at 09:52:56PM -0500, Guy Harris wrote:
> >
> > One possibility might be the Network Monitor-ish scheme I've mentioned,
> > where *all* the decoding is done, purely sequentially, when the capture
> > is read in, with a list of "property instances" being attached to the
> > frame for all of the fields in the frame, and with the detailed display
> > being constructed from the list of "property instances" for a frame when
> > the frame is clicked on.
>
> I am currently working on an initial implementation of this. For now,
> I'm only decoding the frame into a list of properties when the user
> clicks on the frame. However, it could be modified to decode all packets
> sequentially.
>
> >
> > 2) the ability to have a display filter that can select "all NFS
> > requests with a file handle of XXX" or "all SMB OPEN requests
> > with a pathname of YYY" (although that could also be done by
> > having the dissection code capable of being asked to check,
> > for fields it decodes, for specific values, and have "search
> > for a packet that match this filter" or "show me only packets
> > that match this filer" operations run sequentially through
> > the file dissecting each frame with the "check for a match"
> > option).
>
> This is why I'm doing the implementation. I figured it would be much
> easier to write powerful display filters in ethereal, since all the
> decoding logic is there, instead of using BPF filters in wiretap.
So this would let you say "show all DNS packets in shocking pink" fairly
straightforwardly (you'd construct a filter expression based on
"protocol == DNS", and select shocking pink as a color - yes, NetMon did
offer me a fairly shocking pink color when I tried that when I was
checking to see where it remembered the color settings), and you could
also say "show me all NFS requests with a file handle of XXX in nuclear
banana yellow" (yes, that's apparently a real color name, too; our F230
file-server appliances had a front bezel in that color).
