Re: Checksum filterable fields

[Alexis La Goutte <alexis.lagoutte () gmail com>]

On Tue, Jul 2, 2013 at 9:17 PM, <mmann78 () netscape net> wrote:

> 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.

Yes, sure, it is more flexible.

> 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)
Good idea also


> 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?

value_string.h ?
expert_info.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 <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 <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