Re: Conversation tracking

[Evan Huus <eapache () gmail com>]

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.

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