IBM Support

PK94987: Encoded string calculates the length of an OCTET STRING incorrectly when the OCTET STRING has constraints

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as user error.

Error description

  • = SEQUENCE {
    myIdentityInfo OCTET STRING (SIZE (1..255))
    }
    
    and a corresponding TTCN-3 template
    template XYZIdentityType xyzIdentity := {
      myIdentityInfo := '01100110'O
     }
    
    Here, though the actual length of the OCTET STRING
    'myIdentityInfo' is 4, the length bits in the corresponding
    encoded string are represented incorrectly.
    
    When the OCTET STRING is defined without constraints or with the
    constraints OCTET STRING (SIZE (0..255)), the length of the
    string is encoded correctly.
    
    
    Additional Information:
    ***************************
    Here are some of the scenarios that the customer has tested at
    his end, along with the resultant encoded strings:
    
    1. The encoded value when myIdentityInfo is OCTET STRING (SIZE
    (1..255)):
    00 01 00 45 00 00 08 00   03 00 06 00 C0 01 10 01 --- Length is
    calculated as 192 (Incorrect)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    2. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (2..255)):
    00 01 00 45 00 00 08 00   03 00 06 00 80 01 10 01 --- Length is
    calculated as 128 (Incorrect)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    3. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (3..255)):
    00 01 00 45 00 00 08 00   03 00 06 00 40 01 10 01 --- Length is
    calculated as 64 (Incorrect)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    4. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (1..254)):
    00 01 00 45 00 00 08 00   03 00 06 00 C0 01 10 01 --- Length is
    calculated as 192 (Incorrect)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    5. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (0..255)):
    00 01 00 45 00 00 08 00   03 00 06 00 04 01 10 01 --- Length is
    calculated as 4 (Correct)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    6. The encoded value when declared myIdentityInfo as OCTET
    STRING:
    00 01 00 45 00 00 08 00   03 00 06 00 04 01 10 01 --- Length is
    calculated as 4 (Correct)
    10 00 08 00 0C 40 00 88   00 80 56 76 00 06 AA AA
    
    Thus the cases where the length is encoded correctly are
    unconstrained Octet string and Octet string with constraint 0 to
    255.
    
    
    Support Investigation:
    ***************************
    The above encoded values are observed by the customer when they
    encode their ASN.1 structured type, that has one of the fields
    as a constrained OCTET STRING.
    
    To test this at the support end we created the attached sample
    test suite and got the following results:
    
    1. The encoded value when myIdentityInfo is OCTET STRING (SIZE
    (1..255)):
    03 01 10 01 10
    
    2. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (2..255)):
    02 01 10 01 10
    
    3. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (3..255)):
    01 01 10 01 10
    
    4. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (1..254)):
    03 01 10 01 10
    
    5. The encoded value when declared myIdentityInfo as OCTET
    STRING (SIZE (0..255)):
    04 01 10 01 10
    
    6. The encoded value when declared myIdentityInfo as OCTET
    STRING:
    04 01 10 01 10
    
    
    
    How to Reproduce:
    *************************
    Build and execute the attached test suite and observe the values
    of the encoded string
    

Local fix

  • No WA found
    

Problem summary

Problem conclusion

Temporary fix

Comments

  • The current Tester's behavior is correct.
    The cause of encoding difference is that when range is less
    then 256, the actual length is being encoded in bit-field,
    that isn't aligned even in ALIGNED variant (X.691 10.5.7.1)!
    When range is 256 or greater, the encoded length is aligned
    in ALIGNED variant.
    So if before the OCTET STRING field in SEQUENCE we have any
    other field that is encoded in bit-field and some bits are
    not occupied before the octet boundary, in case when OCTET
    STRING is constrained and range is less then 256, the actual
    length bits will be added without alignment.
    

APAR Information

  • APAR number

    PK94987

  • Reported component name

    TLOGIC TESTER

  • Reported component ID

    5724V70TE

  • Reported release

    330

  • Status

    CLOSED USE

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2009-08-28

  • Closed date

    2010-12-07

  • Last modified date

    2010-12-07

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYQJP","label":"Rational Systems Tester"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.3","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
07 December 2010