Ask Your Question

How can I use conversations in custom dissectors

asked 2020-10-09 11:58:12 +0000

Bustel gravatar image

I have a custom dissector written in C that dissects a simple client-server protocol. The protocol though has one quirk: If an operation is successful it sets ACK flag, if not the ACK bit is not set. However if the bit is not set it looks exactly like a packet a client might send to a server. My idea was to use conversations to track if a packet is a response to a query.

From reading the README.dissector documentation I came up with the following:


    guint* conv_frames;
    conversation_t* conv = find_conversation_pinfo(pinfo,0);

    if (conv == NULL){
        conversation_new(pinfo->num, &pinfo->src, 
                                      pinfo->srcport, pinfo->destport, 0);
    conv_frames = (guint*) conversation_get_proto_data(conv, proto_rnvs);
    if (conv_frames == NULL){
        conv_frames = (guint*) wmem_alloc(wmem_file_scope(), sizeof(guint));
        *conv_frames = 0;
        conversation_add_proto_data(conv, proto_rnvs, conv_frames);

    *conv_frames = *conv_frames + 1;


    if (*conv_frames % 2 == 0) {
        proto_item_append_text(ti, ", %s", val_to_str(flags, server_response, "Unknown (0x%02x)"));
        col_add_fstr(pinfo->cinfo, COL_INFO, "%s", val_to_str(flags, server_response, "Unknown (0x%02x)"));
        conversation_delete_proto_data(conv, proto_rnvs);
    } else {
        proto_item_append_text(ti, ", %s", val_to_str(flags, client_ops, "Unknown (0x%02x)"));
        col_add_fstr(pinfo->cinfo, COL_INFO, "%s", val_to_str(flags, client_ops, "Unknown (0x%02x)"));


This seems to work when I run it in Tshark but in Wireshark as soon as I enter a filter it fails and misinterprets the packets. I suspect that this code only works on the first dissection run and then has some 'leftover' state. But i dont understand the conversation feature enough to tell what I am missing here. Can anobody help me out here?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-10-09 12:24:34 +0000

Jaap gravatar image
*conv_frames = *conv_frames + 1;

This won't work because of the following.

A dissector needs to be able to dissect any tvb it gets, whereby the only guarantee is that when PINFO_FD_VISITED(pinfo) is FALSE the packets are fead to the dissectors in sequence. Any other time they might be coming in any random order, e.g., when clicking on a packet in the packet list to look at the packet details.

This is what you experience when using tshark, by default it runs once through the packets, sequentially. Try tshark -2 and see what happens then.

edit flag offensive delete link more


I understand. How can I then use previous state of the connection properly? Do I have at least the guarantee that all packets are at least dissected ONCE in sequence? Then I could check for PINFO_FD_VISITED(pinfo) and only then increase my counter (or something like that).

Bustel gravatar imageBustel ( 2020-10-09 12:47:48 +0000 )edit

Do I have at least the guarantee that all packets are at least dissected ONCE in sequence?

Yes, but note that there is no guarantee that the "tree" argument is non-null, so all state construction should be done regardless of whether a protocol tree is being built or not.

Then I could check for PINFO_FD_VISITED(pinfo) and only then increase my counter


Guy Harris gravatar imageGuy Harris ( 2020-10-09 20:54:35 +0000 )edit

Thanks for the hints. I solved it by copying the way the gryphon plugin handles it: Using PINFO_FD_VISITED and then marking each response packet with p_add_proto_data().

Bustel gravatar imageBustel ( 2020-10-12 11:09:55 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2020-10-09 11:58:12 +0000

Seen: 28 times

Last updated: Oct 09