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
The idea of this test case is to check that OsmoMSC properly
rejects SS/USSD requests for unknown subscribers.
Running this test case against the current OsmoMSC helped
to discover several problems:
- OsmoMSC doesn't print anything in such cases;
- IMSI in the response error message is empty;
- both session state and ID IEs are omited;
which are going to be fixed soon.
Change-Id: Id35cd3ec15d1bab15260312d7bbb41e2d10349fe
Related: OS#2931
This will allow RAN_Emulation to have better knowledge on the protocol
stack in use, and behave differently based on that information.
For intance, forthcoming commit will append OsmuxSupport IE only if
transport is BSSAP AoIP.
Change-Id: Ife62e328af2d3f2475ff93249f2138820c7ddabb
Even if ciphering it not enabled, osmo-msc still sends a
SecurityModeCommand to use IntegrityProtection, and as a result osmo-msc
assumes implicit ACCEPT in all UTRAN CM service requests.
Fixes: OS#3991
Change-Id: Ida91f907dd6dfae68cbc63752ddc6f2948792689
ttcn3-bsc-test-latest currently fails on most tests because it tries to
use "osmux off" VTY param and only current osmo-msc master supports
it.
Change-Id: I53d58b2d905905ebf1df322d0389b3715a48212f
Initially it was thought safe to only enable it since the osmux test was
at the end, but actually IU tests run after it, and those don't expect
osmux to be enabled.
This way we also always match osmo-msc osmux state with whatever the
test expects (and sets through f_init()).
Change-Id: I8fb48af7d37f1a2391a39c19f5ec5064cd5869d2
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
Since we use some BSSMAP extensions to signal Osmux, we need to maintain
our own fork of BSSMAP_Types in order to supports those IEs in BSSMAP
RESET and BSSMAP Assin Req/Compl. Hence, switch all build componenets to
fetch and use our fork.
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: Ic8debe5f3ffe8e1d4258fa6b4632a3871b99af40
Add three tests which exercise MSC behaviour when a CIPHER MODE
COMPLETE command lacks the optional chosenEncryptionAlgorithm IE.
Check for behaviour with A5/1, A5/3, and A5/1 + A5/3 configured
in the network, and expect the location update to succeed.
These tests pass on master, but they should somehow verify the
cipher the MSC ends up using. I am not quite sure how to do that.
Would inspecting the MSC's VTY be a reasonable approach? How
could his be done by code which runs on BSC_ConnectionHandler?
Change-Id: I1a2a126795c544613a7a87e238e1fc8c4e943885
Related: OS#2872
Verify that the MSC rejects a location update from a Cell/BSC that
contains a PLMN which does not match the core network's PLMN.
Related: OS#3162
Change-Id: I676894358259b9cc0f973769ce552ba58a2a58a1
In some cases we might want to match on (and perform) the GSUP
SEND AUTH INFO without also expecting/performing a MM authentication
on the Iu/A interface. Hence it makes sense to split those two.
Change-Id: I7b298d589930bab976b478ac84553a6352f25c93
Tests like TC_lu_imsi_reject, TC_lu_imsi_timeout_gsup and
TC_cmserv_imsi_unknown all expected a reject straight in response
to the LU REQ / CM SERV REQ. However, the MSC may very well decide
to perform authentication beforehand. It's an implementation
detail when a MSC/VLR performs authentication, so the tests should
be tolerant to this.
This primarily shows up in 3G/Iu/RANAP related tests, as authentication
is mandatory there.
Change-Id: Icdd3f34eca08092703ab2ba9a8e755e2d609a59b
We were using '?' for the protocolExtensions in RANAP messages,
which required that such extensions existed. In reality, we want
to use '*' which accepts paging messages whether or not there
are any protocolExtensions present. As this is the default in
all our RANAP receive template, callers don't even need to specify
it.
This should fix all Iu paging related test failures in MSC_Tests*.ttcn
Change-Id: If22e16ecb301c86b9073ffde0af9e03bc85fbcc7
Both f_mo_call_establish() and f_mt_call_establish() were testing barely half a
voice call setup. For example, f_mo_call_establish() used to be satisfied with
just two CRCX, but no actual RTP connections being made.
Add numerous MNCC and MGCP messages more closely resembling an actual call.
The main reason is to achieve a state that passes both current osmo-msc master
as well as the upcoming inter-MSC Handover refactoring.
Add log markers to f_*_call_*(): often when a test halts, it is not at all
clear why. With these log markers it is saner to figure out what has happened
and what hasn't.
Change-Id: I162985045bb5e129977a3a797b656e30220990df
This function is required not only for the MSC_Tests, but also for
the upcoming Iu related SGSN tests
Change-Id: Ic23669671ce79151046f2330726bb68542faeb0e
This might look a bit like copy+paste programming for our testcases.
However, we actually want the Iu related tests show up as separate
'testscase' in the TTCN-3 sense, so there's no way that's more elegant
than this :/
Change-Id: I3b56e17487c9df839e67ed390a1ff89979683e8e
The new function will check the RAN type and dispath to
f_bssap_compl_l3() in case of 2G/GERAN and to f_ranap_initial_ue()
on case of 3G/UTRAN.
Change-Id: Ia27afa265d441d1a0cbb40cc2d938aff46fa25f9
The RAN_Emulation currently unconditionally provides BSSAP and MGCP support.
Let's re-structure the code so that support for those protocols is now
possible to enable/disable at compile time.
This patch is in preparation of introducing RANAP support in RAN_Emulation.
Change-Id: Id53ba3ff05f9946230e0e4a759245de14a0f9fbd
Related: OS#2856
This allows to start ConnHdlr on specific RAN connections, i.e.
on different emulated BSCs (and soon RNCs).
Change-Id: I3d7ec567a7b69d8c6f79d26971bf1c94e077d5f5
Vadim Yanitskiy
Philipp Maier
Oliver Smith
Pau Espin
Harald Welte