> 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
