Wireshark-dev: Re: [Wireshark-dev] Is it better to have dissected and lost than never to have d
On Thu, Nov 19, 2015 at 9:57 PM, Michael Mann <mmann78@xxxxxxxxxxxx> 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.
