Ethereal-dev: Re: [Ethereal-dev] Next Release: Win32 NSIS installer pendingquestions
From: "Guy Harris"
|
| On Feb 4, 2004, at 12:02 PM, Greg Morris wrote:
|
| > Color filters are a great way for new users to be able to quickly
go
| > through a trace to locate errors. I have a set of color filters
that I
| > distribute to my users that flags retransmisssion, NCP, SMB,
SRVLOC,
| > etc... error return values as Red.
|
| Is that a "set of color filters", or a *single* color filter?
|
| If it's a *single* color filter, perhaps the color filter list
supplied
| with Ethereal should have only one filter that checks for *all*
errors
| in *all* protocols.
But that will considerably slow down the processing of packets in the
current implementation of Ethereal (as the CList is colored in
advance, not *iff* it is visible). That's also the reason why I'm
still not sure whether the CList is the way to store all packet
data... but that's another discussion.
| > The remaining color filters that I do is based on protocol so I
color
| > TCP packets one color and DNS packets another. Much the way that
| > Sniffer
| > does so that it gives the user much the same look and feel. I
think we
| > just need to come to an agreement as to what colors fit for what
| > protocols.
|
| You're presuming that such an agreement would be possible; I don't
know
| that everybody wants the same color filters. (I would, personally,
| uninstall any default color filter file installed on my machine -
color
| filters slow down capture loading, and, shocking as I suspect this
| would be to many Ethereal users from what some users say, *I just
don't
| use color filters at all*.)
I tend to disable color filters when processing large capture files,
and enable them when I am looking at smaller ones. This is not always
true however. But... many novice users only look at smaller captures
for which the impact of alpplying color filters is not that high. As
said in a previous mail, I'd like to have a preference controlling the
color filter usage, so I don't need to rename the color filter file to
obtain the same result. This preference could go in the existing
colors pane (sorry guys, I'm not a Gtk+ programmer and I don't want to
ruin the lay-outs).
| Perhaps if a site or organization wants to package a version of
| Ethereal with a set of color filters useful in their environment,
they
| should do that; I'm not convinced that one can come up with a set of
| color filters useful for everybody, other than, perhaps, a singleton
| set with "mark errors in red" as the only such filter.
Color filters serve a purpose. Depending on the purpose, the color
filter will vary too. Hence my roposal to create a library of
purpose-written color filters (maybe something we can add to the
Ethereal web site). We should do the same for display filters, and
maybe for capture filters too (but here the dependency on the BPF
version is crucial).
| > Display and Capture filters - Yes these are unique to your
environment
|
| I *didn't* make that argument about display and capture filters;
that's
| the one set of configuration files where I *don't* see an issue
(other
| than the lack of system-wide filter files) with supplying a default
| file.
Hmmm... I'm rethinking the need for a global color filter file. The
reason is the purpose of it - there is no single purpose to an
Ethereal user. Some use it to debug protocol implementations, others
to track network problems, others want to know what's going on in
those bits and bytes for educational reasons...
Regards,
Olivier
