Wireshark-dev: Re: [Wireshark-dev] Standards supported by dissectors
From: Ulf Lamping <[email protected]>
Date: Thu, 10 Aug 2006 11:56:41 +0200
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
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev