Re: Conversation tracking

[Tobias Weiss <tweiss () ra rockwell com>]

Hi Evan,

Sorry for wasting your time, but this never happened. I was just wondering 
if it could be the case. Thanks for having a look anyway.

Tobi





Evan Huus <eapache () gmail com> 
Sent by: wireshark-dev-bounces () wireshark org
05/11/2012 08:09 PM
Please respond to
Developer support list for Wireshark <wireshark-dev () wireshark org>


To
Developer support list for Wireshark <wireshark-dev () wireshark org>
cc

Subject
Re: [Wireshark-dev] Conversation tracking






On Fri, May 11, 2012 at 12:58 PM, Evan Huus <eapache () gmail com> wrote:
> On Fri, May 11, 2012 at 12:25 PM, Tobias Weiss <tweiss () ra rockwell com>
> wrote:
> > Thanks for your quick replies (Jeff & Lars).
> >
> > I guess I have to explain my real problem in more detail. I want to
> > implement a dissector for a quite old protocol that has 2 stages. The
> > packets of the first stage have a fixed length (4 byte) and the packets 
of
> > the second stage can have an arbitrary length but with a fixed header 
(8
> > bytes).
> >
> > Unfortunately the content of a 4 byte frame can be the beginning of the 
8
> > byte header. So I have to figure out where stage 1 ends and stage 2 
starts.
> > But as the payload of one TCP frame can contain the last stage 1 
frame(s)
> > and the first stage 2 frame, this is not straightforward. So my idea 
was to
> > do this just once with the first packet and save the state in the
> > conversation data and subsequently reuse that information. Because 
detecting
> > the end of stage 1 is pretty easy if you know where you are in the 
stream.
> > And now I'm not sure if something like this could happen within the 
same
> > conversation:
> >
> > TCP connect -> stage 1 frames -> stage 2 frames -> TCP disconnect -> 
TCP
> > connect -> stage 1 frames -> stage 2 frames
> >
> > In this case I cannot just save the packet number where stage 1 ends if 
my
> > dissector gets the same conversation for multiple connects/disconnects.
>
>
> It should return two different conversations because the setup_frame 
should
> be different (search "guint32 setup_frame" in README.developer).  
Perhaps
> this is a bug in the conversation backing? I can't check now, but I will
> take a peek tonight at some point.

A quick scan of the code and a few brief tests haven't raised any
flags. If you have a capture that reproducibly returns the wrong
conversation, file a bug and send me an email and I'll take a look.

Evan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe