Change in osmo-ttcn3-hacks[master]: bsc: Fix race condition waiting for RESET-ACK

[pespin]

pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19930 )

Change subject: bsc: Fix race condition waiting for RESET-ACK
......................................................................

bsc: Fix race condition waiting for RESET-ACK

This scenario appeared in jenkins runs of BSC_Tests making
TC_ctrl_msc_connection_status fail (the first test in the suite). I
could however not reproduce it on my local docker setup because it
really seems like a timing race condition.

The scenario is:
TTCN3 -> BSC: RESET
TTCN3 <- BSC: RESET
TTCN3 -> BSC: RESET-ACK

In there, TTCN3's f_legacy_bssap_reset() expected a RESET-ACK to be
received, but it may well be that the other end never saw the RESET and
hence it will never sent the RESET-ACK, since it indicated it became
available afterwards. In that case (RESET received), let's not fail if a
RESET-ACK is never received, since the connection is actually in the
desired state and this scenario can happen and it's all fine.

Change-Id: Ic92e0fb7033e5134b66e485a11371394adaba78a
---
M bsc/BSC_Tests.ttcn
1 file changed, 12 insertions(+), 1 deletion(-)

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



diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn
index d32f202..4c45028 100644
--- a/bsc/BSC_Tests.ttcn
+++ b/bsc/BSC_Tests.ttcn
@@ -744,6 +744,7 @@
 
 private function f_legacy_bssap_reset(integer bssap_idx := 0) runs on test_CT {
 	var BSSAP_N_UNITDATA_ind ud_ind;
+	var boolean reset_received := false;
 	timer T := 5.0;
 	BSSAP.send(ts_BSSAP_UNITDATA_req(g_bssap[bssap_idx].sccp_addr_peer, g_bssap[bssap_idx].sccp_addr_own,
 					 ts_BSSMAP_Reset(0, g_osmux_enabled)));
@@ -757,10 +758,20 @@
 		log("Respoding to inbound RESET with RESET-ACK");
 		BSSAP.send(ts_BSSAP_UNITDATA_req(ud_ind.callingAddress, ud_ind.calledAddress,
 			   ts_BSSMAP_ResetAck(g_osmux_enabled)));
+		reset_received := true;
 		repeat;
 		}
 	[] BSSAP.receive { repeat; }
-	[] T.timeout { setverdict(fail, "Waiting for RESET-ACK after sending RESET"); }
+	[] T.timeout {
+			log("Timeout waiting for RESET-ACK after sending RESET");
+			/* If we received a RESET after ours was sent, it
+			   may be a race condition where the other peer beacame
+			   available after we sent it, but we are in a desired
+			   state anyway, so go forward. */
+			if (not reset_received) {
+				setverdict(fail);
+			}
+		}
 	}
 }
 

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

Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: Ic92e0fb7033e5134b66e485a11371394adaba78a
Gerrit-Change-Number: 19930
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200909/688c6fed/attachment.htm>