Attention is currently required from: arehbein, daniel, fixeria.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/34966?usp=email )
Change subject: logging_gsmtap: Temporarily disable logging when sending the logs
......................................................................
Patch Set 2:
(1 comment)
File src/core/logging_gsmtap.c:
https://gerrit.osmocom.org/c/libosmocore/+/34966/comment/2ae312bb_d173590a
PS2, Line 118: level = target->loglevel
> I believe we should not be overwriting the input parameters for the sake of saving one variable. […]
as daniel is on holidays and this is a fairly trivial change: @fixeria, would you mind amending this patch and sending an updated version?
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/34966?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I19203cadbad6019a3834793b8ac816d903fe088e
Gerrit-Change-Number: 34966
Gerrit-PatchSet: 2
Gerrit-Owner: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: arehbein <arehbein(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 09 Nov 2023 12:27:51 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/34974?usp=email )
Change subject: allow (second) CS RAB Assignment Request without RTP info
......................................................................
allow (second) CS RAB Assignment Request without RTP info
In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).
Directly forward all RAB Assignment Requests that have no RTP
information. This covers above use case, and also generally applies: no
RTP info means nothing to tell the MGW about.
Do not (yet?) support modifying the RTP address/port.
Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
---
M src/osmo-hnbgw/mgw_fsm.c
1 file changed, 80 insertions(+), 0 deletions(-)
Approvals:
laforge: Looks good to me, but someone else must approve
osmith: Looks good to me, approved
Jenkins Builder: Verified
diff --git a/src/osmo-hnbgw/mgw_fsm.c b/src/osmo-hnbgw/mgw_fsm.c
index ddab0b5..7b4c811 100644
--- a/src/osmo-hnbgw/mgw_fsm.c
+++ b/src/osmo-hnbgw/mgw_fsm.c
@@ -683,6 +683,47 @@
return 0;
}
+static bool is_rab_ass_without_tli(struct hnbgw_context_map *map, ranap_message *message)
+{
+ RANAP_RAB_AssignmentRequestIEs_t *ies;
+ RANAP_ProtocolIE_ContainerPair_t *protocol_ie_container_pair;
+ RANAP_ProtocolIE_FieldPair_t *protocol_ie_field_pair;
+ RANAP_RAB_SetupOrModifyItemFirst_t _rab_setup_or_modify_item_first = { 0 };
+ RANAP_RAB_SetupOrModifyItemFirst_t *rab_setup_or_modify_item_first = &_rab_setup_or_modify_item_first;
+ int rc;
+ bool ret;
+
+ ies = &message->msg.raB_AssignmentRequestIEs;
+
+ if (!(ies->presenceMask & RAB_ASSIGNMENTREQUESTIES_RANAP_RAB_SETUPORMODIFYLIST_PRESENT))
+ return false;
+
+ /* Detect the end of the list */
+ if (ies->raB_SetupOrModifyList.list.count < 1)
+ return false;
+
+ protocol_ie_container_pair = ies->raB_SetupOrModifyList.list.array[0];
+ protocol_ie_field_pair = protocol_ie_container_pair->list.array[0];
+
+ if (!protocol_ie_field_pair)
+ return false;
+
+ if (protocol_ie_field_pair->id != RANAP_ProtocolIE_ID_id_RAB_SetupOrModifyItem) {
+ RANAP_DEBUG
+ ("Decoding failed, the protocol IE field-pair is not of type RANAP RAB setup-or-modify-item!\n");
+ return false;
+ }
+
+ rc = ranap_decode_rab_setupormodifyitemfirst(rab_setup_or_modify_item_first,
+ &protocol_ie_field_pair->firstValue);
+ if (rc < 0)
+ return false;
+
+ ret = rab_setup_or_modify_item_first->transportLayerInformation == NULL;
+ ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_RANAP_RAB_SetupOrModifyItemFirst, rab_setup_or_modify_item_first);
+ return ret;
+}
+
/* Check if the message contains a RAB-ReleaseItem that matches the RAB-ID that is managed by the given context map */
static bool is_our_rab_release(struct hnbgw_context_map *map, ranap_message *message)
{
@@ -721,6 +762,15 @@
initialized = true;
}
+ /* There may be CS RAB Assignment Requests without actual RTP information: after a normal RAB Assignment,
+ * another RAB Assignment may follow, modifying some RAB parameters. When there is no RTP info in the message,
+ * there is no RTP to redirect via MGW, hence just forward as-is. */
+ if (is_rab_ass_without_tli(map, message)) {
+ LOG_MAP(map, DCN, LOGL_INFO,
+ "Rx RAB Assignment Request without transportLayerInformation, forwarding as-is\n");
+ return map_rua_dispatch(map, MAP_RUA_EV_TX_DIRECT_TRANSFER, ranap_msg);
+ }
+
/* The RTP stream negotiation usually begins with a RAB-AssignmentRequest and ends with an IU-Release, however
* it may also be that the MSC decides to release the RAB with a dedicated RAB-AssignmentRequest that contains
* a ReleaseList. In this case an FSM will already be present. */
@@ -791,6 +841,13 @@
return -1;
}
+ if (map->mgw_fi->state == MGW_ST_ESTABLISHED) {
+ /* This is a response to a second RAB Assignment Request, which only modified some RAB config on top of
+ * an earlier RAB Assignment. Just forward the response as-is, we already have our MGW set up and need
+ * no info from it. (i.e. we don't support modifying the RTP address.) */
+ return map_sccp_dispatch(map, MAP_SCCP_EV_TX_DATA_REQUEST, ranap_msg);
+ }
+
mgw_fsm_priv = map->mgw_fi->priv;
talloc_steal(mgw_fsm_priv, ranap_msg);
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/34974?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
Gerrit-Change-Number: 34974
Gerrit-PatchSet: 4
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: daniel.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/34967?usp=email )
Change subject: tests: Test gsmtap logging if write queue fills up
......................................................................
Patch Set 2: Code-Review-1
(4 comments)
File tests/Makefile.am:
https://gerrit.osmocom.org/c/libosmocore/+/34967/comment/b0f29678_b196770f
PS2, Line 18: logging/logging_test_gsmtap
This file needs to be updated properly:
* define `logging_test_gsmtap_SOURCES`,
* add `logging_test_gsmtap.err` to `EXTRA_DIST`.
https://gerrit.osmocom.org/c/libosmocore/+/34967/comment/742cd617_f1dc078e
PS2, Line 566: logging/logging_test
add the respective statement for `logging_test_gsmtap` here
File tests/logging/logging_test_gsmtap.err:
https://gerrit.osmocom.org/c/libosmocore/+/34967/comment/207ec47b_9dddbd44
PS2, Line 108: 0x611000000328
this is non-deterministic output, we should not match it
File tests/testsuite.at:
https://gerrit.osmocom.org/c/libosmocore/+/34967/comment/cc41c509_d39525a8
PS2, Line 206: logging_test_gsmtap.ok
no such file?
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/34967?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Id5ae0c4c3820a9ed59eaf4003d2c57b6bdfe3468
Gerrit-Change-Number: 34967
Gerrit-PatchSet: 2
Gerrit-Owner: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 09 Nov 2023 11:51:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: arehbein, daniel, laforge.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/34966?usp=email )
Change subject: logging_gsmtap: Temporarily disable logging when sending the logs
......................................................................
Patch Set 2:
(1 comment)
File src/core/logging_gsmtap.c:
https://gerrit.osmocom.org/c/libosmocore/+/34966/comment/2ef9061c_b6b37246
PS2, Line 118: level = target->loglevel
I believe we should not be overwriting the input parameters for the sake of saving one variable. If someone later adds some code below, they may need the original value passed by the caller, and it may not be obvious to them that it was overwritten. All in all, please add a new `unsigned int` variable for temporary storage of the `target->loglevel`.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/34966?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I19203cadbad6019a3834793b8ac816d903fe088e
Gerrit-Change-Number: 34966
Gerrit-PatchSet: 2
Gerrit-Owner: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: arehbein <arehbein(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: arehbein <arehbein(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: daniel <dwillmann(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 09 Nov 2023 11:42:02 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Hoernchen has submitted this change. ( https://gerrit.osmocom.org/c/osmo-trx/+/34965?usp=email )
Change subject: ms: init blade with fpga control
......................................................................
ms: init blade with fpga control
Blade 1 defaults to fpga tuning, but the blade 2 code defaults to host,
which does 8000 register reads and writes. The only way to speed this up
is to set the env var, which reduces opening the blade device from 10 to
1 seconds.
Change-Id: I32fe31f1e11f4ceb3c864ec8739d177e780d0a7e
---
M Transceiver52M/ms/bladerf_specific.h
1 file changed, 16 insertions(+), 0 deletions(-)
Approvals:
Jenkins Builder: Verified
laforge: Looks good to me, but someone else must approve
fixeria: Looks good to me, approved
diff --git a/Transceiver52M/ms/bladerf_specific.h b/Transceiver52M/ms/bladerf_specific.h
index e32d77c..e9245d4 100644
--- a/Transceiver52M/ms/bladerf_specific.h
+++ b/Transceiver52M/ms/bladerf_specific.h
@@ -254,6 +254,8 @@
bladerf_log_set_verbosity(BLADERF_LOG_LEVEL_DEBUG);
bladerf_set_usb_reset_on_open(true);
+
+ setenv("BLADERF_DEFAULT_TUNING_MODE","fpga",1); // ensure blade 2 does not spend 10 seconds initializing host control
blade_check(bladerf_open, &dev, "");
if (!dev) {
std::cerr << "open failed, device missing?" << std::endl;
--
To view, visit https://gerrit.osmocom.org/c/osmo-trx/+/34965?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-trx
Gerrit-Branch: master
Gerrit-Change-Id: I32fe31f1e11f4ceb3c864ec8739d177e780d0a7e
Gerrit-Change-Number: 34965
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged