On Monday 17 January 2005 03:01 pm, Guy Harris wrote:
> Jon Ringle wrote:
> > I took a look at the capture, and it seems to me that the problem is that
> > ethereal can't handle having multiple conversations across time that
> > happen to use the same src/dest tuple.
> >
> > I am quite new to the ethereal source code, so my understanding of it is
> > a bit limited right now, but it looks like this might be resolved
> > globally by changing the conversation_t structure to include the frame
> > number of the packet that created a conversation.
>
> The "circuits" mechanism already supports this.
Where can I find the "circuits" mechanism to study?
>
> I worked on an implementation of that for conversations; the main
> problem was making sure it handled all the different types of wildcards.
> I can go back and look at that.
>
> For TCP, there's a need for a mechanism to have more than one
> conversation dissector for a connection (e.g., for switching to TLS in
> an SMTP connection); I'm not sure the right answer there is to have
> multiple conversations for a connection. A mechanism to allow multiple
> conversation dissectors, with frame numbers indicating when to use which
> one, might be the right answer for that problem.
>
> However, in the capture in question, I think one could argue that there
> are two conversations, so that mechanism probably wouldn't be the one
> that should be used.
I can see your point for TCP connections. But UDP is connection-less so has no
bounds of relation from one packet to the next. This is up to the
application. So, it seems to me that for connection-less conversations a
frame number based approach seems appropriate here using information from
other packets to change the conversation dissector based on frame number.
Jon
