Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
[EMAIL PROTECTED] wrote on 07/18/2007 11:29:00 AM:
> Well thats what (I think) I'm now doing, and yet, the value
> isn't registered, because the 'default' dissector gets called,
> not my ipars dissector.
>
> Obviously I'm not getting something right.
... snip ...
I'm following up on my own post... again...
I figured out what was wrong, and have ammended the code snippets
below (for posterity sake... for all others that may follow.)
- packet-sita.c --
disect_sita() {
...
if (!dissector_try_port(sita_dissector_table,
pinfo->pseudo_header->sita.proto, tvb, pinfo, tree)) {
call_dissector(data_handle, tvb, pinfo, tree); /* default decoder */
}
}
proto_register_sita() {
proto_sita = proto_register_protocol("SITA", "sita", "sita");
sita_dissector_table = register_disector_table("sita.proto",
"ACN protocol number", FT_UINT8, BASE_HEX);
register_dissector("sita", dissect_sita, proto_sita);
}
proto_reg_handoff_sita() {
sita_handle = create_dissector_handle(dissect_sita, proto_sita);
dissector_add("wtap_encap", WTAP_ENCAP_SITA, sita_handle);
}
- packet_ipars.c -
proto_register_handoff_ipars() {
register_dissector("ipars", dissect_ipars, proto_ipars);
}
proto_reg_handoff_ipars() {
ipars_handle = find_dissector("ipars");
dissector_add("sita.proto", ACN_PROTO_IPARS, ipars_handle);
}
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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
[EMAIL PROTECTED] wrote on 07/16/2007 06:12:02 PM:
... snip ...
> You could, for example,
... snip ...
>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
>
> and have the "ipars" dissector do
>
>dissector_add("acn.proto", 0x5, ipars_handle);
Well thats what (I think) I'm now doing, and yet, the value
isn't registered, because the 'default' dissector gets called,
not my ipars dissector.
Obviously I'm not getting something right. And thats got to do
with the function and relationship between proto_register_xxx()
and proto_reg_handoff_xxx() and what the job of each is, and what
I should be doing in each. :-(
So I'm concerned about a race condition regarding when
proto_register_sita() is called (that tries to add the
ipars handle to the table), with respectto when the
proto_reg_handoff_ipars() is called (creating the ipars
dissector in the first place).
I also tried putting the:
dissector_add("sita.proto", ACN_PROTO_IPARS, ipars_handle);
in proto_register_handoff_ipars(),
but that caused a run-time error about:
(dissector add): assertion failed (sub_dissectors)
- packet-sita.c --
disect_sita() {
...
if (!dissector_try_port(sita_dissector_table,
pinfo->pseudo_header->sita.proto, tvb, pinfo, tree)) {
call_dissector(data_handle, tvb, pinfo, tree); /* default decoder
*/
}
}
proto_register_sita() {
proto_sita = proto_register_protocol("SITA", "sita", "sita");
sita_dissector_table = register_disector_table("sita.proto",
"ACN protocol number", FT_UINT8, BASE_HEX);
register_dissector("sita", dissect_sita, proto_sita);
dissector_add("sita.proto", ACN_PROTO_IPARS, ipars_handle);
}
proto_reg_handoff_sita() {
ipars_handle = find_dissector("ipars");
sita_handle = create_dissector(dissect_sita, proto_sita);
dissector_add("wtap_encap", WTAP_ENCAP_SITA, sita_handle);
}
- packet_ipars.c -
proto_register_handoff_ipars() {
register_dissector("ipars", dissect_ipars, proto_ipars);
}
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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
[EMAIL PROTECTED] wrote:
> 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.
Some day, we should probably add a lot more stuff to the developer
documentation - and perhaps figure out what belongs in the developer's
guide and what belongs in README.* files. I'll look at adding stuff to
README.developer, at least, when I have some time.
>> 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?
None, really, from the standpoint of the Wireshark core. The underlying
mechanisms for dissector tables are intended to let you choose a
dissector based on a numeric or string value, regardless of where that
numeric or string value came from.
> and/or why are there two routines?
To which two routines are you referring?
> Is there another API called disect_data(), or do you mean
> calling call_dissector(my_handle, ...), or
> something completely different?
There is, but you should call it through a handle (handles, among other
things, allow dissectors with different APIs - "old-style" and
"new-style" dissectors - to be called without the caller knowing or
caring what API the dissector uses; they also allow plugins to get hold
of dissectors defined in other plugins, and to get hold of dissectors
defined in libwireshark on Windows without libwireshark having to export
them in libwireshark.def).
You'd declare
static dissector_handle_t data_handle;
and, if dissector_try_port() fails, do
call_dissector(data_handle, tvb, pinfo, tree);
and, in your register-handoff routine, do
data_handle = find_dissector("data");
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add( ) for a non-nested protocol
On Tuesday 17 July 2007 14:50, [EMAIL PROTECTED] wrote: > Wow. thanks for that great explanation. > It makes me wonder if I'm not missing any API documentation somewhere? > I built a API reference using doxygen from the /epan directory. This helped me a lot for finding the right enum values and functions especially for the tvb stuff. Most of the code contains doxygen comments. regards, Gerhard. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
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.
[EMAIL PROTECTED] wrote on 07/16/2007 06:12:02 PM:
>
> On Jul 16, 2007, at 7:02 AM, [EMAIL PROTECTED] 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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
On Jul 16, 2007, at 7:02 AM, [EMAIL PROTECTED] 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.
> 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
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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] what parameters for dissector_add() for a non-nested protocol
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 ?
TIA
Fulko
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.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
