ttcn3
/
osmo-ttcn3-hacks
mirror of https://gerrit.osmocom.org/osmo-ttcn3-hacks
10
0
Fork 1
Code Issues Releases Wiki Activity

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
This commit is contained in:
Pau Espin 2020-09-01 12:54:12 +02:00 committed by pespin
parent db2dc0494e
commit 24c0599541
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
bsc/BSC_Tests.ttcn
View File

@ -744,6 +744,7 @@ private function f_shutdown_helper() runs on test_CT {
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 @@ private function f_legacy_bssap_reset(integer bssap_idx := 0) runs on test_CT {
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);
}
}
}
}