[mmann78@xxxxxxxxxxxx]

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@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
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@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
___________________________________________________________________________
Sent
via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:   
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
            
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe