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
