Wireshark · Wireshark-dev: Re: [Wireshark-dev] Checksum filterable fields

[mmann78@xxxxxxxxxxxx]

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@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
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@xxxxxxxxxxxx> 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@xxxxxxxxx>
To: wireshark-dev <wireshark-dev@xxxxxxxxxxxxx>

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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev

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

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

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