Failed decoding extensions in RRC

[zaheermot]

There is an issue decoding RRC messages, specifially with extension groups.

bytes: 08 21 be 48 16 01 00 03 42 2a c1 ./rrc-dump -dd -1 -p UL-DCCH-Message <msg.per (hextob of above) asn1: http://code.metager.de/source/xref/wireshark/asn1/lte-rrc/EUTRA-RRC-Definitions.asn

MeasResults ::= SEQUENCE { measId MeasId, measResultPCell SEQUENCE { rsrpResult RSRP-Range, rsrqResult RSRQ-Range }, measResultNeighCells CHOICE { measResultListEUTRA MeasResultListEUTRA, measResultListUTRA MeasResultListUTRA, measResultListGERAN MeasResultListGERAN, measResultsCDMA2000 MeasResultsCDMA2000, ... } OPTIONAL, ..., [[ measResultForECID-r9 MeasResultForECID-r9 OPTIONAL ]], [[ locationInfo-r10 LocationInfo-r10 OPTIONAL, measResultServFreqList-r10 MeasResultServFreqList-r10 OPTIONAL ]] }

l=3 (per_support.c:60) Extensions 3 present in MeasResults (constr_SEQUENCE.c:1200)

Read in extensions bitmap for MeasResults of 3 bits (c0..) (constr_SEQUENCE.c:1215)

Decoding member measResultForECID-r9 in MeasResults (nil) (constr_SEQUENCE.c:1243) Getting open type MeasResultForECID-r9... (per_opentype.c:78)

Getting open type MeasResultForECID-r9 encoded in 1 bytes (per_opentype.c:104) Decoding MeasResultForECID-r9 as SEQUENCE (UPER) (constr_SEQUENCE.c:1100) Decoding member "ue-RxTxTimeDiffResult-r9" in MeasResultForECID-r9 (constr_SEQUENCE.c:1170) Decoding NativeInteger INTEGER (UPER) (NativeInteger.c:268) Integer with range 12 bits (INTEGER.c:621) Freeing INTEGER as a primitive type (asn_codecs_prim.c:125) Failed decode ue-RxTxTimeDiffResult-r9 in MeasResultForECID-r9 (constr_SEQUENCE.c:1180) Failed decode measResults in MeasurementReport-r8-IEs (constr_SEQUENCE.c:1180) Failed to decode measurementReport-r8 in c1 (CHOICE) 2 (constr_CHOICE.c:907)

In the above, its incorrectly selecting the first extension (MeasResultForECID-r9) whereas measResultServFreqList-r10 is the correct selection.

wireshark RRC decoder works correctly for the same PDU

[zaheermot]

The same works with wireshark, a comparitive log suggests that the opentype encoding is working incorrectly in asn1

<field name="per.num_sequence_extensions" showname="Number of Sequence Extensions: 2" hide="yes" size="2" pos="3" show="2" value="4816"/>
                  <field name="per.extension_present_bit" showname=".... .1.. Extension Present Bit: True (extension addition group is present)" hide="yes" size="1" pos="4" show="1" value="1" unmaskedvalue="16"/>
                  <field name="per.extension_present_bit" showname=".... ..1. Extension Present Bit: True (extension addition group is present)" hide="yes" size="1" pos="4" show="1" value="1" unmaskedvalue="16"/>
                  <field name="per.extension_present_bit" showname=".... ...0 Extension Present Bit: False (extension addition group is NOT present)" hide="yes" size="1" pos="4" show="0" value="0" unmaskedvalue="16"/>
                  <field name="per.open_type_length" showname="Open Type Length: 1" hide="yes" size="1" pos="5" show="1" value="01"/>
                  <field name="per.optional_field_bit" showname="0... .... Optional Field Bit: False (measResultForECID-r9 is NOT present)" hide="yes" size="1" pos="6" show="0" value="0" unmaskedvalue="00"/>
                  <field name="per.open_type_length" showname="Open Type Length: 3" hide="yes" size="1" pos="7" show="3" value="03"/>
                  <field name="per.optional_field_bit" showname="0... .... Optional Field Bit: False (locationInfo-r10 is NOT present)" hide="yes" size="1" pos="8" show="0" value="0" unmaskedvalue="42"/>
                  <field name="per.optional_field_bit" showname=".1.. .... Optional Field Bit: True (measResultServFreqList-r10 is present)" hide="yes" size="1" pos="8" show="1" value="1" unmaskedvalue="42"/>
                  <field name="per.sequence_of_length" showname="Sequence-Of Length: 1" hide="yes" size="1" pos="8" show="1" value="42"/>

[vlm]

Extension groups are not supported for at the moment.

[zaheermot]

Thanks for the reply. i found that [[]] can be replaced with name SEQUENCE {}, is that a reliable work around?

[vlm]

For PER — yes, it is. Not so for the other encodings, such as BER/DER/XER/OER.