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