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

How to change a proto_item value at dissector?

0

Hey,

I'm writing a dissector (wireshark-v1.99.9) for a custom protocol with the following structure:

pdu = instruction [& 0x20 & parameter]*

That means each pdu has excatly one instruction and an variable amount of parameters. At the details pane the protocol should be display like that:
-Instructionname
+"Parameters: %d", n
--parameter 0
--parameter 1
--...
--parameter n

The field/node parameters should contain an FT_UINT8 so the user can search for packets with certain amount of parameters (n). Therefore at the time parameters is constructed I don't know n. To work around this issue I could first dissect the pdu and determine n and afterwards dissect a second time to construct the proto_tree. But performance-wise this is not a good solution.

I would rather init parameters with 0, dissect the pdu and finalize n after I'm done. I checked epan/proto.h&.c and README.dissector for methods I could use.
proto_item_set_text(); looked promising but it broke the filter proto.paramters==n (>, < kept working).
The second discovery is static void proto_tree_set_uint(field_info *fi, guint32 value);. It suits my needs perfectly, but is not exported via proto.h.

I'm not that experienced as a programmer and a wireshark newbie, therefore my questions:

  1. Is there a way I overlooked, to accomplish the desired protocol dissection?
  2. Is there a deeper design reason behind the fact that proto_tree_set_uint(); (and similar functions) are not exported? I tried to do it myself, added following costum functions:
    proto.h
    WS_DLL_PUBLIC void my_set_uint(proto_item *pi, guint32 value);
    proto.c
    void my_set_uint(proto_item *pi, guint32 value) { proto_tree_set_uint(PITEM_FINFO(pi), value); }
    and recompiled wireshark and my plugin but it crashed right after the startup.

Thanks in advance!

asked 18 Sep '15, 04:13

Grima's gravatar image

Grima
6113
accept rate: 0%

edited 18 Sep '15, 04:27


One Answer:

0

I'm not certain I follow your protocol definition, but I think you're saying it's one of those awkward protocols that doesn't have a length or count in the "header", and then repeated "parameter" records.

If that's the case, then I would add the instruction field, keeping the return value (a proto_item*) from proto_tree_add_item(), creating a sub-tree off it with proto-item_add_subtree(), iterate over the parameter records accumulating the count, then at the end add the count value to the sub-tree of the instruction field using the accumulated value. To finish off, call the PROTO_ITEM_SET_GENERATED() macro on the count field to show that it's been generated and doesn't exist in the packet.

answered 18 Sep '15, 05:19

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%