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