asn1c: Failed to parse S1AP and RANAP asn.1

Hi @acetcom,

I just pushed 3 commits in my fork - two APER fixes (fec0acc058491b60eb00cd223de246b168b69f92, f5dc5cc6358a153cd0e0da503563c595d2a2edd4) and one XER (8d06d92df6dca1b9a6dcb0aedef0f91e053823d0)

$ file ./s1ap-dump 
./s1ap-dump: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=58db588dc25d71cb014f8c63f3f4577123e710fb, with debug_info, not stripped
$ ./s1ap-dump -t
000b4080 8c000003 00000002 00010008 00020001 001a0079 78efefef efefefef 
efefefef efefefef efefefef efefefef efefefef efefefef efefefef efefefef 
efefefef efefefef efefefef efefefef efefefef efefefef efefefef efefefef 
efefefef efefefef efefefef efefefef efefefef efefefef efefefef efefefef 
efefefef efefefef efefefef efefefef ef

The problems were also reproducible with make check as I’ve already added the PDUs you provided in my fork.

@mouse07410 and @velichkov

Sorry for late response!

Today(26/March), I’ve tested asn1c library with NextEPC test framework.

git checkout https://github.com/mouse07410/asn1c
git checkout vlm_master

git checkout https://github.com/velichkov/asn1c
git checkout s1ap

In 32bit machine, both are correctly worked for NextEPC. No Problem!

Thanks a lot!

Hi @brchiu,

please advice how I incorporate your commit into #226

I’m OK to incorporate this into your PR, an easy way to do it is to cherry-pick from my repository

git remote add velichkov https://github.com/velichkov/asn1c.git
git fetch velichkov
git checkout merge_mouse07410_aper_implementation
git cherry-pick 3f5ef6d
git push

@mouse07410,

@velichkov May I ask to make it a separate PR for after #226 is merged?

Ok. If @brchiu decides to not cherry-pick this change I will open a new PR once #226 gets merged.

And/or could you make it a PR against the vlm_master branch in my fork?

I will. In the future feel free to check-pick changes directly from my repo as described above.

Dear @brchiu , With regard to the problem in compiling “Information Object Set”, the problem seems solved and S1AP, RANAP, X2AP, M3AP, LPPa, PCAP, XwAP are successfully compiled, as you mentioned, after commit 3bbbd04 by @vlm . However, when compiling the GSM_MAP protocol, that issue still rises.

asn1c -fcompound-names -gen-PER GSMMAP.asn MAP-MS-DataTypes.asn MAP-SS-DataTypes.asn MAP-CommonDataTypes.asn MAP-ExtensionDataTypes.asn MAP-SS-Code.asn MAP-BS-Code.asn MAP-TS-Code.asn MAP-ER-DataTypes.asn MAP-OM-DataTypes.asn MAP-CH-DataTypes.asn MAP-DialogueInformation.asn MAP-SM-DataTypes.asn

Do you have any clue that how this can be resolved? Maybe with similar approach which addressed the problem for S1AP.

Thanks

hi, @acetcom, just for your information. Online tool provided by http://asn1-playground.oss.com/ also failed to decode this srsenb.aper.

Hi @acetcom,

srsenb.pcapng : Wireshark packet capture. E-RAB Setup Response captured in number 36. e_rab_set_response.png : screen shot Basically, I have no idea whether srsENB encoding is correct or not.

Most probably the srsENB encoding is not correct because wireshark does not decode it as well.

I think that id-CriticalityDiagnostics(58) seems to be related to the problem.

Yes the problem is related with this parameter. To get some more info run s1ap-dump with -dd option

Getting open type CriticalityDiagnostics encoded in 13 bytes (per_opentype.c:438)
Decoding CriticalityDiagnostics as SEQUENCE (APER) (constr_SEQUENCE.c:1509)
  [PER got  1<=104 bits => span 1 +0[1..104]:03 (103) => 0x0] (asn_bit_data.c:139)
  [PER got  5<=103 bits => span 6 +0[6..104]:03 (98) => 0x0] (asn_bit_data.c:139)
Read in presence bitmap for CriticalityDiagnostics of 5 bits (0..) (constr_SEQUENCE.c:1532)
  [PER got  1<= 5 bits => span 1 +0[1..5]:00 (4) => 0x0] (asn_bit_data.c:139)
Member CriticalityDiagnostics->procedureCode is optional, p=0 (1->5) (constr_SEQUENCE.c:1581)
  [PER got  1<= 4 bits => span 2 +0[2..5]:00 (3) => 0x0] (asn_bit_data.c:139)
