[Tobias Weiss <tweiss@xxxxxxxxxxxxxxx>]

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@xxxxxxxxx>
Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx

05/11/2012 08:09 PM

Please respond to
Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

To	Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
cc
Subject	Re: [Wireshark-dev] Conversation tracking

On Fri, May 11, 2012 at 12:58 PM, Evan Huus <eapache@xxxxxxxxx>
wrote:
> On Fri, May 11, 2012 at 12:25 PM, Tobias Weiss <tweiss@xxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe