Re: Is it better to have dissected and lost than never to have dissected at all?

[Evan Huus <eapache () gmail com>]

On Thu, Nov 19, 2015 at 9:57 PM, Michael Mann <mmann78 () netscape net> wrote:
> This question has probably been asked before, so I thought I'd at least put
> a Tennyson twist on it.
>
> I started getting more serious about converting dissectors to the "new
> style".  I submitted a bunch of patches where it was obvious that the
> dissectors fell into the "give me everything" category.  My biggest worry is
> the comment made by Guy in bug 11134
> (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11134#c13), that some
> dissectors want to "accept" a tvb (packet) as their own, but don't actually
> parse any bytes (so it appears that they would "return 0" with the new
> style).  So the remaining ones I'm taking more slowly (with the attitude of
> unsure means leave as old style) and if anyone know of protocols that behave
> this way, feel free to convert them (or send me a note)
>
> The case I keep coming across that I'm not sure how to deal with is
> dissectors that get a few bytes in (and have already created trees/items for
> a few fields), and then decide they aren't going to dissect anymore because
> of a "bad" field value (most commonly "version" or "length").  Should we
> apply a consistent rule for this?  Like if you're not going to dissect
> "versions" you don't support, check before making trees and just not bother
> with expert info saying "version isn't supported" while ceasing dissection.
> Or dissect as "latest version" (or at least "a" version), but with the
> expert info applied that the version is unknown.  I'm not sure which
> scenario users would appreciate more, but I'd like to see it applied as
> consistently as possible. I believe my preference is for using expert info,
> but continuing dissection.

I'm OK with that.

> Are such rules more critical for popular protocols like Ethernet, IP and
> TCP/UDP where there are possibly "shared" values for a subdissector
> identifier?
>
> Also, should we clean up a tree if a new-style dissector returns 0 (within
> the functions in epan/packet.c)?  I think the expert info would be harder to
> clean up, but I'm also not sure of the difficult of the trees either.

As Guy said, a dissector should not be returning 0 if it's added any
tree items. If we can tell when this occurs, we should make it a
DISSECTOR_BUG.

> Opinions welcome, but I'd like to see the "new" style be the "only" style by
> the 2.2 release.

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