On Fri, Jan 26, 2001 at 02:48:13PM -0600, Jeff Foster wrote:
> But how does the child know the parent protocol when registering
> its self as the conversation dissector?
In the case of a dissector becoming the conversation dissector as a
result of a port match, that wouldn't be done by the child dissector,
it'd be done by "dissector_try_port()" (or "dissector_try_selector()").
Either "dissector_try_port()" would take the protocol ID as an argument,
or "register_dissector_table()" would. (Obliging dissectors to register
themselves with the conversation requires too much work from the
dissectors.)
In the case of a dissector becoming the conversation dissector on
*another* conversation (see, for example, "rtsp_create_conversation()"
in "packet-rtsp.c" for an example of this), the dissector registering
that other dissector as the conversation dissector would have to know
the protocol ID for the protocol that will be used for that future
conversation in order to create the conversation.
> The http dissector is registering it's self, it expects to be called
> by the TCP dissector. However we have a proxy involved so it is
> being call from the socks or MSProxy dissector. If the http
> dissector assume TCP, we have a problem.
This would be the first of the two cases above, so the HTTP dissector
*wouldn't* register itself.
"decode_tcp_ports()" and "decode_udp_ports()" would have to take, as an
argument, the protocol ID of the "real" protocol involved; in the TCP
dissector, it'd be passed "proto_tcp", but in the SOCKS dissector, it'd
be passed "proto_socks".
