Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 2706] CFM - Incorrect parsing of Test TLV

Date: Fri, 15 Oct 2010 13:05:46 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2706

--- Comment #7 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-10-15 13:05:45 PDT ---
(In reply to comment #5)
> Hmmm, I think I'd disagree.  If you look at figure 9.1-2, it shows that they
> are setting up a basic TLV message with a 1-octet Tag, a 2-octet Length, and
> variable-length Value.

To me, that is not conclusive because it merely describes the "general format",
of a TLV.  I think it's unsafe to say that because a general or generic format
is described that it must be applicable to all TLV's, even though any deviation
from this format might not make any real sense.  In my experience, I've
encountered many cases where a general format or definition is given only to be
overridden by a more specific format or definition.

> 9.3.2 goes on to say what you quoted above, but to me the Value is the Value
> part of the whole TLV structure; the "pattern type" is part of the Value field
> for this particular message.  I can see the ambiguity the original author talks
> about because "containing the test pattern" could theoretically mean
> "containing only the pattern but not the 1-octet pattern type selector" but TLV
> encodings don't normally work that way.  (In other words: why make the length
> different different for this message type only?)

Yes, I think "containing" could be taken to mean, "only including, and by
implication, excluding all else", or it could be taken to mean, "including but
not limited to".  I think there's a legal definition that resolves this
ambiguity, but I don't have a copy of Black's Law dictionary handy.  :)

> The Length definition goes on to say (emphasis mine) "In a frame where the PDU
> is limited to 1492 octets, the maximum length value is 1480 octets (since 12
> bytes are required for 8 octets of LBM PDU overhead, *3* *octets* *of* *Test*
> *TLV* *overhead*, and 1 octet of end TLV)."

Either way I think there's a discrepancy here.  Either the Length field
includes the 1-byte for the "pattern type", in which case that should read,
"... the maximum length value is 1479 octets (since 12 bytes are required for 8
octets of LBM PDU overhead, 4 octets of Test TLV overhead, and 1 octet of end
TLV). ..." or the description of the Length should be clarified to read
"Identifies size, in octets, of the Value field containing the pattern type,
test pattern and CRC-32."

One additional clue that the Length does NOT include the 1 byte for the
"Pattern type" is the description of the Test pattern:

Test pattern: An n-octet (n <= length) test pattern: PRBS 2^-31 or null
(all-zeroes) pattern.

If the Length includes the 1-byte for the "Pattern type", then the description
of the "Test pattern" should have indicated, "An n-octet (n <= (length-1)) test
pattern ...".  Hmm, except even "<=" is ambiguous too I think.  It might better
be worded as , "An n-octet, where if the CRC-32 is present, n = (length - 5),
or if the CRC-32 is not present, n = (length - 1), ..."  (Here I've assumed the
1-byte "Pattern type" field IS included in the length.)

I guess we'll wait to hear what the ITU says ...

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.