bsc: clarify RESET logging: BSSMAP vs RANAP vs BSSMAP-LE
When a RESET-ACK times out, the logs currently are indistinguishable between
BSSMAP and BSSMAP-LE. Add protocol naming for each RESET / RESET-ACK logging to
make sure the information does not need guesswork.
Example of a test failure shown in jenkins:
BSC_Tests.TC_unsol_ass_compl
Stacktrace
Timeout waiting for RESET-ACK after sending RESET
BSC_Tests.ttcn:8295 BSC_Tests control part
BSC_Tests.ttcn:4274 TC_unsol_ass_compl testcase
Nothing conveys that it is (presumably) the background *BSSMAP-LE* timeout
halting the test 5 seconds in, and not an A-interface failure.
Change-Id: I874567e68b8279bf2460b9474241f0a9fe5ff0ff
diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn
index fff5c2c..9a5faa7 100644
--- a/bsc/BSC_Tests.ttcn
+++ b/bsc/BSC_Tests.ttcn
@@ -774,10 +774,10 @@
alt {
[] BSSAP.receive(tr_BSSAP_UNITDATA_ind(g_bssap[bssap_idx].sccp_addr_own, g_bssap[bssap_idx].sccp_addr_peer,
tr_BSSMAP_ResetAck(g_osmux_enabled))) {
- log("Received RESET-ACK in response to RESET, we're ready to go!");
+ log("BSSMAP: Received RESET-ACK in response to RESET, we're ready to go!");
}
[] BSSAP.receive(tr_BSSAP_UNITDATA_ind(?, ?, tr_BSSMAP_Reset(g_osmux_enabled))) -> value ud_ind {
- log("Respoding to inbound RESET with RESET-ACK");
+ log("BSSMAP: 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;
@@ -785,7 +785,7 @@
}
[] BSSAP.receive { repeat; }
[] T.timeout {
- log("Timeout waiting for RESET-ACK after sending RESET");
+ log("BSSMAP: 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