Project

General

Profile

Bug #2939

TTCN3: Fix broken paging tests

Added by dexter 6 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/13/2018
Due date:
% Done:

100%

Estimated time:
Spec Reference:

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
osmo-bsc.cfg osmo-bsc.cfg 9.47 KB stsp, 02/13/2018 11:50 AM
result.log result.log 7.19 MB dexter, 02/26/2018 09:28 PM

History

#1 Updated by dexter 6 months ago

  • Status changed from New to Feedback
  • Assignee changed from dexter to stsp

#2 Updated by stsp 6 months ago

The tests are passing for me. I am attaching my osmo-bsc.cfg so you can check if it matches your test setup.

#3 Updated by laforge 6 months ago

  • Assignee changed from stsp to dexter

#4 Updated by dexter 6 months ago

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.

#5 Updated by dexter 6 months ago

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/

#6 Updated by dexter 5 months ago

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;

#7 Updated by laforge 5 months ago

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.

#8 Updated by laforge 5 months ago

  • 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

Add picture from clipboard (Maximum size: 48.8 MB)