https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4943
--- Comment #7 from Bill Meier <wmeier@xxxxxxxxxxx> 2011-01-20 16:05:13 EST ---
(In reply to comment #5)
> 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.
For the record:
Uh, actually, the (private) packet-capture attached does not decode correctly
unless SVN #30814 is reverted. That is the current Wireshark shows the frame as
"malformed". In the capture the L includes the length of the T plus the length
of the L plus the length of the V.
That being said & following up on the info Chris provided I'm guessing that
ISMP messages (and their possible payloads) are obsolete[1] and thus further
resolving this issue is not necessary or useful.
[1] For example: besides the spec Chris found for an ISMP "type 2" message I
found another spec [RFC] for what appears to be a different format message with
the same type.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.