Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Failing to get my tree to show

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 15 Jan 2010 18:30:55 -0800
On Jan 15, 2010, at 1:50 PM, Kaul wrote:

> Hi,
> 
> I'm trying to write a new dissector, and failing miserably getting my tree to show, because the tree I'm getting in my dissect_PROTONAME() is always NULL, not sure why.

Null even if you click on the packet?

> I'm dissecting over TCP, with (regretfully) my own desegmentation:

By "my own desegmentation" I assume you mean "my own code to get the TCP dissector to reassemble stuff, rather than using tcp_dissect_pdus() or req_resp_hdrs_do_reassembly()", given that you refer to setting pinfo->desegment_len.

> packets 1-3 are syn, syn-ack, ack.
> packet 4 is a start of a PDU, which is not enough to dissect the PDU, although I'm a getting its header. From the header, I'm taking the complete PDU length and therefore setting pinfo->desegment_len to calculated PDU length - length of what I got already ( with the offset = 0).
> This looks nice and correct and indeed seems to be desegmented correctly, BUT:
> packet 4 has my COL_PROTOCOL set (why?, I didn't dissect it eventually)

You're setting COL_PROTOCOL before you're doing

>                 if (len < pdu_len && redc_desegment) { /* Did not get all the PDU - request the full length of the PDU */
>                     pinfo->desegment_offset = 0;
>                     pinfo->desegment_len = pdu_len - len;
>                     return len;
>                  }

so you did enough dissection to set the column.

The BGP dissector works the same way; one could argue that it shouldn't.

> packet 5 doesn't (correct, I've asked for more than it has - it just a TCP segment)
> packet 6 has my COL_PROTOCOL set (good) - but the packet isn't dissected there, although now I have the complete data (and TCP desgmentation shows the data is indeed taken from packets 4, 5 ,6 correctly.

OK, presumably you know it has COL_PROTOCOL set because row 6 of the packet list has "Spice" in the Protocol column; do you know that it's not dissected because, when you click on that row, you don't see a protocol tree for your protocol?

> I do know wireshark has two modes, one of which it goes over packets without the tree set, but I don't get when and where.

I wouldn't describe them as "modes"; it's more like "Wireshark generates a protocol tree if it knows it will need one, and in some cases, perhaps, where it doesn't, but doesn't really know that it doesn't".  There are no "modes" such that a guarantee is made that, in certain cases, you will be handed a tree and, in other cases, you won't, only that if the tree is going to be displayed or printed you will be handed a tree (if not, that's obviously a bug).

There's also a bit of a hack that attempts to prevent the entire protocol tree from being generated when it's *not* going to be displayed or printed and where some fields *aren't* needed, and some dissectors that, for example, use proto_item_append_string() have to work around - see change r31460, for example.