Re: Conversation tracking

[Tobias Weiss <tweiss () ra rockwell com>]

Hi Ronnie,

Thanks for all these suggestions. I already had a similar approach but I 
did not know about the pinfo->fd.flags.visited flag, that will help a lot.

I really appreciate all your help.

Tobi





ronnie sahlberg <ronniesahlberg () gmail com> 
Sent by: wireshark-dev-bounces () wireshark org
05/11/2012 08:42 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






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

___________________________________________________________________________
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