Wireshark-bugs: [Wireshark-bugs] [Bug 8089] New Dissector - SEL (Schweitzer Engineering Laborato

Date: Wed, 19 Dec 2012 16:59:41 +0000

Comment # 20 on bug 8089 from
(In reply to comment #19)
> I attempted to run the existing config_frame_fast code for each
> "configuration" message before, but found that the conversation structure
> was always over-writing the previously-saved config message with the current
> one.  So all I ever ended up with was a A5D3 message (as that's typically
> the last config message encountered).  I guess it's down to my lack of
> understanding of how to utilize the conversation functionality to save
> multiple config packets and be able to iterate through them later.

Oh, I think I understand the confusion now.

Conversations allow you to associate a single pointer (to an arbitrary data
structure) with a collection of packets travelling over the same connection (as
identified by address+port combination).

Although conversations by definition include multiple packets, the conversation
library does not automatically provide a pointer per
packet-in-the-conversation, as many conversations don't need to track this
amount of data (the current TCP window size, for example, is a single data
point regardless of the number of packets processed).

If you want a structure per packet in your conversation, you need the
conversation to point to a wrapper object that contains a list.

Off the top of my head, the 'standard' pattern should look something like:

/* if it's a packet we haven't seen yet */
if (!pinfo->fd->flags.visited) {

  /* find an existing conversation or create a new one as necessary */
  conversation = find_or_create_conversation();

  /* get the data for this conversation */
  data = ""

  /* if this conversation doesn't have any data yet, this is the first packet
   * in the conversation, so create a new structure for it and add it to
   * the conversation data */
  if (data == NULL) {
    data = ""
    conversation_add_proto_data();
  }

  /* now that data is guaranteed to exist, do whatever logic is necessary
   * to add the current frame to it's stored information (appending it to a
   * list or what have you) */
  update_data_for_new_packet();
}

You almost never want to conversation_add_proto_data more than once for a given
conversation.

> I am thinking that moving over to the new memory management system is beyond
> my capabilities, at least without plenty of pre-existing examples to refer
> to.  Can I put it out there that you could modify the existing selfm code to
> use the new library?  I'd be happy to verify that all the functionality
> works as before, and you get a showcase for the new library!  :)  Mind you,
> I understand if you're tied up with other things and can't take that on.

Hopefully my explanation of how conversations work will clear things up. If not
then I'll take a crack at it at some point, but it may be a while.

Cheers,
Evan


You are receiving this mail because:
  • You are watching all bug changes.