Wow. thanks for that great explanation.
It makes me wonder if I'm not missing any API documentation somewhere?
And if I'm not... stuff like this should be there.
It would certainly save you a lot of time answering
what are probably basic developer philosophy issues.
BTW. I have read the README.developer, the "developer's guide",
the 'coding for Ethereal' chapter from the Syngress book, and
the Wiki, but nowhere did I see info as clear as your response here.
And its very important, because it seems as thought this is one
of the fundamental design points in developing dissectors.
Note: I also have two embedded followup questions below.
wireshark-dev-bounces@xxxxxxxxxxxxx wrote on 07/16/2007 06:12:02 PM:
>
> On Jul 16, 2007, at 7:02 AM, Fulko.Hew@xxxxxxxxx wrote:
>
> > 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);
>
> The normal approach, if you have a value of *any* sort (whether it's
> the link-layer encapsulation type, a field in a protocol, a field in a
> pseudo-header, a user preference, the current phase of the moon, ...)
> is to have
>
> dissector_add(dissector table name, value in that table,
> mytype_handle);
>
> The distinction between the two cases you give is not a distinction
> that the Wiretap code makes, nor is it a distinction that we want to
> make in the documentation.
Then what _is_ the significance of the distinction?
and/or why are there two routines?
> > 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).
>
> As indicated, that doesn't mean you shouldn't have a dissector table
> and have sub-dissectors register in it. You could, for example,
> create a dissector table named "acn.proto" (or "acn_proto", or
> "roland.the.headless.thomson.gunner" - the name is not tied to
> anything else in Wireshark other than the calls that add to it) by
> calling "register_dissector_table()":
>
> acn_dissector_table = register_dissector_table("acn.proto", "ACN
> protocol number", FT_UINT32, BASE_HEX);
>
> have the dissector for your private WTAP type do
>
> if (!dissector_try_port(acn_dissector_table, pinfo->pseudo_header-
> >acn.proto, tvb, pinfo, tree))
> call dissect_data to dissect the data, or something such as that
Can you elaborate a little on this?
Is there another API called disect_data(), or do you mean
calling call_dissector(my_handle, ...), or
something completely different?
> rather than checking for different values of pinfo->pseudo_header-
> >acn.proto, and, for example, have the "ipars" dissector do
>
> dissector_add("acn.proto", 0x5, ipars_handle);
>
> > What I think I want to is something like:
> >
> > dissector_add("", NULL, mytype_handle);
> >
> > just to make it aribitrarily available for that explicit call.
>
> As you've discovered, if you want to have a dissector callable via
> call_dissector(), you have to register that dissector by name with
> register_dissector() - and you find the handle for the dissector by
> calling find_dissector() with that name.
>
> However, that's not necessarily what you want to do.
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.
