Wireshark-dev: Re: [Wireshark-dev] Conversation tracking
From: Tobias Weiss <[email protected]>
Date: Mon, 14 May 2012 09:07:16 -0400

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 <[email protected]>
Sent by: [email protected]

05/11/2012 08:09 PM

Please respond to
Developer support list for Wireshark <[email protected]>

To
Developer support list for Wireshark <[email protected]>
cc
Subject
Re: [Wireshark-dev] Conversation tracking





On Fri, May 11, 2012 at 12:58 PM, Evan Huus <[email protected]> wrote:
> On Fri, May 11, 2012 at 12:25 PM, Tobias Weiss <[email protected]>
> 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 <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:[email protected]?subject=unsubscribe