Ethereal-dev: [Ethereal-dev] Re: New dissector for CIGI

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Sat, 3 Dec 2005 11:07:10 +0000
On 12/3/05, Guy Harris <gharris@xxxxxxxxx> wrote:
> ronnie sahlberg wrote:
> > On 12/2/05, Harms, Kyle J <Kyle.J.Harms@xxxxxxxxxx> wrote:
>
> >> 2,
> >> README.developer does not mention anything about a new style dissector.
> >> Where might I look at an example of such a dissector?  I might suggest
> >> that the README.developer stub be updated to be a new style dissector.
> >
> > Ok,  remind me i must update that.
>
> ...although the *current* form of new-style dissector has some problems:
>
>  1) it can't distinguish between "the tvbuff we were handed had zero
> bytes in it" and "the tvbuff we were handed wasn't a packet for my
> protocol" - and, yes, there are some cases where this makes a difference.
>
>  2) having to return the amount of data dissected is more work than is
> necessary just to return an accepted/rejected indication - but there are
> some places where the calling dissector really *does* need to know how
> much was dissected.
>
> That's why I haven't just converted all dissectors to new-style ones and
> renamed new_create_dissector_handle(), etc. to create_dissector_handle().
>
> If dissectors were handed a ptvcursor, and returned TRUE or FALSE,
> that'd handle some of that, but it'd still mean that the dissector
> should advance the ptvcursor regardless of whether it does a full
> dissection or not.  Given that dissectors often don't work correctly
> when *not* doing a full dissection (i.e., when passed a null protocol
> tree pointer), because they skip some offset-advancing or
> subdissector-calling (or possibly other operations) when the tree
> pointer is null, perhaps we should discourage checking whether the
> protocol tree pointer is null, even if that does mean dissectors do more
> work than is necessary.

Maybe a solution is having two entry points for a dissector:
For all dissectors
first make it new-style or heuristic
and register it either for all ports as a normal heuristic dissector
or for a specific port.

dissect_X() would be the real dissector.


dissect_X_heur() is a heuristic dissector and registered either for
"all" ports as normal heuriostic dissectors or for a specific port
(such as the SNMP dissector)

it performs heuristics to determine if this is X or not.

if it is NOT X or the tvb is too short to determine that   it will
return 0 and reject the packet.

if it looks like X it will dissect the packet,    set a conversation
dissector and return !=0.


dissect_X_conv() is a conversation dissector and this will perform
heuristics to check if it is NOT X.

If the packet is too short to determine or if it is not sure it can
reject it it will dissect the packet and return !=0

If the packet is long enough to perform the heuristics and it can
definitely say this is NOT X then it will reject the packet and return
0.