Long story short: some time ago I noticed that OsmoMSC crashes if
T3212 expires during the Paging procedure. This is not the case
anymore (as the test case shows) and apparently the bug has been
fixed, hovewer I believe it makes sense to add this test case.
Change-Id: If9147ae8b07d5120d2853b9acda2313910ac48be
This test case reproduces the problem described in OS#4351:
1. MS/UE submits a MO SMS which it getting touted to an ESME;
2. MSC prematurely responds with RP-ACK to the MS/UE;
3. ESME responds with DELIVER-SM error;
4. SMS transaction is already terminated (by RP-ACK).
Expected behaviour:
1. MS/UE submits a MO SMS which it getting touted to an ESME;
2. ESME responds with DELIVER-SM error;
3. MSC terminates the SMS transaction with RP-ERROR.
Change-Id: I33c6ea0ffdf8b8a45f587d690bdceb38fc42c898
Related: OS#4351
Since Ibca0e9196c25ab00803041b81f7b490ba2f0a3ba we can have up to
16 components of type BSC_ConnHdlr running in parallel. Both
TC_multi_lu_and_{mo,mt}_ussd test cases have been updated,
but their Iu/UMTS siblings have not. Let's fix this.
Change-Id: Iaa7347e973ee617cc1780b84e0c298f0a302227c
Both test cases make use of the existing functions:
- TC_multi_lu_and_mo_ussd: f_tc_lu_and_mo_ussd_single_request(),
- TC_multi_lu_and_mt_ussd: f_tc_lu_and_mt_ussd_notification(),
starting several (*) BSC_ConnHdlr components in parallel.
(*) The maximum amount is limited by 16 - this is as much
as both GSUP and SCTP emulation components can handle.
Change-Id: I2fb1c5d285163d5245d92fa24c197a5027ecbe6f
Related: OS#2931
Since [1] we started to match the SMSC Address in f_mt_sms_expect().
That change caused test case failures because OsmoMSC hard-codes
a different SMSC Address. Let's fix this.
[1] Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Change-Id: I3bdb6a74c8b02e4bf8dc88634e2380c924242b4b
While investigating OS#4340, it was discovered that a malformed
MM Identity Request with MI Type '111'B crashes OsmoMSC.
Unfortunately, I could not find a way to encode such an invalid
message in TITAN (because value '111'B is reserved), so I
figured out that '000'B also crashes OsmoMSC.
MM Identity Request is triggered by initiating an Update Location
Request with reserved TMSI value 'FFFFFFFF'O (unknown to the MSC).
Change-Id: I62f23355eb91df2edf9dc837c928cb86b530b743
Related: OS#4340
Unlike IMSI, both MSISDN and SMSC address in SM-RP-OA/DA not only
contain the BCD encoded digits, but also a little header with
NPI (Numbering Plan Identification), ToN (Type of Number), and
Extension fields.
Change-Id: I3f55834489f3e613f541cf1e216027e8d48ccaf0
Related: OS#4324
When sending MO or MT SMS, we never include both SM-RP-DA/OA IEs
at the same time. In case of MO SMS, SM-RP-OA is omitted, and in
case of MT SMS - SM-RP-DA is omitted.
Change-Id: Ia60bdd2498034b6b849f874cf1eee272abef2b47
After discussion on this thread:
http://lists.osmocom.org/pipermail/openbsc/2019-November/013058.html
Do not expect repeated Paging on GERAN.
Pending clarification on 3G, still expect repeated Paging on Iu, though we are
not 100% certain that this is indeed required.
Fixes MSC_Tests.TC_lu_and_mt_sms_paging_repeated,
but not MSC_Tests_Iu.TC_iu_lu_and_mt_sms_paging_repeated
Change-Id: Ie914ea88f31ac158f4bd1700143bbe728dd05e0b
Fix these tests by using f_mm_common(), which takes care of Iu auth+ciph:
TC_iu_lu_imsi_reject
TC_iu_lu_imsi_timeout_gsup
Change-Id: Id2bf160ac4e1cad4770202c6a6f1b8eeeee21d68
Make sure that osmo-msc doesn't crash if a successful CRCX response contains an
invalid IP address.
Originally/recently, osmo-msc did not validate the IP addresses at all. In an
intermediate patch I added error handling, releasing the call. That uncovered a
use-after-free problem in libosmo-mgcp-client. This problem is fixed by
osmo_fsm_set_dealloc_ctx() and an osmo-mgw fix (see
I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 in osmo-mgw).
Add this test to make sure the crash is not re-introduced.
Change-Id: I0c76b0a7a33a96a39a242ecd387ba3769161cf7a
* Semantic:
We don't really know which side the MSC first creates a CRCX for. Instead of
assuming that the RAN side is always CRCX'd first, simply handle a "first" and
a "second" CRCX, not making any assumptions which is for which side.
Notably, there still are quite a few places assuming which CRCX corresponds to
the RAN/CN side, but the changes are sufficient to still pass the tests when
osmo-msc swaps the CRCX order; sometimes for slightly obscure reasons, for
example because it doesn't matter that the wrong port number is returned during
a subsequent MDCX... Cleaning up the rest is still todo for later.
Remove code dup from call establishing code, particularly for MGCP.
Use f_mo_call_establish() and f_mt_call() where ever possible, to make all of
the call establishing tests handle upcoming changes in osmo-msc's order of
messages, without re-implementing the changes for each test individually.
The X-Osmux parameter was so far expected to appear in the first CRCX received,
assuming that this first CRCX is for the RAN. Instead, detect whether X-Osmux
is contained in a CRCX, and reply with an Osmux CID if so, regardless of it
being the first or second CRCX. Count the number of X-Osmux parameters
received in CRCX messages, and compare after call setup to verify X-Osmux
presence.
Since f_mo_call_establish() can't handle RANAP assignment, a few Iu tests that
worked with the older code dup will break by this patch. This is fixed by a
subsequent patch, see I0ead36333ab665147b8d222070ea5cf8afc555ec.
* Details, per patch chunk:
Change ts_BSSMAP_IE_AoIP_TLA4 to a non-value template, so that we can use a
wildcard for the assigned port number from MGCP (depending on RAN or CN CRCX
first, the RAN port number can be one or the other).
In CallParameters, move MGCP handling instructions into a separate record
"CrcxResponse", and have two of them for handling the first and the second
CRCX, replacing mgw_rtp_{ip,port}_{bss,mss} and mgcp_connection_id_{bss,mss}.
In CallParameters, add some flags for early-exiting call establishment with a
particular desired behavior, for specialized tests.
In CallParameters, use common default values and don't repeat them in each and
every call establishing test.
Set cpars.mo_call := {true,false} implicitly when f_{mo,mt}_call_establish()
are invoked.
Remove CRCX comments implying RAN or CN side, instead just talk of the "first"
and the "second" CRCX.
Implement one common f_handle_crcx() function, which is used by
f_mo_call_establish(), f_mt_call_complete(), as_optional_mgcp_crcx(), and
implicitly uses the first/second CRCX handling.
For Assigment, use a wildcard RTP port so that we don't have to assume which
CRCX was for the RAN side.
In f_mo_call_establish(), insert special case conditions to make it enact
errors at specific times, for individual tests. That saves re-implementing the
entire call establishment (code dup).
For error cases, add expectation of a CC Release message in the call
establishment. This should not apply for normal successful operation, but
because interleave does not support conditionals, add flags
got_mncc_setup_compl_ind and got_cc_connect to break the interleave when
establishing is complete, so that the CC Release is skipped.
A CC Release always breaks the interleave, at whatever time it arrives.
Tests adopting f_{mo,mt}_call instead of code dup:
f_tc_mo_setup_and_nothing()
f_tc_mo_crcx_ran_timeout()
f_tc_mo_crcx_ran_reject()
f_tc_mo_release_timeout()
f_tc_mo_cc_bssmap_clear()
Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
- Fix error log for a missing final DTMF.
- Instead of code dup to establish a call, use f_mo_call_establish(). This
will make the test benefit from changes to f_mo_call_establish() (which will
soon come up to accomodate changes in osmo-msc's codec negotiation).
- Instead of hardcoding the expected N_SD counter values to detect DTAP
duplicates, use f_bssmap_last_n_sd() and f_next_n_sd(), so that the N_SD
counter is correct regardless of how many DTAP were sent in
f_mo_call_establish().
- Instead of hardcoding a correct N_SD in the end, use skip_seq_patching ==
false, so that the ttcn DTAP correctly tracks N_SD for subsequent call
release messages.
- Release the call.
Change-Id: Ibfa8b906764f2d5ed75fe74125be42af4546e864
Before this, if an Assignment Request contains an unexpected Transport Layer
Address, the test completely rejects the Assignment Request.
Instead, accept any tla in the Assignment, and compare the expected tla in the
Assignment's interleave action. Thus we directly get logging hinting at the tla
instead of a T_guard timeout.
Change-Id: I04847c10d6c3bf9e04cfda6e343dfd4a65be71a5
Sometimes in TC_proc_ss_paging_fail we hit a race condition. The
problem is that the paging expiration timer in OsmoMSC is set to
10 seconds by default (see MSC_PAGING_RESPONSE_TIMER_DEFAULT),
and in f_tc_proc_ss_paging_fail() we also wait 10.0 seconds.
Let's increase our timer value to 20.0 seconds,
so there will be more 10 seconds of leeway.
Change-Id: I6983e8c0cc8e1d7d1619f127e80063d71a4759d2
Related: Jenkins ttcn3-msc-test build #677
The testcase will ensure paging is repeated by the MSC.
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
Change-Id: Ib5bf0b62e0639436cdcba03acbaedf1458e18873
When a paging for a CS-Call times out the MSC/VLR is expected to send an
SGsAP-SERVICE-ABORT-REQUEST to the MME to indicate that the paging has
timed out. This is not taken into accound yet by TTCN3 test
TC_sgsap_paging_and_nothing
Related: OS#3614
Depends: osmo-msc I3f8f153afe24cf2efa245713509bdc8488902877
Change-Id: I99950a17ccf26aaa0eebded5480f33be4c57586a
The TTCN3 tests MSC_Tests.TC_bssap_lu_sgsap_lu_and_mt_call and
MSC_Tests.TC_sgsap_lu_and_mt_call initate an MT-CSFB call for testing
purposes, but they also send an SGsAP-MO-CSFB-INDICATION to make the MS
come back to LTE. This is wrong. SGsAP-MO-CSFB-INDICATION just informs
the VLR that the UE has initiated a MO CSFB call on the LTE side. On MT
CSFB calls this message should not appear. Lets remove it.
Related: SYS#4624
Change-Id: I2e9fda4fe97866c4cbc77224ba1930ca81411fd6
Fix the broken pipe race condition caused by closing the RAN connection
too early. Properly wait for clear command and send clear complete.
TC_lu_imsi_auth_tmsi_check_imei_{nack,err} do not pass anymore, because
OsmoMSC is sending the LU reject twice. Patch [1] fixes it.
[1] I127b27937613ea0ff29d67991c0414fca6d441d9 (osmo-msc)
Fixes: 1d118ff753 ("msc: add check IMEI tests")
Change-Id: I836f76242463789c4c003feec757714827f2a31b
Extend BSC_ConnHdlr with new check IMEI related parameters. Add tests
for check IMEI and check IMEI early for multiple auth variations, as
well as variants where the HLR would respond with NOK or ERR.
Note that we can safely set "check-imei-rqd 0" in f_init(), because the
latest OsmoMSC version already suppors this VTY command.
Two tests do not always pass, sometimes the RAN connection breaks
before the test finishes (TC_lu_imsi_auth_tmsi_check_imei_err and
TC_lu_imsi_auth_tmsi_check_imei_nack). I have added them as expected
errors in the expected-results.xml.
Related: OS#2542
Change-Id: Ic34bb8dc8547cafb5a53df03884554dd4f72956d
* Some scenarios like MGW BSC-attached in SCCPlite require handling of
2 MGCP-over-UDP sockets in MGCP Emulation: 1 for regular
libosmomgcp-client from osmo-bsc and another one from the forward socket
from osmo-bsc (of MGCP-over-IPA messages communicated with MSC).
* Old port is kept for backward compatibility with other tests and
enabled by default. It's also interesting to keep it because it makes
tests without special needs (2 sockets) to use the old port/API which
produces simpler code to read and mantain.
* Users of the new port have to enable multi_conn_mode parameter and
expect to interact with port MGCP_CLIENT_MULTI instead of MGCP_CLIENT,
which will offer messages containing information about the UDP
connection being used by that message.
Change-Id: Ic0ba8c5cde068c07671512a83095d83e28b86746
The new test case is aimed to verify that OsmoMSC properly does
reject (call independent) SS/USSD messages for non-existing
transactions.
Change-Id: I231142c88b0d3308039c797aa2bccadd79dce18b
Related: OS#2931
This test case is aimed to verify HLR-/EUSE-initiated abort of an
active SS/USSD session according to the following scenario:
1. (HLR/EUSE -> MSC) GSUP_PROC_SS_REQ with random facility;
2. Network-originated connection establishment:
2.a. (MSC -> BSC -> MS) Paging Request;
2.b. ...
2.c. (MS -> BSC -> MSC) Paging Response;
3. (MSC -> MS) GSM 04.80 REGISTER with random facility;
4. (HLR/EUSE -> MSC) GSUP_PROC_SS_ERR (abort);
5. (MSC -> MS) GSM 04.80 RELEASE COMPLETE;
6. Connection release.
As can be seen, HLR/EUSE initiates the session abort right after
the GSM 04.80 REGISTER message is delivered to the MS, and just
before the MS sends anything back in response.
Change-Id: I5586a88136c936441a842f49248824680603672e
Related: OS#2931
The idea of this test case is to check that OsmoMSC does inform
HLR/EUSE that a subscriber did not respond to Paging Request in
case of network-originated SS/USSD.
Both f_expect_gsup_msg() and f_expect_dtap_msg() were extended
with optional timeout value, as we need to wait longer than
2.0 seconds (default). Let's stick to 10.0 seconds.
Change-Id: I1f53c56d569c8ac4071835685bbe3bc9e0ebd7f0
Related: OS#2931
The idea of this test case is to check that OsmoMSC properly
rejects GSUP PROC_SS messages for unknown sessions.
As it turned out, OsmoMSC doesn't send GSUP PROC_SS ERROR
as expected. The fix has been submitted.
Change-Id: Ie267ee174c5061cd3fc102a2824abe03d73f3aac
Related: OS#2931
Vadim Yanitskiy
Pau Espin
Philipp Maier
Oliver Smith