Using multiple (nested) PDU types

[SimonSchnurrbart]

Hi, I have a message which has an UPER encoded header and the body is also UPER encoded but with another structure. Right now I'm just able to decode the header into xml-format and get the body printed as Octet String. Is there a way to decode the whole message at once? Thanks in advance!

[velichkov]

Hi @SimonSchnurrbart,

Depending on the way the inner body field is defined and on the encoding (UPER in your case) it could be possible to rewrite the definition to use Information Object Class and/or Information Object Set and using the asn1c from mouse07410 or brchiu forks it will be encoded/decoded in one run. But note that this is not a trivial task to do.

As a start I recommend you to read SECTION II Chapter 6 and Chapter 7 from the ASN1 Complete book

[brchiu]

@velichkov , based on the clue that UPER is used, I guess what @SimonSchnurrbart mentioned is something like the CONTAINING constraint syntax used in ASN.1 of recent NR-RRC, e.g. the following RRCSetup-IEs has a member called masterCellGroup which contains data of CellGroupConfig type.

RRCSetup ::=                        SEQUENCE {
    rrc-TransactionIdentifier           RRC-TransactionIdentifier,
    criticalExtensions                  CHOICE {
        rrcSetup                            RRCSetup-IEs,
        criticalExtensionsFuture            SEQUENCE {}
    }
}

RRCSetup-IEs ::=                    SEQUENCE {
    radioBearerConfig                   RadioBearerConfig,
    masterCellGroup                     OCTET STRING (CONTAINING CellGroupConfig),

    lateNonCriticalExtension            OCTET STRING                                                            OPTIONAL,
    nonCriticalExtension                SEQUENCE{}                                                              OPTIONAL
}

Current asn1c, even with our patch for Information Object Set, does not decode the data inside inner structure.

0x28, 0x40, 0x01, 0xA2, 0xC2, 0x25, 0x80, 0x08, 0x8B, 0xD7, 0x63, 0x80, 0x82, 0x0F, 0x80, 0x2C, 
0x24, 0x44, 0x5E, 0xBB, 0x1C, 0x04, 0x11, 0x7C, 0x01, 0x62, 0x42, 0x22, 0xF5, 0xD8, 0xE0, 0x20, 
0x83, 0xE0, 0x02, 0x84, 0x70, 0x20, 0x27, 0xEF, 0x01, 0x34, 0x85, 0x8B, 0x88, 0xCD, 0x03, 0x60, 
0x23, 0xDA, 0x40, 0x60, 0x38, 0x13, 0x48, 0x00
<DL-CCCH-Message>
    <message>
        <c1>
            <rrcSetup>
                <rrc-TransactionIdentifier>1</rrc-TransactionIdentifier>
                <criticalExtensions>
                    <rrcSetup>
                        <radioBearerConfig>
                            <srb-ToAddModList>
                                <SRB-ToAddMod>
                                    <srb-Identity>1</srb-Identity>
                                </SRB-ToAddMod>
                            </srb-ToAddModList>
                        </radioBearerConfig>
                        <masterCellGroup>
                            58 44 B0 01 11 7A EC 70 10 41 F0 05 84 88 8B D7 
                            63 80 82 2F 80 2C 48 44 5E BB 1C 04 10 7C 00 50 
                            8E 04 04 FD E0 26 90 B1 71 19 A0 6C 04 7B 48 0C 
                            07 02 69 00
                        </masterCellGroup>
                    </rrcSetup>
                </criticalExtensions>
            </rrcSetup>
        </c1>
    </message>
</DL-CCCH-Message>

Wireshark can decode some of these kind of messages, but not all.

[velichkov]

Hi @brchiu,

based on the clue that UPER is used, I guess what @SimonSchnurrbart mentioned is something like the CONTAINING constraint syntax used in ASN.1 of recent NR-RRC, e.g. the following RRCSetup-IEs has a member called masterCellGroup which contains data of CellGroupConfig type.

I'm not familiar with this construct, I'm seeing it for the first time. Thanks for posting this clarification.

Current asn1c, even with our patch for Information Object Set, does not decode the data inside inner structure.

Yes, this is not well supported at the moment. The parser seems to support this construction but the compiler does not put any information about the inner type in the generated code. Unfortunately I don't have much time to work on this right now.

Wireshark can decode some of these kind of messages, but not all.

Could you send me some pcap files?

[mouse07410]

If support for CONTAINING could be added - it would be awesome. There are cases I'm aware of where PDUs (structures) are encoded as value of OCTET STRING, for cases, e.g., when the receiver may not have the key to decrypt the encrypted part of the message, but still is allowed to see the header and such...

[mouse07410]

@vlm ping? CONTAINING is fairly popular - it would be good to support it.

[revathigrandhi]

@brchiu, can you help me how to decode RRC messages in Wireshark as you posted an image of dissecting messages on the above comment. I was trying to dissect RRC PDUs formed by UPER encoding. it would be very helpful to me.

Thanks, Revathi

[brchiu]

@revathigrandhi , current wireshark already has capability to decode nr-rrc message. wireshark stable release 3.0.6 use ASN.1 of 38.331 V15.4.0 and experimental release 3.1.0 use 38.331 V15.6.0.

You can write a simple socket program to send your RRC message through UDP socket, then capture it using wireshark and use "Decode As" menu option to decode them.

[brchiu]

ref : 11.4. Control Protocol dissection