| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Related: SYS#6297
Change-Id: I424c4ea2681f5c9a5eec99396502615de5eab841
|
|
Make the script work with python < 3.6 again by not using f-strings.
Fix for:
SyntaxError: invalid syntax
File "../../git/asn1/utils/asn1tostruct.py", line 94
f" IE {ie}. Found another entry in ies {ie_other}" \
^
Fixes: 1d19c8e2 ("asn1tostruct: fix defines getting redefined")
Change-Id: I3a19b8a1147532b41d3ed7b802de595302ff8f44
|
|
Do not write the same define twice for two files in a struct, e.g.:
#define ENHANCEDRELOCATIONCOMPLETEREQUESTIES_RANAP_EXTENDEDRNC_ID_PRESENT (1 << 0)
#define ENHANCEDRELOCATIONCOMPLETEREQUESTIES_RANAP_EXTENDEDRNC_ID_PRESENT (1 << 1)
#define ENHANCEDRELOCATIONCOMPLETEREQUESTIES_RANAP_RAB_SETUPLIST_ENHANCEDRELOCCOMPLETEREQ_PRESENT (1 << 2)
typedef struct RANAP_EnhancedRelocationCompleteRequestIEs_s {
uint16_t presenceMask;
RANAP_IuSignallingConnectionIdentifier_t oldIuSigConId;
RANAP_IuSignallingConnectionIdentifier_t iuSigConId;
RANAP_GlobalRNC_ID_t relocation_SourceRNC_ID;
RANAP_ExtendedRNC_ID_t relocation_SourceExtendedRNC_ID; ///< Optional field
RANAP_GlobalRNC_ID_t relocation_TargetRNC_ID;
RANAP_ExtendedRNC_ID_t relocation_TargetExtendedRNC_ID; ///< Optional field
RANAP_RAB_SetupList_EnhancedRelocCompleteReq_t raB_SetupList_EnhancedRelocCompleteReq; ///< Optional field
} RANAP_EnhancedRelocationCompleteRequestIEs_t;
The problem is that the type is used and it may not be unique inside a
struct. Change the code to use the name of the field if the type is not
unique. Keep using the type otherwise so existing code doesn't need to
be modified a lot to fix this.
Fix for:
../include/osmocom/ranap/ranap_ies_defs.h:514: warning: "RANAP_ENHANCEDRELOCATIONINFORMATIONREQUESTIES_RANAP_IUSIGNALLINGCONNECTIONIDENTIFIER_PRESENT" redefined
Change-Id: I2ecae6789899952d1dc5691ab76907abeaa71c12
|
|
Fix warnings from generated asn1 code in order to build osmo-iuh with
werror in a future patch:
../../include/osmocom/hnbap/HNBAP_CriticalityDiagnostics-IE-List.h:29:23: error: ‘struct HNBAP_CriticalityDiagnostics_IE_List__Member’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
These visibility warnings come from "SEQUENCE … OF SEQUENCE" definitions
in the asn1 source files, as described in detail here:
https://github.com/vlm/asn1c/issues/430
It is not possible to tell gcc to just ignore these warnings since they
don't have their own type (unlike e.g. -Wuninitialized). Also it seems
like a huge effort to patch this in asn1c.
So work around the problem the same way the author of the issue worked
around it by rewriting the lines to "SEQUENCE … OF …-Value" and adding
a "…-Value ::= SEQUENCE" line below. Add a script in
asn1/utils/asn1_restructure_sequence_of_sequence.py for the
transformation and apply it.
Related: OS#4462
Change-Id: If84445ed2e0df604b581684dcf83f8520b7da84c
|
|
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I340ab63093138ada6e80edf322e401e9fbfef4ed
|
|
Make build work with python3 and drop the python2 dependency.
Related: OS#2819
Change-Id: Idb9d7a349ddb7619c784823f740648c7956bae5e
|
|
... this is what's required for asn1c to generate nice C language
enums for it. Conversion was performed semi-automatically by use
of asn1enum.pl
Change-Id: I0cd78a102ec6e31c696efc2cc6a4f08a0ba6d89e
|
|
Change-Id: I8211bc334b325e8950edcd769917f164a65591ba
|
|
They cannot immediately be consumed by our (ancient, hacked) asn1c
toolchain, so we have to massage them into the supported format
in follow-up commits.
Change-Id: I9fa05d14493889e0a23354938b04a335a117f242
|
|
This fixes the following error message:
Experimental keys on scalar is now forbidden at ./asn1enum.pl line 25.
Change-Id: I4680627acfd8f3ed73d32324fe0a54b554268f3b
|
|
in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
Also do not record build user name to not have it vary.
Change-Id: I5cfa465cc82f009f28dd7f12ced0e72a05fda842
|
|
Part of the resulting diff in the generated code:
--- /tmp/hnbap_decoder.c 2017-12-24 17:06:50.983979866 +0100
+++ /tmp/hnbap_decoder.c 2017-12-24 17:07:10.760223354 +0100
@@ -1179,6 +1179,7 @@
TNLUpdateResponseIEs_t *tnlUpdateResponseIEs) {
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Context_ID, &tnlUpdateResponseIEs->context_ID);
+ return 0;
}
int hnbap_free_tnlupdaterequesties(
@@ -1187,6 +1188,7 @@
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Context_ID, &tnlUpdateRequestIEs->context_ID);
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_RABList, &tnlUpdateRequestIEs->rabList);
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_Update_cause, &tnlUpdateRequestIEs->update_cause);
+ return 0;
}
int hnbap_free_errorindicationies(
@@ -1197,12 +1199,14 @@
if ((errorIndicationIEs->presenceMask & ERRORINDICATIONIES_CRITICALITYDIAGNOSTICS_PRESENT)
== ERRORINDICATIONIES_CRITICALITYDIAGNOSTICS_PRESENT)
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_CriticalityDiagnostics, &errorIndicationIEs->criticalityDiagnostics);
+ return 0;
}
int hnbap_free_hnbconfigtransferrequesties(
HNBConfigTransferRequestIEs_t *hnbConfigTransferRequestIEs) {
ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_NeighbourInfoRequestList, &hnbConfigTransferRequestIEs->neighbourInfoRequestList);
+ return 0;
}
int hnbap_free_tnlupdatefailureies(
[etc.]
Related: OS#2670
Change-Id: Ieba12c09c33a81da964bf88a858714d922ced8c0
|
|
Looking at hnbap_decode_hnbregisterrequesties(), I noticed a segfault if
decoding the HNB Register Request PDU fails, which is due to an unchecked
return value in code generated by asn1tostruct.py.
Add return value and NULL pointer checks and hence fix null dereference on
erratic PDUs across HNBAP, RUA and RANAP protocols. Similar checks exist in
other places, this one was simply missing.
Since the result of asn1tostruct.py is not committed, here is an example diff
of the resulting change, of which there are 128 instances in total:
@@ -304,7 +329,12 @@
memset(hnbRegisterRequestIEs, 0, sizeof(HNBRegisterRequestIEs_t));
HNBAP_DEBUG("Decoding message HNBRegisterRequestIEs (%s:%d)\n", __FILE__, __LINE__);
- ANY_to_type_aper(any_p, &asn_DEF_HNBRegisterRequest, (void**)&hNBRegisterRequest_p);
+ tempDecoded = ANY_to_type_aper(any_p, &asn_DEF_HNBRegisterRequest, (void**)&hNBRegisterRequest_p);
+
+ if (tempDecoded < 0 || hNBRegisterRequest_p == NULL) {
+ HNBAP_DEBUG("Decoding of message HNBRegisterRequestIEs failed\n");
+ return -1;
+ }
for (i = 0; i < hNBRegisterRequest_p->hnbRegisterRequest_ies.list.count; i++) {
IE_t *ie_p;
Change-Id: I6cb9cc9a88d22f03befa43f0968a874476fa079d
|
|
The script is expected to be run using python 2.x, but nowadays some
distros are already using python 3 as default, which will fail to run
this script.
This change fixes compilation in my Archlinux box.
Change-Id: I6eb95351538a64f2b23d638824972818591b1b66
|
|
Change-Id: I0686467e59b35e68bccb38ccfe645f5ccac97941
|
|
ranap_ies_defs.h is checked in so update it
hnbap_ies_defs.h and rua_ies_defs.h need to be regenerated
|
|
|
|
|
|
|
|
With that syntax error, the RAC was not treated as a possible IE
in the InitialUE-Message, causing decoder failure.
|
|
in order to work around a bug in asn1c. When we keep the original
TBCD-STRING, the APER-encoded PLMNidentity always has an extra leading
length byte that the decoder doesn't expect.
|
|
The decode_*ies functions did not clean up after them. This change is
taken from changes made to asn1tostruct.py in openair-cn repository.
|
|
The ffasn1c files from early trials are obsolete, we're using asn1c now.
|
|
When IMSI is a TBCD-STRING type, and TBCD-STRING is defined as OCTET
STRING, we end up encoding the IMSI the wrong way. I don't knwo why
that is, but changing it fixed the problem, as described below:
before this commit:
00 17 PeranentNAS-UE-ID
40 criticality ignore
0a (length)
00 presence = IMSI
08 BUG: why the additional length field?
46 23 91 34 70 77 80 f3 IMSI (643219430777083)
after this commit:
00 17 PeranentNAS-UE-ID
40 criticality ignore
09 (length)
50 presence = IMSI
46 23 91 34 70 77 80 f3 IMSI (643219430777083)
|
|
|
|
The definition of the above data types as per 3GPP specs results in a
SEQUENCE_OF() an anonymous structure, which is slightly inconvenient to
use. So let's split the SEQUENCE OF part and the actual definition of
the item in separate types.
|
|
This is not development, it is random trial and error hacking. I really
hate the fact that we have no useful asn.1 code generator and need to
work with hacks like asn1tostruct.py and asn1c without information
object classes :/
This commit is a one-day-long iteration of trial+error, manually editing
and adding the .asn source of RANAP until we get something that in the
end at least compiles and links. Do I trust the resulting code? No.
But we have no alternative :(
|
|
We shouldn't generate names like
RANAP_RAB_SetupList_EnhancedRelocCompleteReq__t when creating the
_encode() and _decode() functiosn, as the '-IEs' at the end must be
stripped before converting all '-' to '_'.
|
|
As asn1c cannot understand information object classes, we cannot compile
RANAP-PDU-Contents.asn but instead need to manually add the respective
infrmation elements to RANAP-PDU.asn.
|
|
we are generating the code locally in src/{ranap,rua,hnbap}
|
|
It seems that individual IEs contain nested containers, and
asn1c is not generating code for that unless we help it by some
hand-crafted additional definitions. *sigh*
|
|
If asn1c generates prefixed type names, the asn1tostruct.py of course
also needs to be modified to do so.
|
|
It is a legal impossibility to claim copyright on something that
has been automatically generated by a computer program.
|
|
|
|
A HNBRegisterAccept message should not contain HNBRegisterResponse IEs
This spec inconsistency is confusing the asn1tostruct.py code generator,
so let's remove it.
|
|
this is done semi-automatically using the asn1msgs.pl script.
|
|
|
|
... this is what's required for asn1c to generate nice C language
enums for it. Conversion was performed semi-automatically by use
of asn1enum.pl
|
|
|
|
If we avoid using Information Object Classes in the IE definitions
(which are only used for Extension Containers), then we can compile the
ASN.1 source using Lev Walkin's asn1c.
|
|
If we avoid using Information Object Classes in the IE definitions
(which are only used for Extension Containers), then we can compile the
ASN.1 source using Lev Walkin's asn1c.
|
|
If we avoid using Information Object Classes in the IE definitions
(which are only used for Extension Containers), then we can compile the
ASN.1 source using Lev Walkin's asn1c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
