Re: Failing to get my tree to show

[Kaul <mykaul () gmail com>]

On Sat, Jan 16, 2010 at 4:30 AM, Guy Harris <guy () alum mit edu> wrote:

> 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?

Nope.


> > 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.

Indeed. I cannot use either of the above mentioned methods.


> > 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.

Even if I'm not setting right away (others do it as well - I've taken it
from packet-vnc.c), then it's even worse - all I see is the TCP.


> 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?

Exactly. It's not that it's not dissected - all the right functions are
called. But with tree = null, not much is seen.
I can see that TCP correctly shows the 3 segments in packet 6 (that it
reassembled from packets 4,5,6).



> > 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).

> From README.developer:
"Wireshark distinguishes between the 2 modes with the proto_tree pointer"


> 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.

Again, I think my main issue is that my main dissector function is already
called with a null tree. That makes everything afterwards pretty much fail
to display.
I did notice it doesn't happen without the desegmentation stuff - so I'm
pretty sure it's related to that. Just have no idea why.
Would posting the complete code help?
TIA,
Y.

___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe