Review at  https://gerrit.osmocom.org/7223

bsc: add TC_bssap_rlsd_does_not_cause_bssmap_reset

A test with BSSMAP Clear involved would also be a nice addition, but this so
far tests a direct RLSD from the MSC.

(One way to invoke a typical release situation would be a scenario like in
TC_chan_rel_rll_rel_ind(), but that test currently fails; another would be to
directly invoke a BSSMAP Clear from the MSC first.)

Related: OS#3041
Change-Id: I168cf240383485a5ffbbde377b4f89c5d1f5ab93
---
M bsc/BSC_Tests.ttcn
1 file changed, 48 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks 
refs/changes/23/7223/1

diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn
index d8ca374..71d1b51 100644
--- a/bsc/BSC_Tests.ttcn
+++ b/bsc/BSC_Tests.ttcn
@@ -236,6 +236,13 @@
                }
 }
 
+altstep no_bssmap_reset() runs on test_CT {
+       [] BSSAP.receive(tr_BSSAP_UNITDATA_ind(?, ?, tr_BSSMAP_Reset)) {
+               setverdict(fail, "unexpected BSSMAP Reset");
+               self.stop;
+       }
+}
+
 function f_init_mgcp(charstring id) runs on test_CT {
        id := id & "-MGCP";
 
@@ -1697,6 +1704,45 @@
        vc_conn.done;
 }
 
+/* OS#3041: Open and close N connections in a normal fashion, and expect no
+ * BSSMAP Reset just because of that. */
+testcase TC_bssap_rlsd_does_not_cause_bssmap_reset() runs on test_CT {
+       var default d;
+       var integer i;
+       var DchanTuple dt;
+
+       f_init();
+
+       /* Wait for initial BSSMAP Reset to pass */
+       f_sleep(4.0);
+
+       d := activate(no_bssmap_reset());
+
+       /* Setup up a number of connections and RLSD them again from the MSC
+        * side. In the buggy behavior, the fourth one triggers BSSMAP Reset.
+        * Let's do it some more times for good measure. */
+       for (i := 0; i < 8; i := i+1) {
+               /* Since we're doing a lot of runs, give each one a fresh
+                * T_guard from the top. */
+               T_guard.start;
+
+               /* Setup a BSSAP connection and clear it right away. This is
+                * the MSC telling the BSC about a planned release, it's not an
+                * erratic loss of a connection. */
+               dt := f_est_dchan('23'O, 23, '00010203040506'O);
+
+               /* MSC disconnects (RLSD). */
+               BSSAP.send(ts_BSSAP_DISC_req(dt.sccp_conn_id, 0));
+       }
+
+       /* In the buggy behavior, a timeout of 2 seconds happens between above
+        * trigger (logs "SIGTRAN connection down, reconnecting...") and the
+        * actual BSSMAP Reset. Wait a bit longer just to make sure. */
+       f_sleep(4.0);
+
+       deactivate(d);
+       f_shutdown_helper();
+}
 
 control {
        /* CTRL interface testing */
@@ -1771,6 +1817,8 @@
        execute( TC_err_82_short_msg() );
        execute( TC_err_84_unknown_msg() );
        execute( TC_ho_int() );
+
+       execute( TC_bssap_rlsd_does_not_cause_bssmap_reset() );
 }
 
 }

-- 
To view, visit https://gerrit.osmocom.org/7223
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I168cf240383485a5ffbbde377b4f89c5d1f5ab93
Gerrit-PatchSet: 1
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofm...@sysmocom.de>

Reply via email to