Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Is it better to have dissected and lost than never to have d

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 19 Nov 2015 23:29:18 -0800
On Nov 19, 2015, at 6: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).

I ran into that once when trying to make all dissectors new-style.

Now I can't remember what dissectors it was, or how to find them.

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

Once you've changed a column or added anything to the protocol tree, you don't get to return an "this isn't for me, let somebody else dissect it" indication.

> Also, should we clean up a tree if a new-style dissector returns 0 (within the functions in epan/packet.c)?

No.  A dissector should only return 0 if there's nothing *to* clean up.