Bug #2939
closed
TTCN3: Fix broken paging tests
Added by dexter about 6 years ago.
Updated about 6 years ago.
Description
Many of the paging tests still fail. The result is the same for pmaier/fsm and for current master. Also the jenkins shows a very similar picture.
#BSC_Tests.TC_paging_imsi_nochan # Pass
#BSC_Tests.TC_paging_tmsi_nochan # Fail
#BSC_Tests.TC_paging_tmsi_any # Fail
#BSC_Tests.TC_paging_tmsi_sdcch # Fail
#BSC_Tests.TC_paging_tmsi_tch_f # Fail
#BSC_Tests.TC_paging_tmsi_tch_hf # Fail
#BSC_Tests.TC_paging_imsi_nochan_cgi # Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_ci # Pass
#BSC_Tests.TC_paging_imsi_nochan_ci # Pass
#BSC_Tests.TC_paging_imsi_nochan_lai # Fail
#BSC_Tests.TC_paging_imsi_nochan_lac # Fail
#BSC_Tests.TC_paging_imsi_nochan_all # Pass
#BSC_Tests.TC_paging_imsi_a_reset # Fail
#BSC_Tests.TC_paging_imsi_load # Fail
#BSC_Tests.TC_paging_counter # Fail
#BSC_Tests.TC_rsl_drop_counter # Pass
Files
- Status changed from New to Feedback
- Assignee changed from dexter to stsp
The tests are passing for me. I am attaching my osmo-bsc.cfg so you can check if it matches your test setup.
- Assignee changed from stsp to dexter
Aktueller Status:
#BSC_Tests.TC_paging_imsi_nochan #Pass
#BSC_Tests.TC_paging_tmsi_nochan #Error
#BSC_Tests.TC_paging_tmsi_any #Fail
#BSC_Tests.TC_paging_tmsi_sdcch #Fail
#BSC_Tests.TC_paging_tmsi_tch_f #Fail
#BSC_Tests.TC_paging_tmsi_tch_hf #Fail
#BSC_Tests.TC_paging_imsi_nochan_cgi #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_ci #Pass
#BSC_Tests.TC_paging_imsi_nochan_ci #Pass
#BSC_Tests.TC_paging_imsi_nochan_lai #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac #Pass
#BSC_Tests.TC_paging_imsi_nochan_all #Pass
#BSC_Tests.TC_paging_imsi_nochan_plmn_lac_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_lacs #Pass
#BSC_Tests.TC_paging_imsi_nochan_lacs_empty #Pass
#BSC_Tests.TC_paging_imsi_a_reset #Fail
#BSC_Tests.TC_paging_imsi_load #Fail
#BSC_Tests.TC_paging_counter #Fail
The case statement at the bottom of src/osmo-bsc/osmo_bsc_bssap.c:bssmap_handle_paging() seems to be problematic. In case of CELL_IDENT_NO_CELL the request is dropped but according to TC_paging_tmsi_nochan it should trigger a paging anyway, while at the same time TC_paging_imsi_nochan is expected to trigger no paging at all. The TMSI field is not mandatory, I do not get why this is an illegal case.
I have checked what happens on BSSMAP reset. Ongoing paging requests are indeed stopped. In osmo_bsc_bssmap.c:bssmap_handle_reset() paging_flush_network() is called.
Unfortunately my TTCN3 testsuit broke today for unknown reason.
The TTCN3 testsuit runs fine at the moment. This is what I get at the moment:
#BSC_Tests.TC_paging_imsi_nochan #Pass
#BSC_Tests.TC_paging_tmsi_nochan #Pass
#BSC_Tests.TC_paging_tmsi_any #Pass
#BSC_Tests.TC_paging_tmsi_sdcch #Pass
#BSC_Tests.TC_paging_tmsi_tch_f #Pass
#BSC_Tests.TC_paging_tmsi_tch_hf #Pass
#BSC_Tests.TC_paging_imsi_nochan_cgi #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_ci #Pass
#BSC_Tests.TC_paging_imsi_nochan_ci #Pass
#BSC_Tests.TC_paging_imsi_nochan_lai #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac #Pass
#BSC_Tests.TC_paging_imsi_nochan_all #Pass
#BSC_Tests.TC_paging_imsi_nochan_plmn_lac_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_rnc #Pass
#BSC_Tests.TC_paging_imsi_nochan_lacs #Pass
#BSC_Tests.TC_paging_imsi_nochan_lacs_empty #Pass
#BSC_Tests.TC_paging_imsi_a_reset #Pass
#BSC_Tests.TC_paging_imsi_load #Fail
#BSC_Tests.TC_paging_counter #Pass
Unfortunately this is an optimistic view, we still have the problem that some tests fail when executed shortly one after another. I get the following strange error message on the TTCN3 output:
IPA0-RSL-IPA(42)@lobotron: Dynamic test case error: Port IPA_RSL_PORT has neither connections nor mappings. Message cannot be sent on it. (Operation now in progress)
(I have attached the full log to this ticket)
The following patches related to paging are still in review:
https://gerrit.osmocom.org/#/c/6860/
https://gerrit.osmocom.org/#/c/6848/
From the debugging perspective there is only TC_paging_imsi_load left now. The problem here is that the BSC happily continues to send paging requets, even when the BTS sends paging channel load messages. So far this is a real bug and not a problem with the testsuit.
The testsuit still suffers from intermittent failurs. The source of the problem are race conditions inside the testsuit. We thought there were some simple best practice to resolve this, but apparently there is not. To resolve this we need to build up some synchronization logic that goes though the whole testsuit. (see also https://www.eclipse.org/forums/index.php/t/1091986/)
I personally think we should rollback to the shutdown function we had before:
private function f_shutdown_helper() runs on test_CT {
var integer i;
/* Make sure all IPA_Emulation instances are stopped */
for (i := 0; i < sizeof(bts); i := i + 1) {
bts[i].rsl.vc_IPA.stop;
}
/* Make sure the Osmocom_CTRL_Adapter is stopped */
vc_CTRL_IPA.stop;
setverdict(pass);
}
This one seemed to make the tests more stable than the approach with all port.stop;
On Mon, Mar 05, 2018 at 05:31:44PM +0000, dexter [REDMINE] wrote:
I personally think we should rollback to the shutdown function we had before:
works for me. One can also stop other "outside-facing" components at the same time,
too. I think the number of messages generated inside the components without an external
message arriving is quite low (e.g. SCCP timer expiration), and hence the chance of
races low. So if we stop all components that deal with outside TCP/IP/SCTP connections (IPA,
GSUP, GTP, M3UA, ...) first we should be on the safe side.
- Status changed from Feedback to Resolved
- Assignee changed from dexter to laforge
- % Done changed from 0 to 100
the shutdown function has been extended to stop CTRL and all RSL components after which the paging tests work more reliably. The related Change-Id is I23932927bd6bb9b5e447acbeafc2748a77513a0d
Also available in: Atom
PDF