Re: Conversation tracking

[ronnie sahlberg <ronniesahlberg () gmail com>]

Tobias,
below

On Sat, May 12, 2012 at 2:25 AM, 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).

Ok so the sequence for the protocol would then be something like

TCP session setup
1 or more stage 1 PDUs
1 or more stage 2 PDUs
TCP session closure

and this applies to both directions of the TCP session?

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

In this case this would be logged as two separate conversations, so
that should not be a problem.
But packet number alone might not be sufficient anyway since as you
say the transition from stage 1 to stage 2 is never guaranteed to be
on a tcp segment boundary.


What I would suggest here is that you create a conversation,
then attach a special state structure to this conversation that
contains something like

struct stage_transition {
     int    frame ;   // packet number where stage 1 - > 2 transition occured
     int    offset;    // offset into the data of that frame where the
transition occured
}

Attach two of these structures to the conversation, one for each
direction of the tcp flow.
Create some mechanism to be able to determine "direction" to know
which one to pick.
Perhaps "high portnumber -> low portnumber == forward"  and "low port
number -> high portnumber == reverse" ?

When initially reading the capture file (pinfo->fd.flags.visited == 0)
  you build and track these structures.
When you re-filter or re-process the packet (pinfo->fd.flags.visited
!= 0) you just read from these structures.





> Tobi
>
>
>
> "RUOFF, LARS (LARS)" <lars.ruoff () alcatel-lucent com>
> Sent by: wireshark-dev-bounces () wireshark org
>
> 05/11/2012 11:33 AM
>
> Please respond to
> Developer support list for Wireshark <wireshark-dev () wireshark org>
>
> To
> Developer support list for Wireshark <wireshark-dev () wireshark org>
> cc
> Subject
> Re: [Wireshark-dev] Conversation tracking
>
>
>
>
>
> Hi Tobi,
> I don't understand your concern. (but that may be due to my weird understanding of English)
> If those packets are part of the same stream, i.e. they are being identified as belonging to the same conversation 
> (by whatever means, eg adress-port mapping etc.), then the whole point of conversation tracking is that you will get 
> the *same* conversation object for all those packets.
> So you can store things in there and retrieve them when dissecting another packet of that same conversation.
>
> Regards,
> Lars
>
>
>
> ________________________________
>
> From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Tobias Weiss
> Sent: vendredi 11 mai 2012 16:30
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Conversation tracking
>
>
>
> Right now I'm puzzled: I wanted to use conversation tracking in order to save information about the state of the 
> communication across packet dissection.
>
> The dissector is called completely out of order (which is reasonable) but I get always the same conversation, even 
> when dissecting an older packet than the last one. So saving the state of the communication is completely pointless 
> if the same conversation is used for dissecting random packets. Here is an example just in case you don't understand 
> my possibly weird English ;-)
>
> I have a stream of 10 packets and something interesting was send in packet number 3. Now I want to save this 
> information in the conversations data in order to reuse it when dissecting future packets. But the dissector is 
> called randomly (which is ok) but always with the same conversation (which is absolutely not ok in this case).
>
> I simply cannot rely on the saved information. So how am I supposed to use conversation tracking in a sane way (as 
> far as I can see I can't _track_ anything)???
>
> Tobi
>
>
>
>
> Tobias Weiss <tweiss () ra rockwell com>
> Sent by: wireshark-dev-bounces () wireshark org
>
> 05/10/2012 06:03 PM
> Please respond to
> Developer support list for Wireshark <wireshark-dev () wireshark org>
>
>
> To
>                 Developer support list for Wireshark <wireshark-dev () wireshark org>
> cc
>
> Subject
>                 Re: [Wireshark-dev] Conversation tracking
>
>
>
>
>
>
>
> Section 2.2.3 (The example conversation code using se_alloc'd memory) from the trunk.
>
> Tobi
>
>
>
>
> Stephen Fisher <steve () stephen-fisher com>
> Sent by: wireshark-dev-bounces () wireshark org
>
> 05/10/2012 05:59 PM
>
> Please respond to
> Developer support list for Wireshark <wireshark-dev () wireshark org>
>
> To
>                 Developer support list for Wireshark <wireshark-dev () wireshark org>
> cc
>
> Subject
>                 Re: [Wireshark-dev] Conversation tracking
>
>
>
>
>
>
>
>
>
> ---- On Thu, 10 May 2012 15:54:44 -0600 Tobias Weiss  wrote ----
>
> > Thanks, this is working just fine.
> >
> > But in that case I suggest an update to README.developer as I copied the buggy source-code from there.
>
> Which section(s) were you copying the source code from?
>
> ___________________________________________________________________________
> 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
> ___________________________________________________________________________
> 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
>
> ___________________________________________________________________________
> 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
>
>
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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