[Ulf Lamping <ulf.lamping@xxxxxx>]

David Sips wrote:
> Hello all,
>
> I am new to development w.r.t. Wireshark though I have been a user for 
> years. The question is, what are the rules/guidelines regarding 
> protocol support from a standards perspective? Must a protocol meet a 
> certain threshold before it can be included as part of �official� 
> Wireshark? I browsed the documentation, Wiki and mailing list archive 
> a bit and could find no good guidance on when a protocol should be 
> included in the distribution and what the rules are for protocol that 
> becomes obsolete.
There's no "official" way to handle this. Usually a protocol only
becomes obsolete, if a dissector handles preliminary drafts of a
standard, which are not used "in the wild". E.g. I've implemented some
PROFINET dissectors of a preliminary standard which had slight changes
in the released version (mostly alignment things) which I've changed
then. So this is usually only a problem while a protocol is still a
"work in progress".
> A little color and an example. I am working on a toolset that builds 
> on top of a neat little tool called Scapy 
> (http://www.secdev.org/projects/scapy/). As part of that toolset, I am 
> developing additional classes to extend Scapy for select protocols. 
> Naturally, after I construct my packets I want to inspect them on the 
> wire and Wireshark provides that capability. While extending Scapy, I 
> investigate a particular protocol and write my packet class based on 
> the latest definition of a said protocol. I have discovered that 
> sometimes Ethereal, er, I mean Wireshark, cannot decode or incorrectly 
> decodes a particular protocol. For those it cannot decode I have found 
> enough info so as to be able to write a new dissector. For those that 
> are not correct, I have been able to identify flaws in both my Scapy 
> packet classes and/or particular dissectors.
>
> As an example, the IGMP dissector (packet-igmp.c) has a few associated 
> dissectors (MRDisc, MSNIP, IGAP). The dissector for Multicast 
> Discovery protocol is based on draft 6 
> (draft-ietf-idmr-igmp-mrdisc-06.txt) of a proposal while the protocol 
> has advanced to RFC status (RFC 4286). I would like to update the MRD 
> dissector and submit it back but what should I do with the old (and 
> now obsolete) frame definitions? I think removal is appropriate but I 
> would appreciate guidance on the subject. Also, what about those 
> drafts that just die (MSNIP and IGAP). I think it is appropriate to 
> remove those. What does the community think? Should there be a set of 
> guidelines to define the lifetime of a dissector?
Usually we don't remove "obsolete" dissectors as someone still might
work with the old packets for whatever reasons. Every protocol I know of
has a marker to indicate the protocol version (or similar mechanism) so
it doesn't hurt to keep the "old" code in parallel to the new.
> My apologies if this has been addressed previously.
>
> David Sips
> LVL7 Systems, Inc.
> Software Engineer
>
> The information contained in this e-mail is LVL7 confidential. Any use 
> except that authorized by LVL7 is prohibited. If you get this in 
> error, please notify the sender and delete this e-mail.
If you have read this message, destroy yourself ...
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>