Change in ...osmo-bsc[master]: remove double BSSMAP Clear on HO failure

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

neels gerrit-no-reply at lists.osmocom.org
Tue Jul 9 15:45:41 UTC 2019


neels has submitted this change and it was merged. ( https://gerrit.osmocom.org/c/osmo-bsc/+/14700 )

Change subject: remove double BSSMAP Clear on HO failure
......................................................................

remove double BSSMAP Clear on HO failure

If a handover fails when the new lchan is already fully established, osmo-bsc
so far caused two BSSMAP Clear Requests to be sent out to the MSC: one caused
by detaching the lchan from the gscon, one from returning the gscon back to
ST_ACTIVE, which detects that no lchan is present and Clears. In fact only one
of those is necessary.

Checking for the presence of an lchan when entering ST_ACTIVE is an earlier
attempt to catch insane situations. Since then, osmo-bsc has acquired other
logic that will ensure sending a Clear Request in all cases, see
gscon_forget_lchan(). Sending another BSSMAP Clear Request in ST_ACTIVE's
onenter is simply not necessary. Drop gscon_fsm_active_onenter() entirely.

Note: the double Clear Request is currently hit by
TC_ho_out_fail_no_ho_detect(), which currently fails and will pass again after
this patch; however, osmo-bsc should actually not release the lchan at all
during this test, see OS#4093. In other words, osmo-bsc behavior for this
scenario as well as TC_ho_out_fail_no_ho_detect() need to be changed, and the
test will, once fixed, not be useful to trigger this issue anymore.

Related: OS#4078
Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
---
M src/osmo-bsc/bsc_subscr_conn_fsm.c
1 file changed, 0 insertions(+), 8 deletions(-)

Approvals:
  laforge: Looks good to me, but someone else must approve
  neels: Looks good to me, approved
  osmith: Looks good to me, but someone else must approve
  Jenkins Builder: Verified



diff --git a/src/osmo-bsc/bsc_subscr_conn_fsm.c b/src/osmo-bsc/bsc_subscr_conn_fsm.c
index bc5cb27..f8784f9 100644
--- a/src/osmo-bsc/bsc_subscr_conn_fsm.c
+++ b/src/osmo-bsc/bsc_subscr_conn_fsm.c
@@ -343,13 +343,6 @@
 	}
 }
 
-static void gscon_fsm_active_onenter(struct osmo_fsm_inst *fi, uint32_t prev_state)
-{
-	struct gsm_subscriber_connection *conn = fi->priv;
-	if (!conn->lchan)
-		gscon_bssmap_clear(conn, GSM0808_CAUSE_EQUIPMENT_FAILURE);
-}
-
 /* We're on an active subscriber connection, passing DTAP back and forth */
 static void gscon_fsm_active(struct osmo_fsm_inst *fi, uint32_t event, void *data)
 {
@@ -605,7 +598,6 @@
 				 S(GSCON_EV_HANDOVER_START),
 		.out_state_mask = S(ST_CLEARING) | S(ST_ASSIGNMENT) |
 				  S(ST_HANDOVER),
-		.onenter = gscon_fsm_active_onenter,
 		.action = gscon_fsm_active,
 	},
 	[ST_ASSIGNMENT] = {

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/14700
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
Gerrit-Change-Number: 14700
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge at gnumonks.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: osmith <osmith at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190709/ed99e3a7/attachment.htm>


More information about the gerrit-log mailing list