many protocols are implemented because they are in use in the wild
regardless of their standard status.
in fact, many of the most important protocols that wireshark supports
have never and will likely never be officially documented.
this includes virtually all cifs based file sharing and service
protocols. we are surely not going to remove them just because an rfc
does not exist.
other examples can be that wireshark does exist special non-rfc
versions of kerberos that are widely deplyed such as packetcable
kerberos. this support should not be removed just because they use a
pre-1510 version of the packet formats that is not
compatible/identical to 1510 or later.
As long as the protocols exist in the wild and are useful for users it
is useful for wireshark to have them built in.
If however protocols evolve and they are not updated in wireshark it
probably means that the existing support is good enough or that not
enough interest exist to update them.
users are encouraged though to enhance dissectors and implement later
versions of the protocols.
i dont think we should remove old obsoleted versions of protocols as
long as they are used in the wild.
On 8/9/06, David Sips <DSips@xxxxxxxx> 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.
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?
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.
