kforums@xxxxxxxxxxxxxx wrote:
I think I'm missing something pretty basic on dissectors around reusing
subsets of a protocol vs. the need to enumerate everything in the hf[]
array.
[...]
and I'd just parse through field-by-field, however this gets incredibly
unwieldy as the number of messages and reuse of structures increases.
What I want to do:
proto_tree_add_item(hf_foo_type, ..);
switch (message)
{
case init:
proto_tree_add_item(hf_foo_init_count, ...);
foo_add_payload(...);
break;
case send:
proto_tree_add_item(hf_foo_send_index, ...);
foo_add_payload(...);
break; }
When I want to filter messages for a specific payload length, I'd want
to be able to search for foo.init.payload.length or
foo.send.payload.length -- but I'm not sure how the payload.length gets
added to the parent tree.
Well, if you want 2 different filters ("foo.init.payload.length" and
"foo.send.payload.length") then you'll need 2 hf_ entries. How you do
that is up to you; following the above code you could pass the message
type down to foo_add_payload() and switch on the message type again or
else pass in the hf_ entry(ies) to be used in add_payload, e.g.:
case send:
proto_tree_add_item(hf_foo_send_index, ...);
foo_add_payload(hf_foo_send_payload_length, ...);
That gets unwieldy too, of course.
In my experience a better approach is to leave the user in control: if
they want to filter on payload length then they use
"foo.payload.length". If they want to only filter on "send" payload
lengths then they do "foo.type==send && foo.payload.length==<whatever>".
