summaryrefslogtreecommitdiffstats
path: root/msc/MSC_Tests.ttcn
AgeCommit message (Collapse)AuthorFilesLines
6 daysmsc: Get rid of several uneeded module paramsPau Espin Pedrol1-9/+3
These params are not needed anymore since new releases used in -latest don't need to disable it. Change-Id: I16575ae4f615bf7c42d5921917003007ba4872a0 Related: OS#5042
2021-02-08msc: test reaction on Clear Request during a MO/MT CallVadim Yanitskiy1-0/+62
Change-Id: Id16969fe0de04445d1320a96d35cf1d48cc8cf09 Related: SYS#5340
2021-02-08msc: finish and enable test case for MT Call T310 timerVadim Yanitskiy1-14/+40
The test suite needs to handle MGCP messages, otherwise the related FSMs in the IUT would tear everything down before T310 is expired. Change-Id: I79d9ae3b086d05c3d7c0a1241720d6c3f1e90281 Related: SYS#5340
2021-01-07CTRL: Introduce support to run osmocom CTRL serverPau Espin Pedrol1-1/+1
Change-Id: I37db9962f51baf2c63bd58ec47ec89f773d7a255
2020-09-16mncc: Support IPv6 addresses (new version mncc 7)Pau Espin Pedrol1-0/+1
Apparently commit 06b859ca314f53a902329ed95848dbafef1d4f87 forgot to bump the MNCC_SOCK_VERSION field from 5 to 6. Change-Id: I5448ff931ec33f24f4837a51376f1703fe97683b
2020-09-15msc: Introduce module param to disable crashing test in latestPau Espin Pedrol1-4/+7
Otherwise all tests run after ruing MSC_Tests_Iu.control fail. Change-Id: I46f1066323e19dfe708402a8c9c68e257f62751c
2020-09-15msc: Drop parameter mp_enable_osmux_testPau Espin Pedrol1-14/+5
That was needed for osmo-msc <= 1.3.0, and we are at 1.6.1 now. Change-Id: I8bc0551ec91a5fd8ea2f291a1e16a06a739c7a75
2020-09-09msc: Introduce tests to verify BSSAP and MGCP handling with IPv6Pau Espin Pedrol1-6/+86
It tests IPv6 Transport Address are passed correctly through BSSAP, and forwards handles them correctly as an MGCP client too. Change-Id: Id616926dd4a9febc4268eea2ee1e377b2d22753a
2020-08-25msc: add TC_paging_response_[it]msi_unknownNeels Hofmeyr1-0/+46
These uncover crashes of current osmo-msc master, when a Paging Response contains an unknown mobile identity. Hence run them last. The crash is fixed by osmo-msc Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11 Related: OS#4724 Related: Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11 (osmo-msc) Change-Id: I40496bbccbbd9c496cfa57df49e26f124a2b1554
2020-08-25msc: add TC_cmserv_tmsi_unknown()Neels Hofmeyr1-0/+38
We already have TC_cmserv_imsi_unknown, but lack a test that shows CM Service Request behavior for an unknown TMSI. Looking at OS#4721 I vaguely expected an ID Request to also happen during CM Service Request, but instead we reject the unknown TMSI completely, and require the MS to perform a proper LU subsequently. Related: OS#4721 Change-Id: I54e5efcf4c31625205c99338379a2055633acde9
2020-08-25msc: add TC_attached_imsi_lu_unknown_tmsi()Neels Hofmeyr1-0/+89
The test currently fails with osmo-msc master. It uncovers the evil twin aspect of osmo-msc's VLR, for an attached IMSI re-attaching with an unknown TMSI. Related: OS#4721 Change-Id: Ia53733fc5bc414b0e3d3897f25b549f5183c862d
2020-08-20msc: Fix repeated execution of TC_sgsap_unsol_ud()Harald Welte1-7/+14
Change-Id: I6c2f1a5d5b5316ffe462335f8461c31564ce4274 Closes: OS#4722
2020-08-20msc: Make TC_lu_and_mo_call_sccp_tiar_timeout() more reliableHarald Welte1-1/+4
There is a race condition when shutting down, as a DLCX might arrive while we are half-shutdown. Expect both DLCX before terminating the ConnHdlr. Change-Id: Ia0342a9bb346929e0e538f4cb571abfc4acac6bf
2020-08-19msc: fix log typo in f_tc_cmserv_imsi_unknown()Neels Hofmeyr1-1/+1
Change-Id: If7aa20cd7fea81107f3748251070c32bb08f1f4e
2020-08-19msc: Expect CommonID from MSC by defaultHarald Welte1-0/+5
As of osmo-msc Change-Id I2552736477663adb250c55728093500e8ae83ebb, osmo-msc is always sending BSSMAP CommonID to the BSC. Let's adjust our test expectation, while allowing the user to start the tests with BSC_ConnectionHandler.mp_expect_common_id := false to get the existing behavior (expect no bSSMAP CommonId) can be restored, e.g. for testing 'latest'. Change-Id: I4976d9bb1f07c8ab4ffa02848414f8ddd1bdfd3f Related: OS#2969
2020-08-18msc: Use random chosen unused local TCP port number for SMPP clientHarald Welte1-1/+1
The existing code passed -1 as TCP port number to the SMPP client. This - very unintuitively - causes TITAN to always chose port number 9999, as that's the default value in IPL4asp. Let's use '0' instead. Change-Id: I4db38f4099c388bed23f9a3611619866ede9cbc5
2020-07-08msc: verify conn and VLR cell id in most testsNeels Hofmeyr1-24/+29
osmo-msc failed to record the Complete Layer 3 Information LAC and CI in the MSC-A as well as the VLR record. Since osmo-msc Iee1781985fb25b21ce27526c6a3768bf70d4dc9a and I194271af2acb37b4f8cc2d106ab2fd2b0d443589, osmo-msc properly records these for successful Complete Layer 3 procedures. Incorporate verification of the LAC and CI in all tests calling f_perform_lu() and f_expect_clear(). Implement by scraping the output of vty 'show subscriber imsi 1234 conn' Some tests model a failure to attach, or expire the VLR record: for those, add parameter verify_cell_id to g_pars, and pass it as false, to skip checking the LAC and CI. Disable CI checking for all Iu tests globally in f_verify_vty_lac_ci(), see OS#4634. For the latest build, which does not yet record LAC and CI properly, provide mp_enable_cell_id_test, which skips all cell id verification if set to false. Put to effect by docker-playground I052fea208021509e12826c50474b96474e7a58c2. Related: OS#4627 Depends: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a (osmo-msc) Change-Id: Ie410714a96353f74a52a104c56fa0a08683e0004
2020-06-14move type RAN_Configurations to RAN_Adapter.ttcnppNeels Hofmeyr1-1/+0
So far used only in MSC_Tests.ttcn, but soon to be used also in BSC_Tests.ttcn. Change-Id: If8f7fd50a88302af645ab337a907d8f0ad79a306
2020-05-18library/IPA: split t_ASP_IPA_EVT_UD into send / receive templatesVadim Yanitskiy1-1/+1
Change-Id: Ib5494bff3f9aa0ac396b729c326e7b4a64c5a5dd
2020-05-11msc: add tests for SMS and voice call while PagingNeels Hofmeyr1-1/+111
Start a second - MT SMS - MT call while a Paging is already ongoing. The second trans being an SMS works. The second trans being a call fails with current osmo-msc master; a fix is in the related patch (s.b.). Related: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be Change-Id: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
2020-01-20MSC: add a test case to check T3212 expiration during pagingVadim Yanitskiy1-0/+39
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
2020-01-15MSC/SMPP: fix RP-ACK expectations in TC_smpp_mo_smsVadim Yanitskiy1-2/+6
The MSC shall not send RP-ACK before the response from ESME. Change-Id: Ide1376cae8e75412039b7dc9f0b8bb390eab2280 Related: OS#4351
2020-01-15MSC/SMPP: introduce TC_smpp_mo_sms_rp_error for OS#4351Vadim Yanitskiy1-0/+45
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
2020-01-15MSC/SMS-over-GSUP: cosmetic: use a single log() call to print received PDUVadim Yanitskiy1-4/+2
Change-Id: I862766ac87715d5ad141405f343f0563fd75150f
2020-01-15MSC: fix coding style in f_tc_lu_and_mt_sms_paging_and_nothing()Vadim Yanitskiy1-12/+11
Change-Id: Ide647f62150b2ca64e12044ae8dae5bb33e600c2
2020-01-12msc: Introduce test TC_(iu_)chan_rel_sccp_tiar_timeoutPau Espin Pedrol1-0/+47
Verify SCCP T(iar) timeout triggers release of established channel. Related: OS#4343 Change-Id: Id6488a262e656f5c8fabb4e81f4797b305eb09e2
2020-01-10MSC: add test cases for concurrent MO/MT SS/USSD transactionsVadim Yanitskiy1-0/+41
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
2020-01-10MSC: f_ran_register_imsi(): allow passing omit as TMSIVadim Yanitskiy1-60/+11
Change-Id: I6dd2f77283a79e83f028115f4cc42f05db885838
2020-01-10MSC/Iu: fix SS/USSD tests: pass g_pars.tmsi to f_ran_register_imsi()Vadim Yanitskiy1-4/+4
Makes both TC_iu_proc_ss_abort and TC_iu_proc_ss_paging_fail pass. Change-Id: If7d58cb50d2810975bd547e4e828783b0255d809
2020-01-07MSC/GSUP: make session ID for MT SS/USSD configurableVadim Yanitskiy1-7/+8
This would allow to run multiple SS/USSD transactions in parallel. Change-Id: I326b5e47f4c1e9f9209efa64c143c3dc64132edb
2020-01-04MSC_Tests.ttcn: introduce TC_mm_id_resp_no_identityVadim Yanitskiy1-0/+38
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
2020-01-03MSC_Tests.ttcn: fix: verify the contents of SM-RP-DA/OA for MO/MT SMSVadim Yanitskiy1-8/+18
Change-Id: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9 Related: OS#4324
2020-01-03library/GSUP_Types.ttcn: fix MSISDN / SMSC coding in SM-RP-OA/DAVadim Yanitskiy1-2/+4
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
2020-01-03MSC/BSC_ConnectionHandler: only keep SMSC address in SmsParametersRpVadim Yanitskiy1-1/+1
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
2020-01-01msc: Introduce test TC_lu_imsi_timeout_tmsi_reallocPau Espin Pedrol1-0/+56
Related: OS#4336, OS#4337 Change-Id: I603b2b2b1ae7edd6360ea38c6bbbfedc46e9fa5d
2019-12-17msc: Remove trailing whitespacePau Espin Pedrol1-1/+1
Change-Id: I934dd3504fa91e2006fbc9b1133836060eb0591e
2019-12-12msc: expect only one Paging on GERANNeels Hofmeyr1-2/+28
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
2019-12-12msc: fix 2 Iu tests: use f_mm_common() instead of f_mm_auth()Neels Hofmeyr1-2/+2
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
2019-11-23msc: add f_tc_invalid_mgcp_crashNeels Hofmeyr1-0/+24
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
2019-11-23msc: add and fix Iu mt callNeels Hofmeyr1-1/+1
Change-Id: I3ce29f3d9254656dc295674e8cec72a741b7764a
2019-11-23msc: overhaul voice call testingNeels Hofmeyr1-206/+30
* 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
2019-11-04improve/fix f_tc_mo_setup_dtmf_dupNeels Hofmeyr1-0/+2
- 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
2019-10-04MSC_Tests.ttcn: fix race condition in f_tc_proc_ss_paging_fail()Vadim Yanitskiy1-2/+3
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
2019-09-28msc: add f_tc_lu_and_mt_sms_paging_repeatedAlexander Couzens1-0/+43
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
2019-09-24MSC_Tests: Expect SGsAP-SERVICE-ABORT-REQUEST on paging timeoutPhilipp Maier1-3/+21
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
2019-09-24Cosmetic: Fix commentPhilipp Maier1-3/+3
Change-Id: Ie1c80d951ea2f8e3e154beb5623aa0d5f5874a60
2019-08-18MSC_Tests: do not send an SGsAP-MO-CSFB-INDICATION when testing MT-CallPhilipp Maier1-3/+0
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
2019-07-23msc: check IMEI: move reject LU into new functionOliver Smith1-48/+4
Change-Id: Ifad259e21df035a89e97831a57c0675502308eb6
2019-07-23msc: use f_expect_clear() in check IMEI testsOliver Smith1-2/+6
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: 1d118ff753d963cfe5feb2450a31bc3a51aa5eb6 ("msc: add check IMEI tests") Change-Id: I836f76242463789c4c003feec757714827f2a31b
2019-07-12msc: add check IMEI testsOliver Smith1-1/+300
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
generated by cgit v1.2.1 (git 2.18.0) at 2021-03-04 03:12:48 +0000