Wireshark mailing list archives

Re: Checksum filterable fields


From: mmann78 () netscape net
Date: Tue, 2 Jul 2013 15:17:08 -0400 (EDT)


I like your idea better as it provides a little more flexibility "under the covers" as well as a single function call, 
but I would like to limit the number of filterable fields necessary.

I would say just hf_..._checksum, hf_..._checksum_valid (with enum for unknown/good/bad), and ei_...checksum (for bad 
only).

Only thing to worry about is consistent naming conventions with the display filters themselves (not sure if that can be 
worked into checkdisplayfilter.pl or checkAPIs.pl)

Also, I'm not sure where the value_string for the enumeration of unknown/good/bad would go - tfs.h? (yes I know it's 
more than boolean value), proto.h?


-----Original Message-----
From: Alexis La Goutte <alexis.lagoutte () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Tue, Jul 2, 2013 3:05 pm
Subject: Re: [Wireshark-dev] Checksum filterable fields




Hi Michael,


Good topic !

I thought the same thing when I changed the vrrp dissector (about checksum).

I looked all dissectors and as you say every dissector is different about checksum...



my idea is to create a proto_tree_add_checksum and pass in arg : checksum, chucksum_computed, hf_..._cheskum, 
hf_..._good, hf_..._bad, ei_...checksum...)

Regards,






On Thu, Jun 27, 2013 at 10:13 PM,  <mmann78 () netscape net> wrote:




I logged something into Bugzilla for now (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8859) if anyone has any 
other thoughts.  I have too many other half-completed "ideas" resulting in too many changed files to tackle this now in 
one swoop.  
 
As for the coloring rule, thanks for the heads up, but I think I should be able to update them accordingly, possibly 
using the "expert info" (display) filter instead of the pure dissector display filter.



-----Original Message-----
From: Christopher Maynard <Christopher.Maynard () gtech com>
To: wireshark-dev <wireshark-dev () wireshark org>

Sent: Thu, Jun 27, 2013 3:38 pm
Subject: Re: [Wireshark-dev] Checksum filterable fields



 <mmann78@...> writes:

Perhaps all checksum validations could be an enumeration of 
"-1" (or "2"?) - unknown/disabled
"0" - good
"1" - bad

The TCP dissector does something similar for the window scaling factor.  If
the 3-way handshake isn't captured, then the scaling factor is unknown and
set to -1.  So, there is some precedence at indicating unknown values using
-1, and if changes are to be made, then -1 would be my vote.

If we're already going to take a hit with changed display filter names in
the name of consistency, why not go all the way?

I like consistency, so it's fine by me.  Just my 2 cents though.

Removing the bad_checksums does have at least 1 drawback though, and that's
that several of them are used in default coloring rules, so if they're
removed, users will likely end up with several warnings of the form:

Warn Could not compile color filter "Checksum Errors" from saved filters:
"<protocol>.checksum_bad" is neither a field nor a protocol name.



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev

Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


 




___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe






___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

 
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: