Biot Olivier said:
> In order to fix this and other possible issues, maybe we have to define a
> *real* private_data *structure* containing the information about the
> protocol (such as the protocol dissector handle?) to which it belongs
What would the DCE RPC dissector do with that handle? A more usable
"cookie" might be the value returned by "proto_register_protocol()"; a
subdissector could look up a protocol by name and compare the value it
finds with the value supplied.
However, that's not necessarily the only fix.
The problem is that the contract for some dissectors is that they will
pass a private structure to subdissectors, with data for the calling
protocol, and the contract for some other dissectors is that they will be
passed a private structure, with data appropriate to the called protocol.
If the calling and called dissector differ on the terms of the contract,
there's a problem....
There are multiple DCE RPC dissectors, and they all expect to be handed a
"dcerpc_private_info" structure. Unfortunately, no dissectors that call
the DCE RPC dissector, other than the SMB pipe dissector, do so; some pass
nothing (as that's not in their contract), and the TCP dissector passes a
TCP info structure (as that's in its contract).
Currently, the DCE RPC dissector identifies DCE RPC conversations using
transport-layer conversations (as supported by the conversation code) and
an SMB FID - the FID is relevant only when the RPCs are going over an SMB
named pipe.
I don't know whether there are any other DCE RPC transports we care about
that support multiple DCE RPC conversations over a single transport-layer
conversation. If not, we could have a special DCE RPC dissector for use
on SMB named pipes, which gets handed a "dcerpc_private_info" structure,
and have the others *not* expect to be handed a particular structure;
those would call a common dissector which would take the SMB FID as an
argument.
