Attention is currently required from: pespin.
lynxis lazus has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/libosmocore/+/39062?usp=email )
Change subject: Gb/NS: SNS: SNS Ack don't add List of IP4/6 Elements on success.
......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/libosmocore/+/39062/comment/0262c9f0_3bec5e36?… :
PS1, Line 7: Gb/NS: SNS: SNS Ack don't add List of IP4/6 Elements on success.
> why?
I'll improve the commit message more.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/39062?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: If99b204a9d754323e53746b31bc13df53a653b7d
Gerrit-Change-Number: 39062
Gerrit-PatchSet: 1
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Dec 2024 15:18:59 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria, pespin.
Hello Jenkins Builder, pespin,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Code-Review+1 by pespin, Verified+1 by Jenkins Builder
Change subject: s1ap_proxy: handle_ies(): pass IEI path to handle_ie()
......................................................................
s1ap_proxy: handle_ies(): pass IEI path to handle_ie()
This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP.
We need to be able to match the IEs unambiguously, because the same
IEI may be used in different contexts and thus have different meaning,
sometimes within the same PDU. The E-RABItem IE is such an example:
* 9.1.3.5 E-RAB RELEASE COMMAND
** contains an E-RABToBeReleasedList IE
*** contains E-RABItem IEs
* 9.1.3.7 E-RAB RELEASE INDICATION
** contains an E-RABReleasedList IE
*** contains E-RABItem IEs
So far we handled this duality by passing the release kind via
the #proxy_state record ('rel_kind' field) and it worked. But
soon in follow-up changes we'll have to deal with other PDUs:
* 9.1.3.4 E-RAB MODIFY RESPONSE
** contains an E-RABModifyListBearerModRes IE
** may contain an E-RABFailedToModifyList IE
*** contains E-RABItem IEs
* 9.1.3.9 E-RAB MODIFICATION CONFIRM
** may contain an E-RABFailedToModifyList IE
*** contains E-RABItem IEs
** may contain an E-RABToBeReleased IE
*** contains E-RABItem IEs
A universal approach allowing to match and handle IEs properly
depending on the context is to maintain the full IEI path
in handle_ies() and pass it to handle_ie().
Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530
---
M src/s1ap_proxy.erl
1 file changed, 59 insertions(+), 38 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/erlang/osmo-s1gw refs/changes/13/39113/2
--
To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newpatchset
Gerrit-Project: erlang/osmo-s1gw
Gerrit-Branch: master
Gerrit-Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530
Gerrit-Change-Number: 39113
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email )
Change subject: s1ap_proxy: handle_ies(): pass IEI path to handle_ie()
......................................................................
Patch Set 1:
(1 comment)
File src/s1ap_proxy.erl:
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113/comment/8ca133a2_ed36… :
PS1, Line 395: when P :: [s1ap_ie_id()], %% Path
> I am fine with renaming the actual params (will update this patch), but only for the `-spec`. […]
Acknowledged
--
To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: erlang/osmo-s1gw
Gerrit-Branch: master
Gerrit-Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530
Gerrit-Change-Number: 39113
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Dec 2024 14:42:48 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: pespin.
fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email )
Change subject: s1ap_proxy: handle_ies(): pass IEI path to handle_ie()
......................................................................
Patch Set 1:
(2 comments)
File src/s1ap_proxy.erl:
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113/comment/799b51ca_0391… :
PS1, Line 122: path = []}}.
> btw iirc you can set the default values for a type when you declare it (line 71)
Yes, this can be done. But I think it's also fine having the initial state fully and explicitly initialized (fields that are not `undefined`) here in one place.
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113/comment/549849a8_8229… :
PS1, Line 395: when P :: [s1ap_ie_id()], %% Path
> why not simply renaming the params instead of adding comments? lol
I am fine with renaming the actual params (will update this patch), but only for the `-spec`. For the actual functions below I prefer using short, single letter variable names because we're dealing with rather long ASN.1 identifiers and nested records.
--
To view, visit https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/39113?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: erlang/osmo-s1gw
Gerrit-Branch: master
Gerrit-Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530
Gerrit-Change-Number: 39113
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Dec 2024 14:31:46 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/39119?usp=email )
Change subject: map_sccp: Fix crash during ev MAP_SCCP_EV_RAN_DISC in st MAP_SCCP_ST_WAIT_CC
......................................................................
map_sccp: Fix crash during ev MAP_SCCP_EV_RAN_DISC in st MAP_SCCP_ST_WAIT_CC
Recent commit changed event MAP_SCCP_EV_RAN_DISC to have a bool
parameter instead of a msgb pointer, however only code in state
MAP_SCCP_ST_CONNECTED was updated to account for the change; other
states were left checking the data ptr as if it was a msgb and crashed
while accessing mem address 0x1 (bool true) in msg_has_l2_data().
Fixes: 79589556244bf9cea6e8de8793a611f16e9052cd
Related: SYS#7208
Change-Id: If53dbd6b5a8abffcf94e6d666209954f17e9f9d7
---
M src/osmo-hnbgw/context_map_sccp.c
1 file changed, 29 insertions(+), 7 deletions(-)
Approvals:
laforge: Looks good to me, approved
Jenkins Builder: Verified
osmith: Looks good to me, but someone else must approve
diff --git a/src/osmo-hnbgw/context_map_sccp.c b/src/osmo-hnbgw/context_map_sccp.c
index b39768d..c933e8d 100644
--- a/src/osmo-hnbgw/context_map_sccp.c
+++ b/src/osmo-hnbgw/context_map_sccp.c
@@ -265,11 +265,12 @@
static void map_sccp_init_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
struct hnbgw_context_map *map = fi->priv;
- struct msgb *ranap_msg = data;
+ struct msgb *ranap_msg = NULL;
switch (event) {
case MAP_SCCP_EV_TX_DATA_REQUEST:
+ ranap_msg = data;
/* In the INIT state, the first MAP_SCCP_EV_TX_DATA_REQUEST will be the RANAP message received from the
* RUA Connect message. Send the SCCP CR and transition to WAIT_CC. */
if (tx_sccp_cr(fi, ranap_msg) == 0)
@@ -277,15 +278,22 @@
return;
case MAP_SCCP_EV_RAN_LINK_LOST:
- case MAP_SCCP_EV_RAN_DISC:
case MAP_SCCP_EV_USER_ABORT:
case MAP_SCCP_EV_CN_LINK_LOST:
+ ranap_msg = data;
/* No CR has been sent yet, just go to disconnected state. */
if (msg_has_l2_data(ranap_msg))
LOG_MAP(map, DLSCCP, LOGL_ERROR, "SCCP not connected, cannot dispatch RANAP message\n");
map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
return;
+ case MAP_SCCP_EV_RAN_DISC:
+ /* bool rua_disconnect_err_condition = !!data; */
+ /* 3GPP TS 25.468 9.1.5: RUA has disconnected.
+ * In this state we didn't send an SCCP CR yet, so nothing to be torn down on CN side. */
+ map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
+ return;
+
case MAP_SCCP_EV_RX_RELEASED:
/* SCCP RLSD received from CN. This will never happen since we haven't even asked for a connection, but
* for completeness: */
@@ -300,31 +308,41 @@
static void map_sccp_wait_cc_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
struct hnbgw_context_map *map = fi->priv;
- struct msgb *ranap_msg = data;
+ struct msgb *ranap_msg = NULL;
switch (event) {
case MAP_SCCP_EV_RX_CONNECTION_CONFIRM:
+ ranap_msg = data;
map_sccp_fsm_state_chg(MAP_SCCP_ST_CONNECTED);
/* Usually doesn't but if the SCCP CC contained data, forward it to RUA */
handle_rx_sccp(fi, ranap_msg);
return;
case MAP_SCCP_EV_TX_DATA_REQUEST:
+ /* ranap_msg = data; */
LOGPFSML(fi, LOGL_ERROR, "Connection not yet confirmed, cannot forward RANAP to CN\n");
return;
case MAP_SCCP_EV_RAN_LINK_LOST:
- case MAP_SCCP_EV_RAN_DISC:
case MAP_SCCP_EV_USER_ABORT:
case MAP_SCCP_EV_CN_LINK_LOST:
+ ranap_msg = data;
/* RUA connection was terminated. First wait for the CC before releasing the SCCP conn. */
if (msg_has_l2_data(ranap_msg))
LOGPFSML(fi, LOGL_ERROR, "Connection not yet confirmed, cannot forward RANAP to CN\n");
map->please_disconnect = true;
return;
+ case MAP_SCCP_EV_RAN_DISC:
+ /* bool rua_disconnect_err_condition = !!data; */
+ /* 3GPP TS 25.468 9.1.5: RUA has disconnected.
+ * In this state we didn't send an SCCP CR yet, so nothing to be torn down on CN side. */
+ map->please_disconnect = true;
+ return;
+
case MAP_SCCP_EV_RX_RELEASED:
+ ranap_msg = data;
/* SCCP RLSD received from CN. This will never happen since we haven't even received a Connection
* Confirmed, but for completeness: */
handle_rx_sccp(fi, ranap_msg);
@@ -349,7 +367,7 @@
static void map_sccp_connected_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
- struct msgb *ranap_msg;
+ struct msgb *ranap_msg = NULL;
bool rua_disconnect_err_condition;
switch (event) {
@@ -432,11 +450,12 @@
static void map_sccp_wait_rlsd_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
- struct msgb *ranap_msg = data;
+ struct msgb *ranap_msg = NULL;
switch (event) {
case MAP_SCCP_EV_RX_RELEASED:
+ ranap_msg = data;
/* The CN sends the expected SCCP RLSD.
* Usually there is no data, but if there is just forward it.
* Usually RUA is already disconnected, but let the RUA FSM decide about that. */
@@ -445,12 +464,13 @@
return;
case MAP_SCCP_EV_RX_DATA_INDICATION:
+ ranap_msg = data;
/* RUA is probably already disconnected, but let the RUA FSM decide about that. */
handle_rx_sccp(fi, ranap_msg);
return;
case MAP_SCCP_EV_TX_DATA_REQUEST:
- case MAP_SCCP_EV_RAN_DISC:
+ ranap_msg = data;
/* Normally, RUA would already disconnected, but since SCCP is officially still connected, we can still
* forward messages there. Already waiting for CN to send the SCCP RLSD. If there is a message, forward
* it, and just continue to time out on the SCCP RLSD. */
@@ -458,6 +478,7 @@
return;
case MAP_SCCP_EV_RX_CONNECTION_CONFIRM:
+ ranap_msg = data;
/* Already connected. Unusual, but if there is data just forward it. */
LOGPFSML(fi, LOGL_ERROR, "Already connected, but received SCCP CC\n");
handle_rx_sccp(fi, ranap_msg);
@@ -466,6 +487,7 @@
case MAP_SCCP_EV_RAN_LINK_LOST:
case MAP_SCCP_EV_USER_ABORT:
case MAP_SCCP_EV_CN_LINK_LOST:
+ case MAP_SCCP_EV_RAN_DISC:
/* Stop waiting for RLSD, send RLSD now. */
tx_sccp_rlsd(fi);
map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/39119?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: merged
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: If53dbd6b5a8abffcf94e6d666209954f17e9f9d7
Gerrit-Change-Number: 39119
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Attention is currently required from: pespin.
laforge has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/39119?usp=email )
Change subject: map_sccp: Fix crash during ev MAP_SCCP_EV_RAN_DISC in st MAP_SCCP_ST_WAIT_CC
......................................................................
Patch Set 2: Code-Review+2
--
To view, visit https://gerrit.osmocom.org/c/osmo-hnbgw/+/39119?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: osmo-hnbgw
Gerrit-Branch: master
Gerrit-Change-Id: If53dbd6b5a8abffcf94e6d666209954f17e9f9d7
Gerrit-Change-Number: 39119
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 11 Dec 2024 14:03:25 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes