I have tried to pinpoint the problem. Unfortunately I can not exactly say what it is. The problem is reproducible with docker, but not with my normal setup on my workstation. When I add an f_sleep(10) at the beginning of TC_cr_before_reset() the testcase passes.
In the build artifacts (MSC_Tests.TC_cr_before_reset.pcap) I see only the messages from TTCN3, but not from the MSC, but in osmo-msc.log I can see that the MSC receives the messages from TTCN3 correctly. I can see the connection attempt and the BSSMAP RESET. Also the log says that the BSSMAP RESET ACK is sent out.
Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface.c:138 The calling BSC (RI=SSN_PC,PC=0.24.1,SSN=BSSAP) is unknown to this MSC ...
Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface.c:457 Adding new BSC connection for BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP...
Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface_bssap.c:110 Rx BSSMAP RESET from BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP, sending RESET ACK
To me this looks like a race condition that causes a communication problem between MSC and TTCN3. However, I am really confused to see messages arriving at the MSC because when I check the trace (without_f_sleep.pcapng) I see only the messages from TTCN3 to the STP, but do not see any egress messages going from the STP to the MSC. With the f_sleep(10) the trace looks normal (with_f_sleep.pcapng).
Note: We do not expect the MSC to respond to the CR with an BSSMAP RESET since the BSSMAP RESET from TTCN3 arrives so quickly at the RESET FSM inside the MSC does not get to the point where it sends its BSSMAP RESET. This is fine so far.
