- 12 Apr, 2018 1 commit
-
-
Bi-Ruei, Chiu authored
Mimic what OAI's asnfix.c of generate_asn1 script does.
-
- 21 Mar, 2018 6 commits
-
-
Vasil Velichkov authored
asn1c_save.c:238:5: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation] for(int i = 0; i < argc; i++) ^~~ asn1c_save.c:240:2: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’ safe_fprintf(mkf, "\n\n"); ^~~~~~~~~~~~
-
Vasil Velichkov authored
../skeletons/INTEGER.c:510:60: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if(specs && specs->field_unsigned && dec_value <= ULONG_MAX) {
-
Vasil Velichkov authored
This fixes the following undefined behaviour converter-example.c:721:13: runtime error: null pointer passed as argument 2, which is declared to never be null /usr/include/string.h:44:28: note: nonnull attribute specified here
-
Vasil Velichkov authored
Previously some uper_* function were called
-
Vasil Velichkov authored
When there were no any padding bits the uper and aper decoders where trying to read some which results in read past the buffer end. See https://github.com/mouse07410/asn1c/issues/33#issuecomment-374625610 ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000315 at pc 0x000102ce9c15 bp 0x7fff5d20a8d0 sp 0x7fff5d20a8c8 READ of size 1 at 0x602000000315 thread T0 #0 0x102ce9c14 in asn_get_few_bits asn_bit_data.c:132 #1 0x102d878fd in aper_open_type_get_simple per_opentype.c:455 #2 0x102d85dcc in aper_open_type_get per_opentype.c:514
-
Mouse authored
-
- 14 Mar, 2018 3 commits
-
-
Vasil Velichkov authored
-
Vasil Velichkov authored
On i686 the long is 4 bytes and when converted to uint64_t some big unsigned values get converted to very big negative values See https://github.com/vlm/asn1c/issues/185#issuecomment-372546490
-
Vasil Velichkov authored
On i686 the long is 4 bytes and the right shift with more then 32 bits is probably an undefined behaviour See https://github.com/vlm/asn1c/issues/185#issuecomment-372546490
-
- 09 Mar, 2018 2 commits
-
-
Vasil Velichkov authored
-
Vasil Velichkov authored
Instead in two bytes the ENB-UE-S1AP-ID was encoded in three For value 2 the correct encoding is `02 00 02 00` and not `03 00 02 00 00` And the MME-UE-S1AP-ID were encoded in 5 instead of 4
-
- 08 Mar, 2018 5 commits
-
-
Vasil Velichkov authored
Files are from #185 and were renamed to match the Makefile's glob pattern bin/1.bin -> nextepc/sample-S1AP-PDU-1.aper Thanks to @acetcom
-
Vasil Velichkov authored
Previously when decoding fails the memory was reset with memset after casting the specifics to asn_CHOICE_specifics_t in order to get the size The problem is that the OPEN TYPE could contains a different type not derived from asn_CHOICE that does not have a struct_size member with a valid size. This fixes test failures in examples/sample.source.S1AP
-
Vasil Velichkov authored
This makes debugging and testing a lot more easier as skeleton files are not copied and you don't need to execute `make regen` after every change in the skeleton files. You need to manually remove all skeleton files and run `make regen-makefile` the first time after checking out this commit
-
Vasil Velichkov authored
Rename the existing files to match the glob used in the Makefile To execute the tests run `make check` or `make check-aper`
-
Vasil Velichkov authored
and regenerate the the S1AP Makefile
-
- 07 Mar, 2018 1 commit
-
-
Vasil Velichkov authored
-
- 06 Mar, 2018 1 commit
-
-
Vasil Velichkov authored
According to Rec. ITU-T X.691 (08/2015) 11.5.3 Let "range" be defined as the integer value ("ub" – "lb" + 1), and let the value to be encoded be "n". See also https://github.com/vlm/asn1c/issues/185#issuecomment-368745830
-
- 05 Mar, 2018 4 commits
-
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
When generating code for multiple ASN.1 syntaxes that have clashing names, we need to add a prefix in order to prevent clashes in the global C symbol namespace. Using the ASN1C_PREFIX environment variable and this patch serves as a work-around to that. All non-basic type names as well as references to that type and source code + header file names will be pre-fixed accordingly. This is a re-implementation of this feature due to osmocom's implementation version can not work on newest asn1c repository.
-
- 09 Feb, 2018 1 commit
-
-
Bi-Ruei, Chiu authored
-
- 02 Feb, 2018 1 commit
-
-
Bi-Ruei, Chiu authored
-
- 26 Jan, 2018 5 commits
-
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
1. Copying and modifying ANY_decode_uper() and ANY_encode_uper() to ANY_decode_aper() and ANY_encode_aper(). 2. Adding ANY_fromType_aper()/ANY_new_fromType_aper()/ ANY_to_type_aper().
-
Bi-Ruei, Chiu authored
Based on Velichkov's suggestion on comment : https://github.com/vlm/asn1c/issues/185#issuecomment-341944947
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
-
- 24 Jan, 2018 2 commits
-
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
For RANAP specification : RANAP-ELEMENTARY-PROCEDURE ::= CLASS { &InitiatingMessage, &SuccessfulOutcome OPTIONAL, &UnsuccessfulOutcome OPTIONAL, &Outcome OPTIONAL, &procedureCode ProcedureCode UNIQUE, &criticality Criticality DEFAULT ignore } WITH SYNTAX { INITIATING MESSAGE &InitiatingMessage [SUCCESSFUL OUTCOME &SuccessfulOutcome] [UNSUCCESSFUL OUTCOME &UnsuccessfulOutcome] [OUTCOME &Outcome] PROCEDURE CODE &procedureCode [CRITICALITY &criticality] } Not all instances of elementary procedure have all their optional members defined. For examples : iu-Release RANAP-ELEMENTARY-PROCEDURE ::= { INITIATING MESSAGE Iu-ReleaseCommand SUCCESSFUL OUTCOME Iu-ReleaseComplete PROCEDURE CODE id-Iu-Release CRITICALITY reject } rAB-Assignment RANAP-ELEMENTARY-PROCEDURE ::= { INITIATING MESSAGE RAB-AssignmentRequest OUTCOME RAB-AssignmentResponse PROCEDURE CODE id-RAB-Assignment CRITICALITY reject } So there are empty cells generated in Outcome.c ... etc. static const asn_ioc_cell_t asn_IOS_RANAP_ELEMENTARY_PROCEDURES_1_rows[] = { { "&InitiatingMessage", aioc__type, &asn_DEF_Iu_ReleaseCommand }, { "&SuccessfulOutcome", aioc__type, &asn_DEF_Iu_ReleaseComplete }, { "&UnsuccessfulOutcome", }, { "&Outcome", }, { "&procedureCode", aioc__value, &asn_DEF_ProcedureCode, &asn_VAL_1_id_Iu_Release }, { "&criticality", aioc__value, &asn_DEF_Criticality, &asn_VAL_1_reject }, { "&InitiatingMessage", aioc__type, &asn_DEF_RAB_AssignmentRequest }, { "&SuccessfulOutcome", }, { "&UnsuccessfulOutcome", }, { "&Outcome", aioc__type, &asn_DEF_RAB_AssignmentResponse }, { "&procedureCode", aioc__value, &asn_DEF_ProcedureCode, &asn_VAL_49_id_RAB_Assignment }, { "&criticality", aioc__value, &asn_DEF_Criticality, &asn_VAL_49_reject } } However, in type_selector() functions, these undefined cell are still be counted into presence_index value. This results in wrong behavior for decoder. This commit is to fix this problem.
-
- 23 Jan, 2018 4 commits
-
-
Bi-Ruei, Chiu authored
Currently, there is no code generated for following ASN.1 excerpt. Thus application is not aware of these values. ProtocolIE-ID ::= INTEGER (0..65535) id-MME-UE-S1AP-ID ProtocolIE-ID ::= 0 id-HandoverType ProtocolIE-ID ::= 1 id-Cause ProtocolIE-ID ::= 2 id-SourceID ProtocolIE-ID ::= 3 ... ProcedureCode ::= INTEGER (0..255) id-HandoverPreparation ProcedureCode ::= 0 id-HandoverResourceAllocation ProcedureCode ::= 1 id-HandoverNotification ProcedureCode ::= 2 id-PathSwitchRequest ProcedureCode ::= 3 ... This commit adds corresponding macro definitions in ProtocolIE-ID.h and ProcedureCode.h respectively. #define ProtocolIE_ID_id_MME_UE_S1AP_ID ((ProtocolIE_ID_t)0) #define ProtocolIE_ID_id_HandoverType ((ProtocolIE_ID_t)1) #define ProtocolIE_ID_id_Cause ((ProtocolIE_ID_t)2) #define ProtocolIE_ID_id_SourceID ((ProtocolIE_ID_t)3) ... #define ProcedureCode_id_HandoverPreparation ((ProcedureCode_t)0) #define ProcedureCode_id_HandoverResourceAllocation ((ProcedureCode_t)1) #define ProcedureCode_id_HandoverNotification ((ProcedureCode_t)2) #define ProcedureCode_id_PathSwitchRequest ((ProcedureCode_t)3) ... Only types of ASN_BASIC_INTEGER and ASN_BASIC_ENUMERATED referenced by these constant variables are handled. Other built-in types shall be added in the future.
-
Bi-Ruei, Chiu authored
Currently, there is no code generated for following ASN.1 excerpt. Thus application is not aware of these values. maxnoofErrors INTEGER ::= 256 maxnoofBPLMNs INTEGER ::= 6 maxnoofPLMNsPerMME INTEGER ::= 32 maxnoofEPLMNs INTEGER ::= 15 ... This commit generate asn_constant.h which has the following macro defitions : #define maxnoofErrors (256) #define maxnoofBPLMNs (6) #define maxnoofPLMNsPerMME (32) #define maxnoofEPLMNs (15) #define maxnoofEPLMNsPlusOne (16) ... It only handles ASN_BASIC_INTEGER type. Other built-in types shall be added in the future.
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
With previous commit, the following data types are generated in ProtocolIE-Field.h for S1AP's ASN.1 : ``` typedef enum ProtocolIE_Field_6564P0__value_PR { ProtocolIE_Field_6564P0__value_PR_NOTHING, /* No components present */ ProtocolIE_Field_6564P0__value_PR_E_RABToBeSetupItemBearerSUReq } ProtocolIE_Field_6564P0__value_PR; typedef struct ProtocolIE_Field_6564P0 { ProtocolIE_ID_t id; Criticality_t criticality; struct ProtocolIE_Field_6564P0__value { ProtocolIE_Field_6564P0__value_PR present; union ProtocolIE_Field_6564P0__value_u { E_RABToBeSetupItemBearerSUReq_t E_RABToBeSetupItemBearerSUReq; } choice; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } value; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } ProtocolIE_Field_6564P0_t; ``` It's difficult for developer to recognize to which ASN.1 type they are linked. They all start with 'ProtocolIE_Field_'. It will be error-prone. With this commit, more human comprehensible data types are generated : ``` typedef enum E_RABToBeSetupItemBearerSUReqIEs__value_PR { E_RABToBeSetupItemBearerSUReqIEs__value_PR_NOTHING, /* No components present */ E_RABToBeSetupItemBearerSUReqIEs__value_PR_E_RABToBeSetupItemBearerSUReq } E_RABToBeSetupItemBearerSUReqIEs__value_PR; typedef struct E_RABToBeSetupItemBearerSUReqIEs { ProtocolIE_ID_t id; Criticality_t criticality; struct E_RABToBeSetupItemBearerSUReqIEs__value { E_RABToBeSetupItemBearerSUReqIEs__value_PR present; union E_RABToBeSetupItemBearerSUReqIEs__value_u { E_RABToBeSetupItemBearerSUReq_t E_RABToBeSetupItemBearerSUReq; } choice; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } value; /* Context for parsing across buffer boundaries */ asn_struct_ctx_t _asn_ctx; } E_RABToBeSetupItemBearerSUReqIEs_t; ``` Developers can understand they are generated from : ``` E-RABToBeSetupItemBearerSUReqIEs S1AP-PROTOCOL-IES ::= { { ID id-E-RABToBeSetupItemBearerSUReq CRITICALITY reject TYPE E-RABToBeSetupItemBearerSUReq PRESENCE mandatory }, ... } ```
-
- 16 Jan, 2018 4 commits
-
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
-
Bi-Ruei, Chiu authored
For example, E-RABToBeSetupItemCtxtSUReqIEs S1AP-PROTOCOL-IES ::= { { ID id-E-RABToBeSetupItemCtxtSUReq CRITICALITY reject TYPE E-RABToBeSetupItemCtxtSUReq PRESENCE mandatory }, ... } generate : static const asn_ioc_cell_t asn_IOS_E_RABToBeSetupItemCtxtSUReqIEs_1_rows[] = { };
-
Bi-Ruei, Chiu authored
Solve the problem that 'TYPE OCTECT STRING' fails to generate corresponding item. ClassObj S1AP-PROTOCOL-IES ::= { { ID id-eNB-UE-S1AP-ID CRITICALITY reject TYPE ENB-UE-S1AP-ID PRESENCE mandatory}| { ID id-S1-Message CRITICALITY reject TYPE OCTET STRING PRESENCE mandatory}| ... }
-