From: Guy Harris [mailto:gharris@xxxxxxxxxxxx]
Sent: Monday, January 08, 2001 10:27 PM
> On Mon, Jan 08, 2001 at 12:48:56PM -0600, Jeff Foster wrote:
> > The bigger problem, how to keep this cross-talk between
> > conversational dissectors from happening? I'm suggesting
> > that all conversation dissectors set the dissector with
> > the conversation_set_dissector call.
>
> By "conversation dissector" do you mean "dissector that creates a
> conversation", so that it'd make itself the dissector for all subsequent
> packets in the conversation, even if the other port happens to be
> assigned to another protocol that Ethereal dissects?
Yes.
>
> If so, that sounds reasonable, although doing so only if the dissector
> in question creates a conversation may not be sufficient to avoid
> problems - if you had a TCP conversation between ports X and Y, and both
> ports X and Y are well-known or registered ports for protocols for which
> Ethereal has a dissector, you could end up with the same sort of
> ping-ponging, albeit with that particular problem with state
> information.
>
I agree with the ping-pong issue, the bigger concern is invalid memory
access because a conversation based dissector is using data from another
dissector. This is what caused the original problem with the socks
dissector.
>
> (Ultimately, we will probably want a conversation structure for *every*
> TCP connection, for the benefit of TCP byte stream reassembly, and when
> we do that we might as well use it for "Follow TCP Stream" as well.)
Agreed. Now we need consider how to impliment this. Should the TCP
conversation be an addition outside the current system, leaving it intact,
or a revamp with the find_conversation and conversation_new modified to
emulate the current behavior. I like the second method best, but don't
have the issues or implimentation worked out.
Need more beer and sleep for the brain to process new data ;-)
Jeff Foster
jfoste@xxxxxxxxxxxx
