Re: Protocols vs dissectors, take 23

[Michael Mann <mmann78 () netscape net>]

Using a protocol ID of -1 seems like an interesting solution.  I was a little worried about making sure all of the 
"NULL checks" that could result from that would be covered.  I think it would be easy enough to add to the "internals" 
of packet.c/proto.c, but a little harder to make sure you don't have dissectors requesting protocol names from the 
handle. I think there are other situations where -1 could work, I just don't have a use case right now.

The reason I wouldn't use a protocol ID of -1 specifically for the TLVs of IP/TCP/PPP is that in creating the TLV tree 
(for TCP at least, others have yet to be done) I was using the protocol name from the handle retrieved from the 
dissector table.  And while you could use a value_string, that wouldn't allow third-party dissectors to be included 
within it (which was one of the driving factors for converting it into a dissector table in the first place).  Again 
for this situation I think "Decode As" is a "nice to have" (so I didn't want to prohibit it), but I would agree that 
the other "extras" probably aren't necessary.
 
 
-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Thu, Jan 5, 2017 8:23 pm
Subject: Re: [Wireshark-dev] Protocols vs dissectors, take 23

On Jan 1, 2017, at 6:13 PM, Michael Mann <mmann78 () netscape net> wrote:

> I really like the flexibility and power that the current dissector table API provides.  The one small shortcoming is 
> that a "protocol" needs to be provided when adding a dissection function to a dissector table.  And not all 
> dissection functions are a protocol.  The "protocol" API is intentionally separate from the dissector function API 
> because there isn't always a 1-1 relationship. This can lead to the creation of "dummy" protocols, or "pinos" 
> (Protocols in name only) as I've decided to call them (modeled after [1]).  To me, pinos don't have the same 
> capabilities as real protocols.  They don't have hf_ fields or heuristic dissection functions associated with them.  
> They cannot be enabled/disabled.  They are there strictly to satisfy the dissector table API and Decode As 
> functionality by extension (names for dissection functions).

So why can't you just have dissector handles with -1 as the protocol ID?  That means that you can't disable or enable 
it, but do we really *need* to be able to disable the dissector for some arbitrary IP or TCP or PPP option, for 
example?  It also means that they can't participate in "Decode As", but I'm not sure there's a need for that, either.

The one reason I see for using dissector tables for TLVish things such as IP/TCP/PPP etc. options, attributes, etc., 
etc., etc. is to allow other dissectors, including third-party dissectors, to register dissection code for particular 
type codes.  I'm not sure they need all the extra protocol-oriented enable/disable/decode as mechanisms.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.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://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe