[Tobias Weiss <tweiss@xxxxxxxxxxxxxxx>]

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@xxxxxxxxx>
Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx

05/11/2012 08:42 PM

Please respond to
Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

To	Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
cc
Subject	Re: [Wireshark-dev] Conversation tracking

Tobias,
below

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

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@xxxxxxxxxxxxxxxxxx>
> Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx
>
> 05/11/2012 11:33 AM
>
> Please respond to
> Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>
> To
> Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxx>
> Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx
>
> 05/10/2012 06:03 PM
> Please respond to
> Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>
>
> To
>                 Developer
support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxx>
> Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx
>
> 05/10/2012 05:59 PM
>
> Please respond to
> Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>
> To
>                 Developer
support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe