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.
Evan
