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
... 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
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
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
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.
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.
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*
A HNBRegisterAccept message should not contain HNBRegisterResponse IEs
This spec inconsistency is confusing the asn1tostruct.py code generator,
so let's remove it.
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.
Bernhard M. Wiedemann
