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
Powered by MHonArc 2.6.10