diff options
| author | Pau Espin Pedrol <pespin@sysmocom.de> | 2020-09-01 12:54:12 +0200 |
|---|---|---|
| committer | pespin <pespin@sysmocom.de> | 2020-09-09 16:50:53 +0000 |
| commit | 24c0599541a321547b10fbd1a0f57fc9d414e082 (patch) | |
| tree | 01150cc13c0c28f408f650b07c3f06bfeca9aa95 | |
| parent | db2dc0494eda03880551013001073a71f539634f (diff) | |
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
| -rw-r--r-- | bsc/BSC_Tests.ttcn | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn index d32f2026..4c450287 100644 --- a/bsc/BSC_Tests.ttcn +++ b/bsc/BSC_Tests.ttcn @@ -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); + } + } } } |