Wireshark · Wireshark-dev: Re: [Wireshark-dev] use of FT_PROTOCOL

[Hadriel Kaplan <the.real.hadriel@xxxxxxxxx>]

On Tue, Aug 25, 2015 at 11:55 PM, Cody Doucette <doucette@xxxxxx> wrote:
>> I *think* (though I could easily be wrong), that the purpose of
>> declaring a field of type FT_PROTOCOL is for cases where one
>> protocol's dissector is about to invoke another protocol's dissector
>> for encapsulated data, and wants to show that encapsulated data of the
>> other protocol as a field (of bytes) within itself in the tree - if
>> the other (inner) protocol will add itself to the top level of the
>> tree.
>
> That could well be the case, although that would seem to me to go against
> what the docs say about FT_PROTOCOL, which is just that it is: "Used for
> protocols which will be placing themselves as top-level items in the
> "Packet Details" pane of the UI." I don't know -- I haven't experimented
> with
> what you're saying.

Actually that says the same thing, so perhaps I didn't explain well enough. :)

Let me try again:
Assume there are protocols Foo and Bar. Foo carries some payload,
which can be Bar protocol. The Bar protocol's dissector will add
itself to the top of the tree (the tree in the Packet Details pane).
So if Foo simply invokes Bar's dissector with the root tree item, the
packet details will show Bar at the top level of the tree. To help
users figure out the relationship, Foo creates a FT_PROTOCOL field - a
field belonging to Foo, but which represents the Bar protocol being
carried in Foo. So Foo adds this FT_PROTOCOL field to its subtree, and
then invokes Bar's dissector.


>> This also lets one filter for "foo.bar" so only packets with Bar being
>> in Foo would match, instead of filtering for "bar" where any packet
>> with Bar would match.  Whereas if Foo simply invoked Bar's dissector,
>> even with passing it a sub-tree to force Bar to display inside of Foo,
>> it would have no such filtering ability afaik.
>
> Your explanation here led me to the realization that it's not fair to ask
> for
> what I wanted -- for a protocol Bar to be displayed at the top level if it's
> written
> inside Foo, since users would need to know to filter on "foo.bar" instead of
> just "bar" when it's not displayed that way.

No, I meant they can filter for "foo.bar" to only get packets where
Bar is inside of Foo; but they can also filter for "bar" and get all
packets that have a Bar in the packet. They can filter for "bar" no
matter what, in both cases, wether you add a FT_PROTOCOL field in Foo
or not.

The display filters have nothing to do with the organizational
hierarchy of the tree view in the Packet Details pane. You can put
everything at the top level, or everything in a parent-child
relationship, and the filters would match the same regardless. They
match purely on field information - even fields not displayed in the
Packet Details view tree.

As for deciding whether Bar should be displayed at the top level of
the tree or not - there's no hard+fast rule for which way to do it as
far as I can tell. A lot of the SS7-related protocols and
sub-protocols, for example, display each of themselves at the top
level; and they use FT_PROTOCOL fields to provide the relationship.

-hadriel