Wireshark-bugs: [Wireshark-bugs] [Bug 4943] ISMP.EDP "Tuples" dissected incorrectly: revert SVN
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4943
--- Comment #5 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2011-01-10 14:12:09 PST ---
(In reply to comment #4)
> Question is does the L in TLV include the length of the TL part or not?
> Can't find a spec on this protocol this quickly, so I don't know which is
> correct.
According to http://www.ethereal.com/lists/ethereal-dev/200312/msg00703.html,
the "Enterasys Discovery Protocol" was formerly the "Cabletron Discovery
Protocol".
RFC 2643 (http://www.faqs.org/rfcs/rfc2641.html), entitled "Cabletron's
SecureFast VLAN Operational Model", while not the "Cabletron Discovery
Protocol" itself, describes the Cabletron TLV in section 2.3, whereby the L is
indicated as the length of the value field only and does not include the bytes
for T or L.
Other Cabletron RFC's that reference RFC 2643:
RFC 2641: "Cabletron's VlanHello Protocol Specification"
RFC 2642: "Cabletron's VLS Protocol Specification"
Also, RFC 2124, "Cabletron's Light-weight Flow Admission Protocol
Specification", doesn't reference RFC 2643 (for obvious reasons), but section
3.1 describes the IE (Information Element) format exactly the same as the RFC
2643 TLV format.
Considering the original author's implementation, the fact that the attached
packet sample packet capture from Bill decodes correctly and information from
these RFC's, I'd say it's a pretty safe bet that the current implementation is
correct and this bug can be closed.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
