On the first TCH, establish Layer 3 so that the BSC will issue a Clear
Request at all.
Verify the cause value of the Clear Request.
Tear down the established Layer 3: clean up for the leak check.
Related: OS#5535
Depends: I20108f7b4769400b89b7b0d65c8dab883bf87c46 (osmo-bsc)
Change-Id: Ib13be73119cfc96712f32899c02e655e1751d547
Rename chan_nr to first_tch, and more clearly show that the TCH that is
released gets assigned to the emergency call.
Related: OS#5534
Change-Id: I0c540d76eedfd4115b410921bf5a0b6c2d00b5c2
Deactivate as_Media() once the handover is completed, so that it does
not fail on the expected MGCP DLCX from release.
Fix fallout seen in these tests:
SCCPlite
BSC_Tests.TC_ho_into_this_bsc
BSC_Tests.TC_ho_into_this_bsc_a5_0
BSC_Tests.TC_ho_into_this_bsc_a5_1
BSC_Tests.TC_ho_into_this_bsc_a5_3
BSC_Tests.TC_ho_into_this_bsc_a5_4
BSC_Tests.TC_ho_into_this_bsc_a5_1_3_no_chosen_enc_alg
BSC_Tests.TC_ho_into_this_bsc_a5_1_3
BSC_Tests.TC_srvcc_eutran_to_geran
BSC_Tests.TC_srvcc_eutran_to_geran_a5_3
BSC_Tests.TC_srvcc_eutran_to_geran_src_sai
BSC_Tests.TC_srvcc_eutran_to_geran_forbid_fast_return
BSC_Tests.TC_ho_into_this_bsc_sccp_cr_without_bssap
All of these tests use f_ho_into_this_bsc().
(It is not clear to me why only the SCCPlite tests show the fallout, the
AoIP should be similarly affected, but isn't.)
The failures were introduced by recent merge of
I0633f60f09d58802f6be0238ef41a632d93a4327, which made as_Media()
stricter by failing on early DLCX.
Related: SYS#5916
Change-Id: Ic5650a48eb3d90f2b42f16685178c97b54473429
An emergency call often comes with a Location Request. Make sure
osmo-bsc handles it well.
Related: SYS#5916
Change-Id: I95037374c45943cb14401bc48f16a39c2fcbe1f5
as_Media_mgw() is used to establish a voice stream. If a DLCX happens as
part of that, that should be flagged as a problem.
In fact the Mode Modify test with current osmo-bsc does exhibit a DLCX
right upon the Assignment Complete message, which is a bug fixed in
I5ab10ee7fd9c5d7608e8a06893881d990943feed.
This patch now correctly flags this as a failure.
In the two tests
TC_ho_in_fail_no_detect, TC_ho_in_fail_no_detect2
the expected failure causes expected DLCX, so exempt those.
Related: SYS#5916
Change-Id: I0633f60f09d58802f6be0238ef41a632d93a4327
Using a guard statement makes no sense given that we match the
cellSelectionIndicatorValue conditionally within the alt branch
itself. Removing that guard statement eliminates the need to
have an additional alt branch with identical body.
Change-Id: I373376637a083637ce01f3ac59fe5fd2836ac6cd
RR Cause is a mandatory IE, so it cannot be omitted. Therefore it
makes no sense to check if istemplatekind(expect_rr_cause, "omit").
Change-Id: I564d00a4715b86d248bce449d2b9193ac5e99008
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
In f_ho_into_this_bsc(), check presence and correctness of the Cipher
Mode Setting IE. Add TC_srvcc_eutran_to_geran_a5_3, which is similar
to TC_srvcc_eutran_to_geran, but enables ciphering on the target channel.
This patch makes all SRVCC relates test cases fail, until [1] is merged.
Change-Id: Ic3dfc4e31a7ed078cdfdaced9986ee9551c5aa7c
Related: [1] osmo-bsc.git I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
Due to a bug in the current osmo-bsc master, osmo-bsc inverts
the band indicator bit in SI6 Rest Octets. This change extends
testing coverage to demonstrate the problem (see TC_si_default).
Change-Id: I93e1fcfaea973ec2461e30f656d5f5f0d829909b
Related: osmo-bsc.git Iaa8377919a144e7f3799b76249f579c8f3874145
So far, osmo-bsc ignored the Codec List (MSC Preferred) in inter-BSC
incoming HO Request messages. Starting with osmo-bsc
I117cc29d6d11db77d160de654f43f5993db6ee21, a missing codec list on AoIP
causes incoming inter-BSC HO to fail, as it should (3GPP TS 48.008
indicates that a codec list shall be included on AoIP). To avoid test
fallout when merging above osmo-bsc patch, add a codec list to HO
Request on AoIP.
Related: OS#5839
Change-Id: If06de9c9b43d79f749447a4e2a340176eef75c79
Test inter-BSC incoming HO where the Handover Request message is not
included in the initial SCCP N-Connect, but follows in a separate DT1.
Related: SYS#5864
Depends: I535c791fa01e99a2226392eb05f676ba6c3cc16e (osmo-bsc)
Change-Id: I6732153cdd0d529bfaf0925387e765f3403a756b
Since I just fixed the encryption behavior, I also want to know whether
the case of no A5 intersection is handled properly.
The tiny test comes with a lot of changes to allow a handover failure
code path. The 'expect_ho_fail' flag goes via function arguments to
g_pars and the general ho test code uses it to branch for exp-failure.
Related: SYS#5839
Change-Id: I44b464a0bedbff09c467c4bccd7c985480fb883a
Expect IEs Speech Codec (Chosen) and Codec List (BSS Supported), they
are missing in current osmo-bsc.
Related: SYS#5839
Depends: I3c0576505a3ceb3cd5cc31dc69c5bc4a86a4ea08 (osmo-bsc)
Change-Id: Ib2b4e27be241e2a92c0c3bffdf906bf22c09352b
This test should be failing as it is, because A5/4 is not permitted in
the BSC's configuration! It only passed all this time because osmo-bsc
is/was/is going to have been flawed and just takes the Chosen Encryption
Algorithm IE as the basis for choosing an encryption algorithm. Instead
it should intersect the pemitted algos with the BSC config. It will soon
do that, and then this test would fail as it should have. After fixing
the BSC config for the test with this patch, we'll not see it failing in
the transition.
Related: SYS#5839
Change-Id: Ic6bbbeea36e6ea26d16bbb510fd08f5c0defb955
Report: in inter-BSC incoming handover, when the MSC omits the Chosen
Encryption Algorithm IE in the Handover Request message, then osmo-bsc
starts an unencrypted lchan even if A5/0 is not permitted.
This test verifies that the Encryption Information is present in the
Channel Activation when the Chosen Enc Alg is omitted.
Related: SYS#5839
Change-Id: Ia94cc29bf66339ed782cb5101f3640f69cf73131
Clean up: absorb pars.encr_exp_enc_alg into TestHdlrEncrParams as
pars.encr.alg_expect.
Remove the automagic encr alg choice from test procedures, instead put
all magic in the pars.encr configuration setup; like this all encr alg
values remain fixed through the tests, less confusing.
Add separate alg_chosen for BSSMAP: So far, we have only one algorithm
field for both the mask of permitted algorithms in the Encryption
Information IS and the Chosen Encryption Algorithm IE. However, in the
Chosen Enc Alg there must be only one bit set. Thus we cannot easily run
a test where more than one alg is permitted and where the BSSMAP Chosen
Enc Alg IE is involved.
We've recently come to realize that the Chosen Encryption Algorithm IE
may also be omitted from BSSMAP messages, in which case osmo-bsc should
still work. To be able to test BSSMAP messages with omitted Chosen
Encryption Algorithm, allow to set alg_chosen == omit.
Keep t_EncrParams() in a way that all current tests (that set only one
bit in alg_permitted) still run the same as they always did.
Add t_EncrParams2() for a proper template.
Add a convenience function to configure encryption testing.
Related: SYS#5839
Change-Id: I6590ecf4a146dbed494d9d72f5a79441877e9010
This parameter allows to enable/disable checking of the IUT's talloc
report in f_shutdown_helper(). This may be useful when running the
test suite against '-latest' with unfixed memory leaks.
Change-Id: Ic7bf8d9def21083ebda1b94659d72dde2bb5e664
Three tests fail after recent patch
"bsc: properly clean up conn after each test"
I9396efcabc085d2850244c6468b83c5f3a3ff3a2
In TC_assignment_emerg_setup_deny_bts(), do not expect an RR Rel.
In TC_assignment_emerg_setup_deny_msc() and TC_cm_reestablishment(),
drop the additional f_expect_dlcx_conns().
Related: OS#5337
Change-Id: I1d1d27f0927e640a430b24c6dc3d5d851a5c4cb9
Make all tests clean up BSSAP conn and RSL link. Now all
f_verify_talloc_count() in f_shutdown_helper() should pass, verifying no
conn or bsc_subscr leaks.
Related: OS#5337
Change-Id: I9396efcabc085d2850244c6468b83c5f3a3ff3a2
ACK any MGCP DLCX or RLL REL REQ during f_perform_clear(), which makes
it more universally applicable to invoke at the end of a test.
Related: OS#5337
Change-Id: Ie5b77c266a5d8f47edd187c474df281a799a81de
Invoke f_verify_talloc_count() for bsc_subscr and
gsm_subscriber_connection, expecting none to remain after each test.
This makes numerous tests fail, where the test does not properly release
the RSL and BSSAP connections. An upcoming patch fixes all of those
cases: I9396efcabc085d2850244c6468b83c5f3a3ff3a2
Related: OS#5337
Change-Id: I69d4c5c6f8d499bb7f0b96a48af045361433c57b
To be able to invoke perform_clear() also in tests where the VTY isn't
used, in f_logp() only access the VTY when it is actually ready.
Otherwise this causes an error and a failed test, for no good reason.
Related: OS#5337
Change-Id: I8116075f32937bd06ba14b426010bf6fec2ef402
Cause GSM0808_CAUSE_MS_NOT_EQUIPPED is to be transmitted only in the case
BSC receives a RelInd from the MS/BTS. In this test, an ErrorInd is
sent, as in TC_rll_err_ind_sapi_n_reject, so it is expected that the
BSC will send the N_Reject message with cause
GSM0808_CAUSE_BSS_NOT_EQUIPPED.
Related: OS#4728
Related: SYS#5047
Fixes: 999ceb6637
Change-Id: Ieebe3465b31d98fcae0e2c1993477c5021c99b3b
IPA_Emulation component was marked with the "alive" type recently, in
order to avoid race conditions leading to errors during tear down of the
test.
It turns out, the way "alive" keeps the component alive is by means of
not closing the sockets when the component is stopped. As a result,
TC_rsl_drop_counter test stopped working properly because it was
specting a TCP FIN to be sent to osmo-bsc when the component was
stopped.
In order to fix it, add a new CFG port to the IPA_Emulation component on
which one can operate. Add a a new method to tell the component to close
the socket.
Then, put that in BSC_Tests into a function which was actually unsued
until now, and use it in the test in order to have the specific logic
enclosed in a function helper.
Fixes: 7138913d66
Change-Id: I68163b053313d9907ba8e40954a5933d14cb7db6
In the out-of-this-BSC handover tests, a neighbor config of LAC 99 left
behind from a previous test obstructed the test from working:
% BTS 0 already had neighbor LAC:99 ARFCN-BSIC:123-45
% ERROR: duplicate Cell ID in neighbor config, with differing ARFCN+BSIC: LAC:99 ARFCN-BSIC:123-any
Add a 'no neighbor lac 99' before configuring the neighbor via VTY.
Also add the missing neighbor config to
f_tc_srvcc_eutran_to_geran_ho_out_main().
Affects tests:
BSC_Tests.TC_ho_out_of_this_bsc
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out_forbid_fast_return
Change-Id: I7a7c97a47a06abb59c0d89638c6b503ab66eb359
* t_RSL_IE_ActType_PDCH is actually a constant, not a template.
* tr_RSL_CHAN_ACT_PDCH makes no use of parameter 'mode'.
* Accomplish tr_RSL_CHAN_ACT_PDCH with a send template.
* Use 'present' qualifier for receive template parameters.
Change-Id: Ie62a92daaacf4de5f05dd1f3f5b4a2a5e4ee6dd6
According to feedback received from TITAN developers in
https://www.eclipse.org/forums/index.php?t=msg&th=1106652&goto=1848616&#msg_1848616
the use of alive-type components has the following advantage:
> Also the DTE during the shutdown can be avoided to use alive type
> components. The test ports of the alive components are not
> disconnected/unmapped when the component finished only when killed or
> the MTC terminated.
So the idea of this patch is to use alive-type components for all the
underlying infrastructure, such as the *_Emulation_CT starting from M3UA
to SCCP and further up the stack. This way, only the MTC and the
highest level of components (such as ConnHdlr) remain as normal
components.
The hope is that using more alive-type components in the lower protocol
layer emulations will reduce the probability of DTE during shutdown if
some message is received during the component shutdown after the MTC
has completed.
Change-Id: I61d791d6d1bfe9226aabbe223baafc5f8f6d4f04
Using the same IMSI in each test case makes it harder to correlate
subscriber connections in the SUT with particular test cases. A
good example is a problem described in OS#5337: some test cases
create dangling subscriber entries that never got released:
OsmoBSC# show subscriber all
IMSI TMSI Use
001019876543210 ffffffff 3 (3*paging-start)
001010000100001 ffffffff 1 (conn)
With this patch I am getting the following output:
OsmoBSC# show subscriber all
IMSI TMSI Use
001016017428234 ffffffff 1 (paging-start)
001014631230680 ffffffff 1 (paging-start)
001011161500382 ffffffff 1 (paging-start)
001010000100001 ffffffff 1 (conn)
so I was able to correlate the following test cases:
* (001016017428234) TC_lcs_loc_req_for_active_ms_ta_req,
* (001014631230680) TC_lcs_loc_req_for_active_ms_le_timeout2,
* (001011161500382) TC_cm_service_during_lcs_loc_req,
* (001010000100001) TC_no_msc.
Change-Id: Ie008b5566b207b13cd562c55625bad38c09b3927
Related: OS#5337
This change fixes sporadic failures of TC_cm_serv_rej:
RAN Connection table not found by component TC_cm_serv_rej(2648)
BSC_Tests.ttcn:11106 BSC_Tests control part
BSC_Tests.ttcn:10550 TC_cm_serv_rej testcase
The reason is that sometimes a BSSAP/DTAP PDU (with CM Service Reject)
gets enqueued before the SUT has established an SCCP connection to the
virtual MSC. This causes a lookup error in the RAN connection table.
A simple solution would be to add a receive statement after calling
f_create_chan_and_exp(), like it's done everywhere else:
f_create_chan_and_exp();
BSSAP.receive(tr_BSSMAP_ComplL3); // <---
But a more general solution is to expect and receive this message in
f_create_chan_and_exp(), so we can reduce code duplication and make
the API more convinient. This is exactly what this change does.
Change-Id: Ic675168e29919e1234cb49440c4a630238ff5d70
Related: SYS#4878
Verify the BTS level assignment:attempted_speech / _sign as well as
assignment:completed_speech / _sign counters, in four selected
assignment tests (fr, hr, amr_f, amr_h).
Shows a bug where we counted a speech assignment as
assignment:completed_sign.
Related: SYS#4878
Depends: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8 (osmo-bsc)
Change-Id: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7
Test the new bsc.N.paging:expired stat in TC_paging_counter too.
Depends: osmo-bsc I9c118e7e3d61ed8c9f1951111255b196905eba4d
Related: SYS#4878
Change-Id: I8931bf1bc2f4e0d4b168168cdb83683bb350d961
So far all handover tests trigger handover via VTY command. This means
that any bugs introduced in measurement report handling and handover
target selection are by definition not caught.
Almost a year ago, fixing a handover oscillation bug for intra-BSC
handover introduced a segfault for inter-BSC handover targets, because
for those the target.bts is NULL. Show this bug.
Related: OS#5324 SYS#5259
Related: I5a3345ab0005a73597f5c27207480912a2f5aae6 (osmo-bsc)
Change-Id: Iba033c32015173f57dbb1c211aefab1a9094e29d
As can be seen from ttcn3-bsc-test run #1565 on Jenkins [1], it may
happen that the VTY command requesting handover reaches the IUT earlier
than the SCCP 'SACK CC' message. In this case, the 'SUBSCR_CONN' FSM
remains in state 'WAIT_CC', so we get an error:
(bts=0,trx=0,ts=0,ss=0) (ARFCN 871) --> BTS 1 Manually triggering Handover from VTY
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Received Event HANDOVER_START
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Event HANDOVER_START not permitted
The easiest way to avoid this is to introduce and artificial delay
after the connection establishment and before triggering the handover.
[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1565/
Change-Id: I19f7ca942e22d7930a56d1a525414f137a9ef831
Make the test more stable by sleeping a bit before stopping all
components. Also reduce the f_sleep(3.0), an accidental leftover from
initial debugging.
Related: SYS#4878
Change-Id: I005af13baac4bca2a431b09b2a6bbfe7077342e0
This test case fails in ttcn3-bsc-test-sccplite due to:
BSC_Tests.ttcn:10212 Dynamic test case error:
Using the value of an optional field containing omit.
Change-Id: I235027c2b53b8f2ae975e25eb7c38b1959668d6f
Related: SYS#5627