Wireshark-dev: Re: [Wireshark-dev] Standards supported by dissectors

From: Ulf Lamping <ulf.lamping@xxxxxx>
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
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev