My work on the socks and MSProxy dissectors has lead to
the spot where I need to install conversational based
dissectors. The socks proxy isn't so bad because it doesn't
need it unless a UDP conversation is started. However the
MSProxy is in desperately need of this.
The proposal:
Add code into the conversation stuff to allow a dissector to
be installed. This would add another field to the conversation_t
structure for the dissector pointer. This field would be set to
NULL by the conversation_new routine. The dissector creating
the conversation could install a dissector by placing the address
of the routine in this field -
my_conversation->dissector = &my_conv_dissector;
The TCP and UDP routines would have to be modified to do a
conversation lookup and check for a value in the 'dissector' field.
Questions:
1) Should the conversation_t value from the lookup to find a
dissector be passed to the conversation dissector? The
conversation dissector definition would be..
void dissector( conversation_t conv, const uchar *pd, int offset,
frame_data *fd, proto_tree *tree)
I favor this, why do two lookup to find a conversation.
2) Are there any other protocols, beside TCP and UDP that need to
look for conversational dissectors?
3) Should TCP and UDP do a conversation lookup before or after the
current sub-dissector search code? Doing the lookup first will
provide the best chance to finding a conversation that happens to
use a 'well-know port', at the expense of the hash table lookup for
every packet.
If there is agreement on this, or once the dust settles, I am willing
to start the coding on it.
Jeff Foster
jfoste@xxxxxxxxxxxx
