Wireshark mailing list archives
Re: use of FT_PROTOCOL
From: mmann78 () netscape net
Date: Fri, 21 Aug 2015 13:42:48 -0400
Another "I *think*" is that FT_PROTOCOL is more intended for hf_ items that are actually a protocol (typically a proto_xxx variable that uses the value returned from proto_register_protocol), then any "independent" fields registered through proto_register_field_array. The tree you pass into proto_tree_add_item determines where an item shows up, not its frame type (ie FT_PROTOCOL). You can have a protocol outside of the top level. 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. -----Original Message----- From: Hadriel Kaplan <the.real.hadriel () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Sent: Fri, Aug 21, 2015 11:26 am Subject: Re: [Wireshark-dev] use of FT_PROTOCOL On Thu, Aug 20, 2015 at 5:17 PM, Cody Doucette <doucette () bu edu> wrote:
I am
trying to extend the XIP dissector to include a sub-protocol that
should only
come after an XIP header. I want it displayed at the top-level
in the "Packet
Details" pane, so adding this protocol *inside* of the XIP
dissector code
seems like a good choice. I think FT_PROTOCOL will allow me
to do this.
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. In other words, say you have protocol Foo which contains protocol Bar, and Foo wants to show a field in its own tree of Bar, but Bar will add itself to the top of the tree instead, then Foo can create a FT_PROTOCOL field, call it "foo.bar", and add it to its own tree before invoking 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. Or at least that's how I think of it - but again I can easily be wrong.
But on the other hand, the
new protocol is somewhat complicated, and for
readability would probably be
better suited as its *own* dissector in a
separate file.
Yes, I think having a separate file is cleaner. Its usually easier to follow/digest when they're in separate files than one massive file. (at least for me, ymmv)
Is there a preferred way to proceed in this kind of case? All of the uses of
FT_PROTOCOL in dissectors that I can see appear to be fairly simple. I'd create a new protocol with its own dissector in a new file, and have the encapsulating one invoke the other's dissector. -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
___________________________________________________________________________ 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)