This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

epan_dissect_t not being passed to stats_tree correctly

0

I've written a protocol dissector plugin for a protocol that uses CORBA for some of its communication. This protocol can send objects that can have any number of member variables and each object has a 64bit id. I have a text file with an text name and ID mapping. I'm able to correctly identify the messages in wireshark during dissection.
I'm trying to to do a stats_tree for this protocol to identify the different object types received. A tap listener has been written along with stats_tree code. When the stats_tree callback for the packet is called, the pinfo current_proto has "<missing protocol="" name="">" for its value. The epan_dissect_t has a tvb with values that I don't recognize and doesn't look like the values from my protocol.

My dissector plugin code is loosely based off of packet-coseventcomm.c. I call tap_queue_packet right after decode_CosEventComm_PushConsumer_push in the function dissect_coseventcomm. The objects I'm interested in dissected get dissected in decode_CosEventComm_PushConsumer_push so I dissect them in there and after that function I call tap_queue_packet.

Does the stats_tree packet callback get called on the packet that gets queued by tap_queue_packet? Does the callback receive the tvb data starting with the same data that gets sent to the dissector? I'm having a hard time trying to figure out what I'm doing wrong.

I register the tap listener and the stats_tree plugins with the following code

G_MODULE_EXPORT void plugin_register_tap_listener(void) {
GString *error_string;
error_string = register_tap_listener(&quot;TOMA&quot;, NULL, NULL, 0, toma_tap_packet_init,
    toma_tap_packet, NULL);

if (error_string)
{
    fprintf(stderr, &quot; %s\n&quot;,
        error_string-&gt;str);
    g_string_free(error_string, TRUE);
}

stats_tree_register_plugin(&quot;tomatcp&quot;,
    &quot;tomatcp&quot;, 
    st_str_toma,
    TL_REQUIRES_PROTO_TREE,/*  TL_REQUIRES_PROTO_TREE*/
    toma_stats_tree_packet,
    toma_stats_tree_init,
    NULL);

}

Thanks for any help with this issue.

asked 11 Sep ‘13, 16:44

tlann's gravatar image

tlann
76121419
accept rate: 100%


One Answer:

0

After doing a lot of digging in the source and refreshing of my memory it seems like I was looking at data in the wrong data structure. Although, I didn't even need to do that.
I ended up calling tap_queue_packet right after the necessary object gets dissected and just passing an ephemeral created data structure with the info I needed.

answered 17 Sep '13, 09:35

tlann's gravatar image

tlann
76121419
accept rate: 100%