Attention is currently required from: laforge.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email )
Change subject: support RAB Assignment in cn_ranap_rx_*_msg_co()
......................................................................
Patch Set 2:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-iuh/+/37393/comment/49ee9033_44a78c0a
PS2, Line 20: Procedure", but doesn't
> I always assumed that the "outcome" is for the "intermediate" responses and the final response would […]
My humble conclusion is to just accept all the variants that an implementation could sensibly choose. There are no adverse effects AFAICT.
Details:
If an implementation were separating the outcomes by success/failure, each would have to be a separate RANAP PDU entirely:
Below listings show how the [[un]successful]outcome is indicated once in the "top" of the RANAP PDU, and the RAB Assignment lists of actual detailed responses is deeper within that single PDU:
```
typedef struct RANAP_RANAP_PDU {
RANAP_RANAP_PDU_PR present;
union RANAP_RANAP_PDU_u {
RANAP_InitiatingMessage_t initiatingMessage;
RANAP_SuccessfulOutcome_t successfulOutcome;
RANAP_UnsuccessfulOutcome_t unsuccessfulOutcome;
RANAP_Outcome_t outcome;
/*
* This type is extensible,
* possible extensions are below.
*/
} choice;
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} RANAP_RANAP_PDU_t;
typedef struct RANAP_SuccessfulOutcome {
RANAP_ProcedureCode_t procedureCode; --> "RAB Assignment"
RANAP_Criticality_t criticality;
ANY_t value; --> decoded to struct ranap_message
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} RANAP_SuccessfulOutcome_t;
typedef struct ranap_message_s {
uint8_t procedureCode; --> "RAB Assignment"
uint8_t criticality;
uint8_t direction; --> initiating/*outcome copied from RANAP_PDU
union {
...
RANAP_RAB_AssignmentRequestIEs_t raB_AssignmentRequestIEs;
RANAP_RAB_AssignmentResponseIEs_t raB_AssignmentResponseIEs;
...
}
}
typedef struct RANAP_RAB_AssignmentResponseIEs_s {
uint16_t presenceMask;
RANAP_RAB_SetupOrModifiedList_t raB_SetupOrModifiedList; ///< Optional field
RANAP_RAB_ReleasedList_t raB_ReleasedList; ///< Optional field
RANAP_RAB_QueuedList_t raB_QueuedList; ///< Optional field
RANAP_RAB_FailedList_t raB_FailedList; ///< Optional field
RANAP_RAB_ReleaseFailedList_t raB_ReleaseFailedList; ///< Optional field
RANAP_CriticalityDiagnostics_t criticalityDiagnostics; ///< Optional field
} RANAP_RAB_AssignmentResponseIEs_t;
```
A clear wording on which kind of outcome should be used doesn't seem to exist for Class 3, we only have this for Class 1:
3GPP TS 25.413 3.1:
"[Class 1 EP...]
Successful and Unsuccessful:
- One signalling message reports both successful and unsuccessful outcome for the different included requests.
The response message used is the one defined for successful outcome.
"
An implementation could assume the same for Class 3. Or they could return "outcome" for mixed outcomes. Or they could make it unsuccessful if >=1 items have failed... Each interpretation makes sense from different points of view.
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: Ifec566a98cb6141d27b9e5e33d5a78f8b1530658
Gerrit-Change-Number: 37393
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Sat, 06 Jul 2024 14:55:07 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: neels.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email )
Change subject: support RAB Assignment in cn_ranap_rx_*_msg_co()
......................................................................
Patch Set 2: Code-Review+1
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-iuh/+/37393/comment/aa9aba01_b34723a3
PS2, Line 20: Procedure", but doesn't
I always assumed that the "outcome" is for the "intermediate" responses and the final response would then be a "successfulOutcome" or an "unsuccessfulOutcome".
So basically any rab assignment request would always see exactly one of either "successful" or "unsuccessful" outcome, plus 0..N "outcome". This is just my gut feeling of how I understand those type of 3GPP specs - I cannot give you a spec refrerence for it.
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: Ifec566a98cb6141d27b9e5e33d5a78f8b1530658
Gerrit-Change-Number: 37393
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 06 Jul 2024 11:00:08 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: neels.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-iuh/+/37414?usp=email )
Change subject: ranap_cn_rx_co(): do not ranap_cn_rx_co_free() on error
......................................................................
Patch Set 2: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37414?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: If7545f91c69f06bc32c55cab7dcfcad8350b0473
Gerrit-Change-Number: 37414
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 06 Jul 2024 10:56:52 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email
to look at the new patch set (#2).
Change subject: support RAB Assignment in cn_ranap_rx_*_msg_co()
......................................................................
support RAB Assignment in cn_ranap_rx_*_msg_co()
Allow decoding all Assignment Request/Response messages.
A RAB Assignment request is
- connection oriented
- 'initiatingMessage'
- procedureCode == RAB_Assignment
A RAB Assignment response is
- connection oriented
- 'successfulOutcome' or 'unsuccessfulOutcome' or 'outcome'
(3GPP TS 25.413 specifies RAB Assignment as a "Class 3 Elementary
Procedure", but doesn't seem to specify which of these three 'outcome'
types to use for Class 3. In the field we've seen 'successfulOutcome'
and 'outcome'. Either one is fine.)
- procedureCode == RAB_Assignment
Add decoding the request to cn_ranap_rx_initiating_msg_co().
Add decoding the unsuccessful response to
cn_ranap_rx_unsuccessful_msg_co();
Decoding the successful response is already present in
cn_ranap_rx_successful_msg_co().
osmo-gsm-shark uses this to connect a voice call's signalling with RTP.
Change-Id: Ifec566a98cb6141d27b9e5e33d5a78f8b1530658
---
M src/ranap_common_cn.c
1 file changed, 46 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-iuh refs/changes/93/37393/2
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37393?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: Ifec566a98cb6141d27b9e5e33d5a78f8b1530658
Gerrit-Change-Number: 37393
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: newpatchset
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-iuh/+/37413?usp=email )
Change subject: fix memleak: free after aper_decode() also on error
......................................................................
fix memleak: free after aper_decode() also on error
It turns out that aper_decode() wants the caller to ASN_STRUCT_FREE()
always, also even when it returned != RC_OK.
When during a test I was feeding random data (a BSSMAP message) to
ranap_cn_rx_co_decode2(), I ended up with ASAN indicating a memory leak:
```
pkt DEBUG packet.1 RANAP 01 00 03 05 18 01 (decode_iu.c:658)
tag ERROR Error in RANAP ASN.1 decode (ranap_common_cn.c:401)
tag ERROR Not calling cn_ranap_handle_co() due to rc=-1 (ranap_common_cn.c:428)
pkt ERROR packet.1 RANAP failed to decode RANAP data (decode_iu.c:668)
=================================================================
==1920572==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 208 byte(s) in 1 object(s) allocated from:
#0 0x7f34520f3bc7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f34526ccddd (/lib/x86_64-linux-gnu/libtalloc.so.2+0x5ddd) (BuildId: 75c550e5dc091c77e1159c52b284f34d0c4d92cd)
Indirect leak of 102 byte(s) in 1 object(s) allocated from:
#0 0x7f34520f3bc7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f34526ccddd (/lib/x86_64-linux-gnu/libtalloc.so.2+0x5ddd) (BuildId: 75c550e5dc091c77e1159c52b284f34d0c4d92cd)
SUMMARY: AddressSanitizer: 310 byte(s) leaked in 2 allocation(s).
```
With this patch, the leak is gone.
Change-Id: I03ed2376e520ec6dbcc2bae22f9291e211c7cca9
---
M src/ranap_common_cn.c
1 file changed, 43 insertions(+), 2 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-iuh refs/changes/13/37413/1
diff --git a/src/ranap_common_cn.c b/src/ranap_common_cn.c
index 1a01bb0..26f9e69 100644
--- a/src/ranap_common_cn.c
+++ b/src/ranap_common_cn.c
@@ -399,13 +399,15 @@
dec_ret = aper_decode(NULL, &asn_DEF_RANAP_RANAP_PDU, (void **)&pdu, data, len, 0, 0);
if (dec_ret.code != RC_OK) {
LOGP(DRANAP, LOGL_ERROR, "Error in RANAP ASN.1 decode\n");
- return -1;
+ rc = -1;
+ goto error_free;
}
message->direction = pdu->present;
rc = _cn_ranap_rx_co(pdu, message);
+error_free:
ASN_STRUCT_FREE(asn_DEF_RANAP_RANAP_PDU, pdu);
return rc;
@@ -645,13 +647,15 @@
dec_ret = aper_decode(NULL, &asn_DEF_RANAP_RANAP_PDU, (void **)&pdu, data, len, 0, 0);
if (dec_ret.code != RC_OK) {
LOGP(DRANAP, LOGL_ERROR, "Error in RANAP ASN.1 decode\n");
- return -1;
+ rc = -1;
+ goto error_free;
}
message->direction = pdu->present;
rc = _cn_ranap_rx_cl(pdu, message);
+error_free:
ASN_STRUCT_FREE(asn_DEF_RANAP_RANAP_PDU, pdu);
return rc;
--
To view, visit https://gerrit.osmocom.org/c/osmo-iuh/+/37413?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-iuh
Gerrit-Branch: master
Gerrit-Change-Id: I03ed2376e520ec6dbcc2bae22f9291e211c7cca9
Gerrit-Change-Number: 37413
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: newchange