Hi,
Yes indeed, we try to make sure that the most important feature (the filtering) works as well as possible, which is undermined by using the add_text() API.
What you are saying is that there is no way to know how the message looks like until you’ve received it. That’s not unusual. But are you also saying that there is no definition of protocol elements for the message you receive? How does the receiving application understand the message then? By definition a protocol dissector looks at protocol elements and string them together while dissecting every detail of the message.
When you say packed, this means some sort of compression right? But after decompression you have or make a new TVB and start dissecting that. No problems there.
So, does this in anyway help? Can you find the protocol elements? The message may consist of any combination of these elements, but that does not mean that they have to be individually identified within the message. You can use the same dissection for the same type of protocol element over and over again.
Thanks,
Jaap
> On 18 Jun 2016, at 16:14, marko@xxxxxxxxx wrote:
>
> Hi.
>
> I have read Developer Manual, README.dissector and looked into few
> examples, but could not find an answer to my question.
>
> I have a dissector for a custom protocol, that is basically 4 bytes
> length, 4 bytes msg_id and rest is packed protocol buffers message.
>
> I am unpacking this protocol buffers message inside dissector and
> would like to construct nice tree structure that represents this
> message.
>
> In wireshark 1.x I could do this easily using something like
>
> proto_tree_add_text(gpbs_tree, tvb, 0, 0, "%s: %s", f->name, *(char **)m);
>
> where gpbs_tree is my subtree that represents a message.
>
> But in wireshark 2.x function proto_tree_add_text does not exists.
> There is a similar function proto_tree_add_string_format, but second
> parameter there is a hf_* field id.
>
> As far as I understand, wireshark would like me to register all
> possible fields in the beginning so I would have this hf_* for all
> possible fields.
>
> But is very very difficult, because my protocol buffers message can be
> anything at all. Different values, array, submessages, etc...
>
> What should I do in that case?
>
> How do I construct nice tree without knowing what my field types are
> before I receive network packet?
>
> Thanks!
>
> Marko.