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.
- Prev by Date: [Wireshark-bugs] [Bug 2706] CFM - Incorrect parsing of Test TLV
- Next by Date: [Wireshark-bugs] [Bug 5095] new dissector for Apache Etch
- Previous by thread: [Wireshark-bugs] [Bug 2706] CFM - Incorrect parsing of Test TLV
- Next by thread: [Wireshark-bugs] [Bug 2706] CFM - Incorrect parsing of Test TLV
- Index(es):