On Thu, Aug 20, 2015 at 5:17 PM, Cody Doucette <doucette@xxxxxx> 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
