On Mon, 8. Jan 2001, Guy Harris <guy@xxxxxxxxxx> wrote:
>> I have a dissector_table and a port number. I want
>> to get the portocol id of the protocol dissector
>> registered under port in the dissector_table. How
>> do I get it?
>
>Currently, there's no way to do that; dissectors don't have protocol IDs
>associated with them.
>
>Something to more closely tie protocols and dissectors will probably be
>checked in at some point, as it's needed for other purposes.
>
>> I need this id for proto_is_protocol_enabled.
>
>Typically, "proto_is_protocol_enabled()" is used either in the
>"CHECK_DISPLAY_AS_DATA()" macro or in an explicit call in a heuristic
>dissector, and in those cases the dissector would use its own protocol
>ID, which would presumably be set in the registration routine in the
>same source file.
>
>Ultimately, I'd like to get rid of as many calls to
>"CHECK_DISPLAY_AS_DATA()" and "proto_is_protocol_enabled()" as possible,
>and have the code that calls dissectors through dissector tables and
>dissector handles do the checks instead (that being one place where
>tying protocols and dissectors together would help).
>
>Where are you using "proto_is_protocol_enabled()" in one dissector where
>it needs to check whether some *other* protocol is enabled?
I'm working on the SCTP/M3UA interaction. If the SCTP dissector does not
know the upper layer protocol it dissects the payload inside a data_chunk
inside the sctp packet. If there is an M3UA payload the M3UA packet (=
payload)
is dissected on the top level in the lower pane. That's how it should be. But
if the user selects to 'dissect M3UA as data' it is currently then dissected
at the root level da data. I would prefer the same behaviour in this case as
in the case where the upper layer protocol is unknown.
So I when dissecting the payload, I would like to get the protocol dissector
for the uppler layer based on the SCTP port number, check if it should be
dissected and then call the dissector or dissect it as data.
Best regards
Michael
--
e-mail: Michael.Tuexen@xxxxxxxxxxxxxxxxx