Member CriticalityDiagnostics->triggeringMessage is optional, p=0 (2->5) (constr_SEQUENCE.c:1581)
  [PER got  1<= 3 bits => span 3 +0[3..5]:00 (2) => 0x0] (asn_bit_data.c:139)
Member CriticalityDiagnostics->procedureCriticality is optional, p=0 (3->5) (constr_SEQUENCE.c:1581)
  [PER got  1<= 2 bits => span 4 +0[4..5]:00 (1) => 0x0] (asn_bit_data.c:139)
Member CriticalityDiagnostics->iEsCriticalityDiagnostics is optional, p=0 (4->5) (constr_SEQUENCE.c:1581)
  [PER got  1<= 1 bits => span 5 +0[5..5]:00 (0) => 0x0] (asn_bit_data.c:139)
Member CriticalityDiagnostics->iE-Extensions is optional, p=0 (5->5) (constr_SEQUENCE.c:1581)
Too large padding 98 in open type (per_opentype.c:461)

Hi @mouse07410,

but would you mind taking a look at the fix I applied to skeletons/INTEGER.c, and comment on whether the added checks are sufficient in your opinion?

I think these checks are sufficient.

Hi, @velichkov

Great! NextEPC 32bit version is also successfully ported with this.

For your reference, I’ve only changed the following code based on your s1ap branch.

