Wireshark mailing list archives
Re: use of FT_PROTOCOL
From: Cody Doucette <doucette () bu edu>
Date: Tue, 25 Aug 2015 23:55:00 -0400
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.
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.
Since the XIP dissector isn't that big, I don't see an issue with adding the new subdissector into packet-xip.c. Sharing a header format seems like enough to justify keeping it in the same file. I'm more against "file pollution" in a very crowded directory, it has nothing to do with FT_PROTOCOL use. Also, keep in mind not all dissectors are protocols. I don't know enough about XIP to know if your "subdissector" is truly its own protocol.
Regarding whether it is its own protocol, it definitely is -- it's one of those newfangled layer 3.5 protocols. In thinking of it that way, it should definitely be its own dissector, especially since it will need to invoke layer 4 dissectors (TCP, UDP, ...) to be displayed at the top level. My original intent was to try to reduce the kind of file pollution that you are talking about, but it is now clear to me that it needs to be separate, and the code probably looks better that way anyway. I'll try it out. Thanks very much for the thoughts! Cody
___________________________________________________________________________ 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)