Wireshark mailing list archives
Re: use of FT_PROTOCOL
From: Hadriel Kaplan <the.real.hadriel () gmail com>
Date: Wed, 26 Aug 2015 11:02:24 -0400
On Tue, Aug 25, 2015 at 11:55 PM, Cody Doucette <doucette () bu edu> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- use of FT_PROTOCOL Cody Doucette (Aug 21)
- Re: use of FT_PROTOCOL Hadriel Kaplan (Aug 21)
- Re: use of FT_PROTOCOL mmann78 (Aug 21)
- <Possible follow-ups>
- Re: use of FT_PROTOCOL Cody Doucette (Aug 26)
- Re: use of FT_PROTOCOL Hadriel Kaplan (Aug 26)
- Re: use of FT_PROTOCOL Hadriel Kaplan (Aug 21)