acetcom@sejin123:~/Documents/git/asn1c.velichkov/skeletons$ git diff
diff --git a/skeletons/per_support.h b/skeletons/per_support.h
index 23079c9..1378030 100644
--- a/skeletons/per_support.h
+++ b/skeletons/per_support.h
@@ -25,7 +25,11 @@ typedef struct asn_per_constraint_s {
        int  range_bits;                /* Full number of bits in the range */
        int  effective_bits;            /* Effective bits */
        long lower_bound;               /* "lb" value */
+#if 0 /* modified by acetcom */
        long upper_bound;               /* "ub" value */
+#else
+       int64_t upper_bound;            /* "ub" value */
+#endif
 } asn_per_constraint_t;
 typedef struct asn_per_constraints_s {
        asn_per_constraint_t value;

The attached pcap was created by new S1AP API. s1ap-32bit.tar.gz

And also, you can find the example code in NextEPC repository.

git clone https://github.com/acetcom/nextepc
git checkout s1ap

The new NextEPC will be released after testing real eNodeB. 1~2 week might be needed.

Thank you very much!!!

Best Regards, Sukchan

Hi @acetcom,

But, S1 Setup Request is failed.

The previous fix was definitely not correct, my second attempt is 3f5ef6d (you need to revert or drop the previous patch and apply this on top of a1537b84624a1626d6c806e6791765d837d190ef).

And if possible could you send me all messages from the testepc.pcapng extracted as a bin files.

Hi @acetcom, @brchiu,

To resolve the problem with s1reset_three_part_of_s1_interface.bin apply 25da4e3d90e827f70c31b3a4833fe31ef56401ce

When decoding a SEQUENCE OF with less then 256 the alignment bits were not read and because of this the decoded length was wrong

<S1AP-PDU>
    <initiatingMessage>
        <procedureCode>14</procedureCode>
        <criticality><reject/></criticality>
        <value>
            <Reset>
                <protocolIEs>
                    <ResetIEs>
                        <id>2</id>
                        <criticality><ignore/></criticality>
                        <value>
                            <Cause>
                                <radioNetwork><release-due-to-eutran-generated-reason/></radioNetwork>
                            </Cause>
                        </value>
                    </ResetIEs>
                    <ResetIEs>
                        <id>92</id>
                        <criticality><reject/></criticality>
                        <value>
                            <ResetType>
                                <partOfS1-Interface>
                                    <ProtocolIE-SingleContainer>
                                        <id>91</id>
                                        <criticality><reject/></criticality>
                                        <value>
                                            <UE-associatedLogicalS1-ConnectionItem>
                                                <mME-UE-S1AP-ID>100</mME-UE-S1AP-ID>
                                                <eNB-UE-S1AP-ID>4</eNB-UE-S1AP-ID>
                                            </UE-associatedLogicalS1-ConnectionItem>
                                        </value>
                                    </ProtocolIE-SingleContainer>
                                    <ProtocolIE-SingleContainer>
                                        <id>91</id>
                                        <criticality><reject/></criticality>
                                        <value>
                                            <UE-associatedLogicalS1-ConnectionItem>
                                                <mME-UE-S1AP-ID>99</mME-UE-S1AP-ID>
                                                <eNB-UE-S1AP-ID>3</eNB-UE-S1AP-ID>
                                            </UE-associatedLogicalS1-ConnectionItem>
                                        </value>
                                    </ProtocolIE-SingleContainer>
                                    <ProtocolIE-SingleContainer>
                                        <id>91</id>
                                        <criticality><reject/></criticality>
                                        <value>
                                            <UE-associatedLogicalS1-ConnectionItem>
                                                <mME-UE-S1AP-ID>44</mME-UE-S1AP-ID>
                                            </UE-associatedLogicalS1-ConnectionItem>
                                        </value>
                                    </ProtocolIE-SingleContainer>
                                </partOfS1-Interface>
                            </ResetType>
                        </value>
                    </ResetIEs>
                </protocolIEs>
            </Reset>
        </value>
    </initiatingMessage>
</S1AP-PDU>

Hi @brchiu,

Part of IOC generation problems is solved in my local branch.

You have made a great progress!

However, due to complex relation between so many generated types, there is cyclic inclusion of header file occurs and some generated C files from S1AP ASN.1 fail to be compiled. I think it might need a overhaul of file structure to solve this problem. For example, break up ProtocolIE-Field.h to small ones, … etc.

An alternative solution according to the documentation could be

   -findirect-choice
      When  generating code for a CHOICE type, compile the CHOICE mem-
      bers as indirect pointers instead of declaring them inline. Con-
      sider  using this option together with -fno-include-deps to pre-
      vent circular references.

I just tried with both options and the cyclic inclusion is removed at least for S1AP but the compilation fails with

cc -DASN_DISABLE_OER_SUPPORT  -DPDU=S1AP_PDU -DASN_EMIT_DEBUG=1 -I. -g3 -O0 -o ProtocolIE-Field.o -c ProtocolIE-Field.c
ProtocolIE-Field.c:15995:1: error: redefinition of ‘memb_id_constraint_0’
 memb_id_constraint_0(const asn_TYPE_descriptor_t *td, const void *sptr,
 ^~~~~~~~~~~~~~~~~~~~
ProtocolIE-Field.c:15977:1: note: previous definition of ‘memb_id_constraint_0’ was here
 memb_id_constraint_0(const asn_TYPE_descriptor_t *td, const void *sptr,
 ^~~~~~~~~~~~~~~~~~~~
ProtocolIE-Field.c:16001:1: error: redefinition of ‘memb_criticality_constraint_0’
 memb_criticality_constraint_0(const asn_TYPE_descriptor_t *td, const void *sptr,
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ProtocolIE-Field.c:15983:1: note: previous definition of ‘memb_criticality_constraint_0’ was here
 memb_criticality_constraint_0(const asn_TYPE_descriptor_t *td, const void *sptr,

Part of problems during parsing S1AP’s ASN.1 was fixed in fix_s1ap branch of my fork.

But there still be unsolved ones. It looks like current asn1c can not handle following ASN.1. A minimum excerpt is in this gist.

PROTOCOL-IES ::= CLASS {
	&id		ProtocolIE-ID	UNIQUE,
	&criticality	Criticality,
	&Value,
	&presence	Presence
}
WITH SYNTAX {
	ID				&id
	CRITICALITY		&criticality
	TYPE			&Value
	PRESENCE		&presence
}

ProtocolIE-Container {PROTOCOL-IES : IEsSetParam} ::= 
	SEQUENCE (SIZE (0..number1)) OF
	ProtocolIE-Field {{IEsSetParam}}

ProtocolIE-SingleContainer {PROTOCOL-IES : IEsSetParam} ::= 
	ProtocolIE-Field {{IEsSetParam}}

ProtocolIE-Field {PROTOCOL-IES : IEsSetParam} ::= SEQUENCE {
	id		PROTOCOL-IES.&id		({IEsSetParam}),
	criticality	PROTOCOL-IES.&criticality	({IEsSetParam}{@id}),
	value		PROTOCOL-IES.&Value		({IEsSetParam}{@id})
}

By the way, though S1AP and RANAP can be parsed and generate corresponding C code for S1AP and RANAP with commit 94f0b64, due to APER not support in this repository, S1AP and RANAP message can not be encoded or decoded yet.

We still need to merge APER implementation, for example #125 or #115, in the future.