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 _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
