ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protoco

Date: Mon, 16 Jul 2007 13:00:44 -0400
A follow-up answer to my original post (for posterity sake)...

fulko hew wrote on 07/16/2007 10:02:37 AM:

> I've scoured the READMEs and dissectors for details on the parameters
> for disector_add().  It seems as though all the cases are different
> than my (simple) case, so I'm at a loss as to how to register my
> sub-protocol, so it gets called properly.
>
> I have a private WTAP type for which I have written a simple dissector.
> (so far so good)  In that dissector it looks at some data in
> 'pinfo->psuedo_header->acn.proto' that I use to figure out what
> dissector to call next... Ie.  call_dissector(ipars_handle, tvb, pinfo,
> tree);
> For example:
>
> if (pinfo->psuedo_header->acn.proto == 0x5) {
>   call_dissector(ipars_handle, tvb, pinfo, tree);
> }
>
> But when wireshark tries to call my (sub)dissector I get the error:
>
>   Err  file packet.c: line 1710 (call_dissector): assertion failed:
(handle
> != NULL)
>
> Thats because right now I'm missing the dissector_add() in my
> (sub)dissector
> ... because I don't know what to code in my case.
>
>
>
> The normal approach is to have (for a frame level dissector):
>
>   dissector_add("wtap_encap", WTAP_ENCAP_MYTYPE, mytype_handle);
>
> OR something like this for a nested dissector (where its based
> on data in the super-frame (I think)):
>
>   dissector_add("ip.proto", SOME_INDICATOR, mytype_handle);
>
>
> But I in my case, my (sub)dissector protocol isn't a WTAP type,
> nor is it (really) sub-protocol of a super-frame type (in my
> first scenario).  Yes, it can also be found in all sorts of
> other encapsulations (that I'm not going to disect right now)
> but this is the primary case.
>
> What I think I want to is something like:
>
>   dissector_add("", NULL, mytype_handle);
>
> just to make it aribitrarily available for that explicit call.
>
> When I code later dissector, I'll probably have more dissector_add()
> entries that _are_ based on super-frame data, but not right now.
>
> Either my approach is wrong, or I'm just missing something...
> Any ideas ?

a) It seems as though register_disector() _is_ the correct routine
   to call in this case rather than some version of dissector_add().

I don't know what I was doing wrong (when I started from the
dissector template from README.developer), but I've now started
over by using packet-data.c as my template instead.

b) Whatever I did wrong was causing call_dissector() to call
   assert on the 2nd pass through (with a null pointer).






This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.