- 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 5 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}| ... }
-
Bi-Ruei, Chiu authored
Set the key.sequence to eclass's _type_unique_index and increment it in each object parsing call, then set the result back to _type_unique_index field. It can keep a class-wise counter for eash object instantiated. This new method not only solve name duplication when union two information object sets, but also avoid name duplication within multiple instances of this class.
-