neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/31463 )
Change subject: cosmetic: regroup members of hnbgw_context_map
......................................................................
cosmetic: regroup members of hnbgw_context_map
Change the order in the struct definition so that the items for RUA and
for SCCP are grouped together. Tweak comments.
Change-Id: I84424617996d8e1a6814aa122e63454c0666b724
---
M include/osmocom/hnbgw/context_map.h
1 file changed, 23 insertions(+), 8 deletions(-)
Approvals:
Jenkins Builder: Verified
msuraev: Looks good to me, but someone else must approve
laforge: Looks good to me, approved
diff --git a/include/osmocom/hnbgw/context_map.h b/include/osmocom/hnbgw/context_map.h
index 97e1b09..7bcdf57 100644
--- a/include/osmocom/hnbgw/context_map.h
+++ b/include/osmocom/hnbgw/context_map.h
@@ -28,23 +28,26 @@
struct hnbgw_context_map {
/* entry in the per-CN list of mappings */
struct llist_head cn_list;
- /* entry in the per-HNB list of mappings */
+ /* entry in the per-HNB list of mappings. */
struct llist_head hnb_list;
- /* pointer to HNB */
+
+ /* Pointer to HNB for this map, to transceive RUA. */
struct hnb_context *hnb_ctx;
- /* pointer to CN */
- struct hnbgw_cnlink *cn_link;
- /* RUA contxt ID */
+ /* RUA context ID used in RUA messages to/from the hnb_gw. */
uint32_t rua_ctx_id;
- /* False for CS, true for PS */
- bool is_ps;
- /* SCCP User SAP connection ID */
+
+ /* Pointer to CN, to transceive SCCP. */
+ struct hnbgw_cnlink *cn_link;
+ /* SCCP User SAP connection ID used in SCCP messages to/from the cn_link. */
uint32_t scu_conn_id;
/* Set to true on SCCP Conn Conf, set to false when an OSMO_SCU_PRIM_N_DISCONNECT has been sent for the SCCP
* User SAP conn. Useful to avoid leaking SCCP connections: guarantee that an OSMO_SCU_PRIM_N_DISCONNECT gets
* sent, even when RUA fails to gracefully disconnect. */
bool scu_conn_active;
+ /* False for CS, true for PS */
+ bool is_ps;
+
enum hnbgw_context_map_state state;
/* FSM instance for the MGW, handles the async MGCP communication necessary to intercept CS RAB Assignment and
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/31463
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: I84424617996d8e1a6814aa122e63454c0666b724
Gerrit-Change-Number: 31463
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: msuraev <msuraev(a)sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: laforge, pespin, msuraev.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431 )
Change subject: context map: introduce RUA and SCCP FSMs to fix leaks
......................................................................
Patch Set 6:
(5 comments)
File include/osmocom/hnbgw/context_map.h:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431/comment/48b49e44_1257e896
PS6, Line 18: * - For events that may send a RANAP message towards CN via SCCP, the msgb shall have reserved headrom to fit a struct
> typo: headroom
lol head-ROM =)
File src/osmo-hnbgw/context_map_rua.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431/comment/25581165_5e5caf15
PS6, Line 57: * Assumes local variable fi exists. */
> That's very confusing - better make no assumptions and pass all variables explicitly. […]
I agree with the principle but this one is the exception; 'fi' is literally everywhere in an fsm implementation .c file. We use a macro like this in pretty much all osmo_fsm implementation .c files.
File src/osmo-hnbgw/context_map_sccp.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431/comment/0054f0c6_281a465d
PS6, Line 63: * Assumes local variable fi exists. */
> Same here.
Done
File src/osmo-hnbgw/hnbgw.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431/comment/058fe4fa_a38f7bce
PS6, Line 862: ranap_msg = msgb_alloc_c(OTC_SELECT, sizeof(struct osmo_scu_prim) + 1500, name);
> Where does 1500 comes from?
that's a good question, I took it from prior code. Actually, before, osmo-hnbgw would reserve 1500 in *total*, and would even subtract from that the headroom required for osmo_scu_prim; so apparently all RANAP messages that osmo-hnbgw processed so far are way shorter than that.
Maybe it comes from the common MTU = 1500?
File src/osmo-hnbgw/hnbgw_rua.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431/comment/0082d02a_a53af90a
PS6, Line 230: msg = msgb_alloc(1500, "rua_to_sccp");
(this is where I took 1500 from; note that it first puts the prim, and then the ranap in l2h below)
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
Gerrit-Change-Number: 31431
Gerrit-PatchSet: 6
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: msuraev <msuraev(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: msuraev <msuraev(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 24 Feb 2023 14:19:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: msuraev <msuraev(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: neels, laforge, pespin.
Hello Jenkins Builder, laforge,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431
to look at the new patch set (#7).
Change subject: context map: introduce RUA and SCCP FSMs to fix leaks
......................................................................
context map: introduce RUA and SCCP FSMs to fix leaks
Refactor the entire RUA <-> SCCP connection-oriented message forwarding:
- conquer confusion about hnbgw_context_map release behavior, and
- eradicate SCCP connection leaks.
Finer points:
== Context map state ==
So far, we had a single context map state and some flags to keep track
of both the RUA and the SCCP connections. It was easy to miss connection
cleanup steps, especially on the SCCP side.
Instead, the two FSMs clearly define the RUA and SCCP conn states
separately, and each side takes care of its own release needs for all
possible scenarios.
- When both RUA and SCCP are released, the context map is discarded.
- A context map can stay around to wait for proper SCCP release, even if
the RUA side has lost the HNB connection.
- Completely drop the async "context mapper garbage collection", because
the FSMs clarify the release and free steps, synchronously.
- We still keep a (simplified) enum for global context map state, but
this is only used so that VTY reporting remains mostly unchanged.
== Context map cleanup confusion ==
The function context_map_hnb_released() was the general cleanup function
for a context map. Instead, add separate context_map_free().
== Free context maps separately from HNB ==
When a HNB releases, talloc_steal() the context maps out of the HNB
specific hnb_ctx, so that they are not freed along with the HNB state,
possibly leaving SCCP connections afloat.
(It is still nice to normally keep context maps as talloc children of
their respective hnb_ctx, so talloc reports show which belongs to
which.)
So far, context map handling found the global hnb_gw pointer via
map->hnb_ctx->gw. But in fact, a HNB may disappear at any point in time.
Instead, use a separate hnb_gw pointer in map->gw.
== RUA procedure codes vs. SCCP prims ==
So far, the RUA rx side composed SCCP prims to pass on:
RUA rx ---SCCP-prim--> RANAP handling ---SCCP-prim--> SCCP tx
That is a source of confusion: a RUA procedure code should not translate
1:1 to SCCP prims, especially for RUA id-Disconnect (see release charts
below).
Instead, move SCCP prim composition over to the SCCP side, using FSM
events to forward:
RUA rx --event--> RUA FSM --event--> SCCP FSM --SCCP-prim--> SCCP tx
+RANAP +RANAP +RANAP
RUA tx <--RUA---- RUA FSM <--event-- SCCP FSM <--event-- SCCP rx
+RANAP +RANAP +RANAP
Hence choose the correct prim according to the SCCP FSM state.
- in hnbgw_rua.c, use RUA procedure codes, not prim types.
- via the new FSM events' data args, pass msgb containing RANAP PDUs.
== Fix SCCP Release behavior ==
So far, the normal conn release behavior was
HNB HNBGW CN
| --id-Disconnect--> | ---SCCP-Released--> | Iu-ReleaseComplete
| | <--SCCP-RLC-------- | (no data)
Instead, the SCCP release is now in accordance with 3GPP TS 48.006 9.2
'Connection release':
The MSC sends a SCCP released message. This message shall not contain
any user data field.
i.e.:
HNB HNBGW CN
| --id-Disconnect--> | ---Data-Form-1(!)--> | Iu-ReleaseComplete
| | <--SCCP-Released---- | (no data)
| | ---SCCP-RLC--------> | (no data)
(Side note, the final SCCP Release Confirm step is taken care of
implicitly by libosmo-sigtran's sccp_scoc.c FSM.)
If the CN fails to respond with SCCP-Released, on new X31 timeout,
osmo-hnbgw will send an SCCP Released to the CN as fallback.
== Memory model for message dispatch ==
So far, an osmo_scu_prim aka "oph" was passed between RUA and SCCP
handling code, and the final dispatch freed it. Every error path had to
take care not to leak any oph.
Instead, use a much easier and much more leakage proof memory model,
inspired by fixeria:
- on rx, dispatch RANAP msgb that live in OTC_SELECT.
- no code path needs to msgb_free() -- the msgb is discarded via
OTC_SELECT when handling is done, error or no error.
- any code path may also choose to store the msgb for async dispatch,
using talloc_steal(). The user plane mapping via MGW and UPF do that.
- if any code path does msgb_free(), that would be no problem either
(but none do so now, for simplicity).
== Layer separation ==
Dispatch *all* connection-oriented RUA tx via the RUA FSM and SCCP tx
via the SCCP FSM, do not call rua_tx_dt() or osmo_sccp_user_sap_down()
directly.
== Memory model for decoded ranap_message IEs ==
Use a talloc destructor to make sure that the ranap_message IEs are
always implicitly freed upon talloc_free(), so that no code path can
possibly forget to do so.
== Implicit cleanup by talloc ==
Use talloc scoping to remove a bunch of explicit cleanup code. For
example, make a chached message a talloc child of its handler:
talloc_steal(mgw_fsm_priv, message);
mgw_fsm_priv->ranap_rab_ass_req_message = message;
and later implicitly free 'message' by only freeing the handler:
talloc_free(mgw_fsm_priv)
Related: SYS#6297
Change-Id: I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
---
M include/osmocom/hnbgw/context_map.h
M include/osmocom/hnbgw/hnbgw.h
M include/osmocom/hnbgw/hnbgw_cn.h
M include/osmocom/hnbgw/mgw_fsm.h
M include/osmocom/hnbgw/ps_rab_ass_fsm.h
M include/osmocom/hnbgw/tdefs.h
M src/osmo-hnbgw/Makefile.am
M src/osmo-hnbgw/context_map.c
A src/osmo-hnbgw/context_map_rua.c
A src/osmo-hnbgw/context_map_sccp.c
M src/osmo-hnbgw/hnbgw.c
M src/osmo-hnbgw/hnbgw_cn.c
M src/osmo-hnbgw/hnbgw_rua.c
M src/osmo-hnbgw/hnbgw_vty.c
M src/osmo-hnbgw/mgw_fsm.c
M src/osmo-hnbgw/ps_rab_ass_fsm.c
M src/osmo-hnbgw/ps_rab_fsm.c
M src/osmo-hnbgw/tdefs.c
18 files changed, 1,397 insertions(+), 375 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-hnbgw refs/changes/31/31431/7
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/31431
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
Gerrit-Change-Number: 31431
Gerrit-PatchSet: 7
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-CC: msuraev <msuraev(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newpatchset
Attention is currently required from: pespin, msuraev, dexter.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/31415 )
Change subject: bts_features: Add features for HR formats (TS 101813 vs. RFC5993)
......................................................................
Patch Set 8:
(1 comment)
File include/osmocom/gsm/bts_features.h:
https://gerrit.osmocom.org/c/libosmocore/+/31415/comment/2dd6a3ed_ad8184c5
PS7, Line 39: _TX
> The BTS will accept both formats since it is easy to detect and convert from one to the other. […]
As I said, this is an implementation detail (converting between formats on the fly). The PHY of each particular BTS models still does emit/expect only a specific format.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/31415
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I05e4ed7a85f3a0451de7cd07380503a7ac76d043
Gerrit-Change-Number: 31415
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: msuraev <msuraev(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: msuraev <msuraev(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 24 Feb 2023 13:54:33 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: dexter <pmaier(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: fixeria, pespin, msuraev.
dexter has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/31415 )
Change subject: bts_features: Add features for HR formats (TS 101813 vs. RFC5993)
......................................................................
Patch Set 8:
(2 comments)
File include/osmocom/gsm/bts_features.h:
https://gerrit.osmocom.org/c/libosmocore/+/31415/comment/294d4ae9_9319f923
PS7, Line 39: _TX
> IMO, the '_TX_' part should be removed. […]
The BTS will accept both formats since it is easy to detect and convert from one to the other. So the BTS will not care. However the BTS will still transmit in one of the two formats. That why we opted to have a _TX_ in the name.
File src/gsm/bts_features.c:
https://gerrit.osmocom.org/c/libosmocore/+/31415/comment/5376aab1_a4b18fe7
PS7, Line 49: { BTS_FEAT_VBS, "Voice Broadcast Service" },
> That's a duplicate from the entry above.
Done
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/31415
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I05e4ed7a85f3a0451de7cd07380503a7ac76d043
Gerrit-Change-Number: 31415
Gerrit-PatchSet: 8
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: msuraev <msuraev(a)sysmocom.de>
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: msuraev <msuraev(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 24 Feb 2023 13:47:12 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: msuraev <msuraev(a)sysmocom.de>
Gerrit-MessageType: comment