Color filters are VERY personal but maybe there is a subset that most people
agree on.
(I personally HATE when normal packets are colorized just because they are
of a certain protocol.
But many of my colleagues use colors that way.
Myself I prefer if ONLY packets showing errors are colored and nothing
else)
I
like this color filter and think it would make sense to add it to the
system :
Name: TCP Errors and events
Filter: tcp.analysis.flags
Background: RED
Other RED filters could be checksum errors or other types of invalid
packets.
Maybe a filter that marks all SMB errors, all ONC-RPC errors, and all DCERPC
errors in orange?
I.e. marks all protocol response codes that indicate error as orange?
Then maybe a set of filters that mark all smb.time, rpc.time, dcerpc.time,
ldap.time etc all the response times
and filter xxx.time > 0.050 or something and mark them yellow?
RED : protocol errors
ORANGE: protocol response is error
YELLOW: response was too slow
?
Then all colors make sense. RED show a protocol violation or packetloss
effects in TCP
ORANGE shows when the application responds with an error but the packets
themself were ok.
YELLOW show when the application is ok but just a bit slow.
----- Original Message -----
From: "Greg Morris"
Sent: Thursday, February 05, 2004 7:02 AM
Subject: Re: [Ethereal-dev] Next Release: Win32 NSIS installer
pendingquestions
> 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. This way the user can quickly browse
> through the summary and identify any errors. I know that a wish list
> item to have intellegence built into Ethereal to flag errors has not
> been completed but color filters help to provide this mechanism. It
> doesn't trap for problems like an intellegent algorythm might but it
> does provide as a useful tool when quickly analyzing a trace. In fact it
> does a much better job then NAI's Sniffer Pro expert.
>
> 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.
>
> Display and Capture filters - Yes these are unique to your environment
> but to a new user or one that is unfamiliar with the syntax, It is nice
> to be able to provide sample filters. For example - ether host
> xx:xx:xx:xx:xx:xx with the name of Capture by MAC Address. These can be
> basically used as templates by users to quickly configure a filter
> instead of having to call someone or look it up. I used to get many
> calls from my end users asking how to create a filter. Since providing
> the sample filters, I haven't received a single call.
>
> All in all, everything but the preference file itself should be
> provided if at all possible. It makes Ethereal user friendly. Sure the
> expert Ethereal user will not need or might not even desire to have
> them, but as Ethereal becomes more and more popular these will become a
> valuable asset. Anything we can do to help users use the tool will only
> make the tool that much more popular.
>
> My 2 cents,
> Greg