* 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
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
So far, BSSMAP_Emulation supported only a transport over BSSMAP.
However, we soon intend to merge support for RANAP in order to
simulate RANAP/Iu connections as well as BSSMAP. Let's start
by renaming some of the existing types/functions/ports/modules
without introducing any functional changes just yet.
Related: OS#2857, OS#2856
Change-Id: Iecbcb0c6c136baad9460eca40606bb4010d8882d
An MSC might decide to repeatedly retry Paging if it failed the first time, but
osmo-msc currently has no such mechanism. Instead, it so far had a bug that
retriggered a failed Paging from a start in a situation where there are SMS
pending for only one subscriber, and sending the SMS fails. osmo-msc patch
I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49 changes this behavior to accept a
Paging failure and not launch the same SMS again numerous times.
Adjust the tests to this new behavior.
Depends: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49 (osmo-msc)
Change-Id: I7dce12942a65eaaf97f78ca69401c7f93faacb9e
If an MT SMS is triggered and not handled in the test, it is so far left behind
when the test ends. That causes Paging to retrigger for that SMS at any later
point during subsequent test runs, causing stray bogus test failures.
Actually remove the SMS from the SMS database and the queue with a new VTY
command: The vty command to clear failed SMS from the db is added in osmo-msc
I637cbd7adc075a192f49752b38779391472ff06d
Depends: I637cbd7adc075a192f49752b38779391472ff06d (osmo-msc)
Change-Id: I4ff05187131e93f5bc58dc7ea44546f770e5b4c1
Currently we do not simulate a situation where the HLR is unreachable to
the MSC. Lets add a test wehere the HLR is disconnected and an LU via
SGsAP is tried. The SGs interface should then carry out a reset
procedure.
Change-Id: I830d0b936cbe9d73d1e0b1f4792c2be3d0b08cb9
Related: OS#3859
The GSUP link between testsuit and osmo-msc is currently on by default
and can not be disabled. However, there may be situations where a
missing GSUP connection must be simulated. Lets add add a parameter to
disable GSUP if necessary.
Change-Id: I7c86aa0a906a0d7e8be765f9109a65b4b4387bc6
Related: OS#3859
When a subscriber is detached from non eps services, it gets fully
detached from 2G, which means that the VLR is supposed to remove the
subscriber. Lets check if the subscriber is in deed no longer known by
the VLR.
Change-Id: I2ec3f548dfcf5a9b99f10214a8bfd0c6978e253b
Related: OS#3614
We have a testcase that sends an explicit (UE-Initiated) imsi detach
from EPS services. Lets also cover the case for an implicit
(Network-initated) detach.
Change-Id: I63ebc32ae457dd74214d4abee4f511cde28de4a7
Related: OS#3614
We have a testcase that sends an explicit (UE-Initiated) imsi detach
from non EPS services. Lets also cover the case for an implicit
(Network-initated) detach.
Change-Id: I76049e6717680c54c18f97b7cd51944901a81ae7
Related: OS#3614
The control interface of osmo-msc is able to return a list with all
active subscribers from the VLR. Lets add a function, so that we can
check from TTCN3 if a specified subscriber is known by the VLR or not.
Change-Id: I7661ae55afe34795c3701d59795331b32d64c988
Related: OS#3614
The only reason to omit f_sgsap_bssmap_screening() in this was the still
pending SMS in the database. Since SMS are now removed,
f_sgsap_bssmap_screening() will succeed.
Change-Id: Ibea1e1fb33e0dde7e8bf51ff226d5e57c5a5d763
Upcoming osmo-msc changes move away from the current ordering of MGCP and
Assignment messages. Allow these async dialogs to appear in any order.
Change-Id: Ia06af1e347601949f4ddb19f963daa400766d9e7
So far we omit a Speech Codec (Chosen) from Assignment Complete messages, which
is actually a mandatory parameter. osmo-msc seems to carry on nevertheless, but
it actually shouldn't be able to.
Always send a Speech Codec (Chosen).
Change-Id: Ib35f019383db8ace05a9dc349648e2da7ba58bfa
For the sole reason that f_vty_sms_send() was put on MTC_CT for no apparent
reason, we start the test function and send an SMS with an arbitrary two
seconds delay.
Instead move it to BSC_ConnHdlr and place SMS sending in the actual test
function flow where it belongs.
Change-Id: I5f348b3d30342b7c4871a1fc8f94648923e82eea
When aborting a call with a Clear Request, it is actually a good idea to
release an ongoing call with a CC Release message from the MSC. Allow this.
Change-Id: I8378f7602fecac8262b31b47ad9327a3782c1bcd
When a CSFB voice call is cleared by the MSC, it must include the
CSFB INDICATOR in order to trigger the BSC to perform actions
required for Fast Return to LTE.
This patch changes TC_sgsap_lu_and_mt_call() and
TC_bssap_lu_sgsap_lu_and_mt_call() to ensure the CSFB INDICATOR IE
is present as expected.
Change-Id: I6ce3a34f85aca7143cf7925cb9319bc679e8d395
At the moment the SGs interface is started and connected in all tests in
the testsuite. This may be a problem because the IUT may lack the SGs
support. In this case all tests would fail because of the missing SGs
interface.
Lets initalize and connect the SGs interface only for SGs related tests
to prevent unrelated test failures.
Change-Id: I8e012e3599ad00db2e132b6463499f8a4a2307f1
Related: OS#3614
The testcase TC_gsup_mt_multi_part_sms is known to fail osmo-msc in a
way that meaninful sms delivery is not possible anymore. This is due to
a bug in osmo-msc, but in the testsuit it makes running certain normally
working testcases impossible. Lets move at at the end of the testsuite
so that it rus late and other tests won't get blocked.
Change-Id: I581cd80895ea992a15389c6f73816769864e6d4c
Related: OS#3614
The IMSIs used with the SGs tests are partially re-used in other SGs
testcases and also in unrelated testcases. Lets give each SGs test a
unique IMSI to prevent unrelated interference with other tests.
Change-Id: I417d9c5f0fbab7483d1b31dc20a99f63ee1bbfe6
Related: OS#3614
The idea of this test case is to verify SM-RP-MR assignment for
a few concurrent MO/MT SMS being sent over GSUP.
Basically, the algorythm is the following:
1.0 establish a RAN connection,
1.1 send CM Service Request for MO SMMA indication,
1.2 submit MO SMMA indication on DTAP,
1.3 expect MO-ForwardSM-Req on GSUP,
2.0 send MT SMS using MT-ForwardSM-Req on GSUP,
2.1 expect CP-DATA/RP-DATA for MT SMS on DTAP,
3.0 compare both SM-RP-MR values (for MT, assigned by the MSC),
3.1 send MO-ForwardSM-Res for MO SMMA on GSUP,
3.1.1 expect CP-DATA/RP-ACK for MO SMMA on DTAP,
3.2 send CP-DATA/RP-ACK for MT SMS on DTAP,
3.2.1 expect MT-ForwardSM-Res for MT SMS on GSUP.
Change-Id: I17cbbaa64d9bce770f985588e93cd3eecd732120
The idea of this test case is to verify SM-RP-MR assignment for
a few MT SMS being sent over GSUP. Basically, the algorythm is
the following:
1.0 send the 1st SMS using MT-ForwardSM-Req on GSUP,
1.1 expect Paging Request on RAN,
1.2 establish a RAN connection,
1.3 expect CP-DATA/RP-DATA for the 1st SMS,
2.0 send the 2nd SMS using MT-ForwardSM-Req on GSUP,
2.1 expect CP-DATA/RP-DATA for the 2nd SMS,
3.0 compare both SM-RP-MR values assigned by the MSC,
3.1 send CP-DATA/RP-ACK for both 1st and 2nd SMS messages,
3.2 expect MT-ForwardSM-Res for both 1st and 2nd SMS messages.
The SM-RP-MR values for both 1st and 2nd messages shall not match.
Change-Id: I3a52d44f4abde9b6b471b9108c1cee905884c9bc
The testcase TC_lu_and_mt_sms_paging_and_nothing is currently using an
IMSI that ends on 43. The same IMSI is used by TC_mo_cc_bssmap_clear as
well. Since TC_lu_and_mt_sms_paging_and_nothing is running before
TC_mo_cc_bssmap_clear, the re-use of the IMSI triggers the MSC to
continue the paging procedure. The MSC then eventually tries to deliver
the SMS from TC_lu_and_mt_sms_paging_and_nothing. This will disturb the
execution of TC_mo_cc_bssmap_clear, which then fails.
Lets make sure that TC_lu_and_mt_sms_paging_and_nothing uses an
individual IMSI that is never used again throught the execution of the
testsuite.
Change-Id: I66f8310981078dd032c47fcc97810944cf0c856f
Related: OS#3762
Trigger sending of an SM, but ignore any paging requests from the
MSC, make sure that the MSC is not paging indefinitely
Change-Id: Id645729551672026c6a96bb849ecd04f20cd0c56
Related: OS#3704
The idea of this test case is to verify the process of multi-part
MT SMS transmission. The MSC should keep the RAN connection until
the last message part is transmitted.
Change-Id: I6308586a70c4fb3254c519330a61a9667372149f
Related: OS#3587
The idea of this test case is to verify MT SMS transmission
initiated by ESME over GSUP. Basically, the algorythm is
the following:
1.0 send MT-ForwardSM-Req on GSUP,
1.1 expect Paging Request on RAN,
1.2 establish a RAN connection,
1.3 expect CP-DATA/RP-DATA on BSSAP/DTAP,
2.1 send CP-DATA/RP-ACK on BSSAP/DTAP,
2.2.a expect MT-ForwardSM-Res,
2.2.b expect MT-ForwardSM-Err.
Change-Id: I63a25c8366cce0852df6b628365151661a22a25f
Related: OS#3587
At the moment the sgsap always enabled in the testsuite. This means the
testsuite will try to connect the SGs interface of osmo-msc on
initalization. If the connection fails, the testcase will fail also.
Unfortunately the related patches that add the SGs interface to osmo-msc
are not yet merged to master. This causes almost all testcases to fail,
so lets have the SGs interface as an option that we can switch on when
the SGs interface patches are merged to master.
Change-Id: I429c0c5250d4b61de8a4d6399f284ce2c87cca93
Related: OS#3645
This extens MSC_Tests.ttcn with an initial set of SGs interface test
cases for RESET, LU, DETACH, PAGING, SMS and CSFB procedures
In particular the following testcases are added:
- TC_sgsap_reset: isolated reset procedure test
- TC_sgsap_lu: isolated location update with TMSI realloc
- TC_sgsap_lu_imsi_reject: location update, reject case
- TC_sgsap_lu_and_nothing: location update with failed TMSI realloc
- TC_sgsap_expl_imsi_det_eps: detach from EPS serveces
- TC_sgsap_expl_imsi_det_noneps: detach from non-EPS services
- TC_sgsap_paging_rej: isolated paging, reject case
- TC_sgsap_paging_subscr_rej: isolated paging, subscr rejects call
- TC_sgsap_paging_ue_unr: isolated paging, ue is unreachable
- TC_sgsap_paging_and_nothing: page, but don't respond
- TC_sgsap_paging_and_lu: check paging followed by an LU
- TC_sgsap_mt_sms: mobile terminated SMS through SGs Interface
- TC_sgsap_mo_sms: mobile originated SMS through SGs Interface
- TC_sgsap_mt_sms_and_nothing: trigger SMS, but don't respond to paging
- TC_sgsap_mt_sms_and_reject: trigger SMS, but reject paging
- TC_sgsap_unexp_ud: Send unexpected unitdata (SGs Association: NULL)
- TC_sgsap_unsol_ud: Send unsolicited unitdata (subscriber not in VLR)
- TC_bssap_lu_sgsap_lu_and_mt_call: LU on 2G, LU on SGs and CSFB call
- TC_sgsap_lu_and_mt_call: LU on SGs, and CSFB call
Change-Id: I38543c35a9e74cea276e58d1d7ef01ef07ffe858
Depends: osmo-msc I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3645
The idea of this test case is to verify MO SMMA transmission
over GSUP towards HLR. The algorythm is equivalent to MO SMS.
Change-Id: I7abc95b8e416f7308d54e11be11c08586d18e6c5
Related: OS#3587
The idea of this test case is to verify MO SMS transmission
over GSUP towards HLR. Basically, the algorythm is the following:
1.0 establish a RAN connection,
2.1 send CP-DATA/RP-DATA on BSSAP/DTAP,
2.2 expect MO-ForwardSM-Req on GSUP,
3.1 send MO-ForwardSM-Res on GSUP,
3.2 expect CP-DATA/RP-ACK on BSSAP/DTAP.
Change-Id: Id14bbd8bd51558cdacefea0fe042769cd69ed5c8
Related: OS#3587
The MM Info message is an optional message that is set to the MS usually
after the location update. It contains the full network name and time
information. At the moment the presence of this message is not checked
or expected since sending of MM-Info is explicitly disabled in the
osmo-msc configu.
This patch adds an optional check of MM Info that is disabled by
default.
Change-Id: I431f50c2ff3536f87f0c7c3caf23b7a38d501904
Related: OS#3615
Ensure that tests running after TC_cipher_complete_with_invalid_cipher
won't see a left-over subscriber connection at the MSC.
Change-Id: If26ee688f77cdb80557e9695b8e3920fa2ce6706
Related: OS#2872
The BSC_ConnectionHandler currently has no access to the VTY interface.
Lets make it available so that upcoming tests can use the VTY interface
to trigger actions (e.g. Paging, see also Change Id:
6a1a6bd6da1bf46d6d703be495795d3610ca431)
Change-Id: I684f0a3a435924d81bc5a793cb7b43a3ab9ef842
Related: OS#3615
There are some upcomming tests which require to access the control
interface of the MSC while the actual test is running. Future test
cases (e.g. Paging, see also Change Id:
a6a1a6bd6da1bf46d6d703be495795d3610ca431) will use this.
Change-Id: Ie3caf7a449311e7687670cadfa27818635d25aa4
Related: OS#3615
Related: OS#3187
Add new test TC_cipher_complete_with_invalid_cipher which verifies
that the MSC will reject a CIPHER MODE COMPLETE command with a
cipher which wasn't part of the preceding CIPHER MODE command.
Change-Id: I4492eb7d77371aaa047abae81a2dcf26fe46eb6a
Related: OS#2872
In MSC_Tests.default we expect /tmp/mncc.sock as MNCC socket path -
let's match this expectation with osmo-msc.cfg to make sure that tests
work out of the box without the need to use specific command-line
option.
Change-Id: I540645ef4b1e08d05b89251f074af84a516e7a88
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before
the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a
few corrections of the VTY command format.
Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
This would allow to expect a MT SMS message using f_mt_sms_expect()
and send an RP-ACK using f_mt_sms_send_rp_ack() separately in the
follow-up changes for SMS over GSUP.
Change-Id: I4730634a9f3352b6f8553ee2fd1d43044f41241e
This would allow to submit an SMS message using f_mo_sms_submit()
and wait for RP-ACK using f_mo_sms_wait_rp_ack() separately in the
follow-up changes for SMS over GSUP.
Change-Id: I5b35206286ae8add8b5bd34b0ab41ba7862c28e4
The idea of this test case is to verify SS session termination
due to expiry of its guard timeout. The timeout value is
intentionally set to a few seconds in order to speedup
test case execution (we don't want to wait 2 minutes).
We expect OsmoMSC to inform both session entities (MS and EUSE)
about timeout expiry before releasing the transaction. The MS
should receive GSM 04.80 RELEASE COMPLETE message with optional
cause, while the EUSE should receive OSMO_GSUP_MSGT_PROC_SS_ERROR.
At the moment, it's not clean which cause values should be used:
- for GSM 04.80 RELEASE COMPLETE the cause IE is optional,
and possible values are defined in GSM TS 04.08, annex G-H.
The H.6.7 Cause No. 102 "recovery on timer expiry" seems to
be suitable;
- for OSMO_GSUP_MSGT_PROC_SS_ERROR the generic cause IE could
be used, but actually this IE is not generic at all, and
limited by 'gsm48_gmm_cause' enum;
so we temporarily expect arbitrary cause values in both messages.
Change-Id: I3e1791773d56617172ae27a46889a1ae4d400e2f
Depends-on: (OsmoMSC) Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related: OS#3655
MSC tests were unable to match odd-length digit strings in
a CallingPartyBCD_Number template created by tr_Calling().
This happens because the raw encoder for CallingPartyBCD_Number
pads odd-length digits with 1-bits ('F'H). Do the same when
constructing such a template in our own code to ensure that
we'll match the actual data received.
Change-Id: I34439c8750f588802a5403375e2a3d6e74dae70c
Related: OS#2930
This function can now be called from anywhere to try and safely shutdown
a testcase. It is not optimal as we can't call "all component.stop" from
outside the mtc, but without any proper and orderly shutdown handling of
all our emulation components I believe this is the best we can do.
To use it:
import from Misc_Helpers all;
in your module and then call
Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
You can also pass the function a verdict and a message and it will take care
of calling setverdict, but beware of the following:
While setverdict would accept any number of arguments as log message
and convert them to a log string f_shutdown expects one charstring.
It's possible to use the log2str function to use the log arguments in
setverdict for f_shutdown, for example
setverdict(fail, "Template didn't match: ", tmpl_foo);
would become
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo));
Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
The mncc guard timer in osmo-msc expires after 180 sec. This tests
terminates early and fails. Lets expand the timeout in order to give the
test a chance to pass.
Change-Id: I9f954a8807c0f0513422693ac24c647da0bfafd1
Related: OS#3599
Add f_gen_handover_req() like f_gen_ass_req(), to match AoIP or SCCPlite
requirements.
For incoming HO, MSC_ConnHdlr needs to know the SCCP addresses to expect the
incoming SCCP Connection from MSC to BSC. Add 'handover' section to
TestHdlrParams, and pass in the addresses from test_CT via that.
In osmo-bsc.cfg, add a remote neighbor config, so that the VTY command
'handover any to arfcn 123 bsic any' can trigger an outgoing inter-BSC HO.
Add various BSSMAP handover templates to BSSMAP_Templates.ttcn.
Add RR Ho Command template to L3_Templates.ttcn.
Move ts_BSSAP_Conn_Req() from msc/BSC_ConnectionHandler.ttcn to
library/BSSMAP_Emulation.ttcn, so we can also model an SCCP Connection Request
in BSC_Tests.ttcn (this time from MSC to BSC).
Add the two new tests to bsc/expected-results.xml.
Related: OS#2283
Change-Id: Id22852d4be7f127d827e7a8beeec55db27c07f03
After osmo-msc I73c7cb6a86624695bd9c0f59abb72e2fdc655131, osmo-msc
sends a BSSMAP Classmark Request if encounters a missing Classmark,
which is the case during LU when A5/3 is enabled.
Fix this test by answering the Classmark Request, if any.
Change-Id: I25578c050b7e105ed71b064891d4cd418ee30fcf
I was able to reproduce the sporadic cr_before_reset failures by running
both osmo-{stp,msc}-master with --cpus 0.1. In that case the first test
run would fail for me because no BSSMAP RESET ACK was seen. Sleeping
some seconds before sending the messages will make sure all components
are connected.
Note: TC_cr_before_reset is the first test executed in control so this
seems to be why it sometimes fails in jenkins.
Change-Id: Id745470231950e0a284f8c231246d3719f7617cc
These tests were expecting two ClearCommands, but the MSC will
only send one. Remove redundant calls to f_expect_clear() outside
of the alt step. The expected ClearCommand is received inside the
alt step.
Change-Id: I77f189d9050a06fe6eac457312285cf173c842d5
This function starts the SCCP component which will relay the BSSAP
messages to/from port SCCP_SP_PORT which is connected to BSSAP_DIRECT.
Ticket: OS#3286
Change-Id: Icee085d5fe610061c85d7fe7cf62cbccd8cfa556
The idea of this test case is to check the reaction of OsmoMSC
on MS-initiated release during an active transaction. In other
words, when the network is waiting for some response from a MS,
subscriber can press the 'red button' in order to terminate
this conversation.
It is expected that the MSC would terminate the transaction
as on DTAP interface, as on GSUP interface.
Change-Id: I7936ed5072ed2ae02f039dc90a1fece1e7f70a70
This change introduces two new test cases for network-initiaded
USSD notification and network-initiaded USSD request, which are
based on the existing SS/USSD related test cases.
The idea of TC_lu_and_mt_ussd_notification is to verify that
a network-initiaded USSD notification can arrive subscriber in
IDLE mode using Paging procedure.
The idea of TC_lu_and_mt_ussd_during_mt_call is to verify that
a network-initiaded USSD notification can arrive subscriber in
DEDICATED mode (in this case during a call) on a separate
transaction.
Change-Id: I073893c6e11be27e9e36f98f11c1491d0c173985
As we are about to finish the implementation of GSM TS 09.11,
OsmoMSC will forward all SS/USSD messages over GSUP to HLR,
and will expect responses back from HLR. The SS/USSD payload
processing will be out of scope for OsmoMSC itself.
Let's modify the existing test cases in order to expect and
reply SS/USSD messages over GSUP protocol.
Change-Id: I01de73aced6057328a121577a5a83bc2615fb2d4
In order to avoid code duplication in the upcoming test cases,
let's introduce a few functions which basically do a GSUP/DTAP
message matching within the alternative statement.
Change-Id: I846c2d40a7c37afa8647e644673b4df905e3e116
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Teach the function f_vty_wait_for_prompt() about connection
reports by the TELNET module. We may now receive an integer which
represents the socket file descriptor for the telnet connection.
This case was not handled by the previous change made in
commit cb111b21ab. As a result,
BSC tests started failing with "VTY Timeout for prompt" because
the alt-statement in f_vty_wait_for_prompt() would not progress
past the integer sitting on the VTY port's receive queue.
Change-Id: I56925f93af6c55e93f3f417099db135744da6a40
Related: OS#3149
With this patch, I see all ttcn3-bsc-tests failing with
"Verdict: fail reason: VTY Timeout for prompt"
This reverts commit cb111b21ab.
Change-Id: I215d7ab5eee75cf6d3afaac760af64356c943140
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Change-Id: I9acf7793d5d68aec6d087cff254a10d8b673dab1
Related: OS#3149
The random length for that test could go out of bounds leading to a
Dynamic test case error when sending the message.
The limiting field here is the lengthIndicator of PDU_BSSAP which
includes the length of the PDU_BSSMAP mesageType, cellId as well as the
layer3 info IE and lenght indicator additionally to the l3info payload.
So maximum length for the payload can only be 240 bytes (if the cell ID
is encoded in the longest possible way as BSSMAP_FIELD_LAC_RNC_CI).
Change-Id: I7be33e261a11f03a80a6b770b6acf0a4be49b85b
This test suite acts as an SCCP server on top of M3UA.
SCCP tests are run against the sccp_demo_user program which
can be found in libosmo-sccp/examples. This program must be
started in client mode: sccp_demo_user -c
The SCCP test suite should then work out of the box with
the provided SCCP_Tests.cfg file and this additional change
to sccp_demo_user default point codes:
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9652/
There is currently only one test, for the libosmo-sccp crash
reported as issue OS#2666. The implementation of this test
is currently using an ugly workaround due to shortcomings of
the M3UA Emulation layer (see source code comments). Whether
a better solution is feasible is still to be determined.
The test requires a patch to the SCCP Protocol Emulation which
has been submitted upstream: https://git.eclipse.org/r/#/c/124552/
Change-Id: I03f5e8b282a7396b45417495c88d8fb81b26cda8
Related: OS#2666
BSC_ConnectionHandler.ttcn:563 This helps TC_gsup_cancel which
previously encountered a Dynamic test case error: Using the value of an
optional field containing omit. The test still fails, but this time
because it "Received unexpected BSSAP instead of CM SERV REJ".
Change-Id: I9fedf2573487066b951804a328ba428d2189c4a4
Call mtc.stop after setverdict(fail), add reasons to most failures and
fail with verdict error for internal errors.
Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
The test currently crashes osmo-msc, which is fixed by
I5c30e0f9545fb76615776ff6cc16b56aeb5b043a (osmo-msc).
Related: OS#3062
Change-Id: Ic80646e1fba37bb6163ca3a7eead7980b4ad7a51
Overlong IMSIs used to trigger an assertion failure in osmo-msc.
This problem has been fixed but there was no test for it yet.
A lazy way of testing for this problem is to send an overlong IMSI
from an existing test which already verifies related behaviour
and would fail if the MSC crashed: TC_lu_by_tmsi_noauth_unknown
However, osmo-msc currently accepts overlong IMSIs and silently
truncates them, so this change as-is currently breaks this test.
But I would argue that osmo-msc's current behaviour is unreasonable
anyway and have proposed a patch to change it:
https://gerrit.osmocom.org/#/c/osmo-msc/+/9739/
With that patch applied to osmo-msc, this test keeps passing.
Change-Id: I2c472bee76086f6c84ec684d2e58b3351ebc3147
Depends: I785c994f41a646d8d83d3d82f5a9ae6b572eb641
Related: OS#2864
Related: g#9739
As we are about to finish the implementation of GSM TS 09.11, in
our case it is 'SS/USSD over GSUP', OsmoMSC will not decide itself
which USSD request-code is known, and which is wrong.
Change-Id: Ic104a49bb2dce2127063bcef8443ee6b639c9f19
PARALLEL | VERDICTOP will log when the port is dying or when other
components will change to fail. This helped to find a timeout in the
SGSN tests where a function call message timed out.
Change-Id: I770ac964dc37e2752e7d35e493f707b091c739b0
The idea of this testcase is to check if MSC can correctly
handle a USSD-request during an active call.
What we do here:
1) Perform Location Update
2) Establish a MT-call
3) Perform *#100# request
4) Release the call
Change-Id: Ifa3cd1aeeb34ccf5864f78b76a88aaa6d5e51839
The idea of this testcase is to check reaction of the network on
reception of USSD request with unknown/unhandled request code.
It is not clearly defined by the GSM specs, how the network
should react in such cases, but looking at GSM TS 04.80,
section 4.3.2 "Error types description", the UnexpectedDataValue
error looks suitable. Commercial networks also use this error
when an unknown request code is sent.
Change-Id: I6a3fcaafc37972a38c13722f0b511ea5e1e3fbd8
In this testcase we perform LUR, then request our own number and
then expect the response with matching MSISDN.
Change-Id: I82450c6f48f6c17bc33e0ec6c91f2a73e44793ad
Update MSC_Tests.default according to the current MSC_Tests.cfg
used by docker-playground.
Add osmo-msc.cfg and osmo-stp.cfg example configuration files.
Allows the MSC tests to be run locally.
Change-Id: Ia00f0315a5246c3ec55563ebd21a586aec8e4688
The test case TC_establish_and_nothing is now passing.
Update expected results list accordingly.
Change-Id: I925fa4ad2e38e189cf5dd1ae76a24cdb9011fdc8
Related: OS#2879
The many SS_* types depend on MAP, whcih in turn depends on ROSE.
Add all of this to the MSC testsuite so we can do SS related testing.
Change-Id: If5084decb5391736ab5cadd86adb2ffa78e7140f
In non-handler mode, the SCCP emulation is currently started before
there's a user registered to SCCP_SP_PORT. If the first BSSMAP
package arrives from the network, then the SCCP_Emulation will crash
as it cannot deliver the resulting SCCP user primitive to the user.
Let's split start from initialization, so user code can still register
something to SCCP_SP_PORT before starting SCCP_Emulation.
Change-Id: I55c94f18531bb7e5369500dc90f4b0ff3a420774
This should fix the bogus failures we are seeing in this test. The pcap
usually shows that the Clear Command does arrive after about 5 seconds,
but sometimes the internal timer fires before that. Double the timeout
of the test here.
Change-Id: I998cfb52a3813dd9f76d3787e4d0d448752ec847
With f_init(), the user has the option to specifiy how many bsc
instances should be created. A for loop then iterates over the
prepared configurations and calls f_bssap_init(). The first
parameter g_bssap is tied to index 0 constantly but should be
tied to the iterator i.
- use i instad of 0 as iterator for g_bssap
Change-Id: I490bab70224d236ab576a2ea3863f6d0afd5f22a
In addition to the existing 3GPP AoIP stacking, allow BSSAP to
run on top of a SCCPlite stacking. Implement both the server and the
client role for IPA.
Related: OS#2544
Change-Id: Ie844c4de62e0ef5d5c4c366185968211a7f6d676
In Change-Id I52a4c8118828c1605cf672889982f987568ad17d we introduced
a name change for the SCCP/M3UA components, which meant that the log
level configuration did no longer apply as intended.
Change-Id: Iebdaf3446a81ea5f8310110f5cca2bdb3e552e3f
The L3 transaction-id in MT-SMS is allocated in the MSC, so any
messages we expect from the MSC must carry c_TIF_ORIG.
Change-Id: I6ea977a7662fdfc9c504f13ac5632ac20a04f522
'make clean' as generated by ttcn3_makefilegen removes all *.log files, which
of course cleans out expected-results.log, which should not happen. Since this
is a junit XML file, rename the suffix to .xml.
Change-Id: Ic334f6b758eef865e3a497aa430691a3ae696d25
The testcase intentionally responds to the RAN sided CRCX
with a garbeled message to cause the MGCP handlin inside
the MSC to fail. The MSC is then expected not to perform
further MGCP operations since it did not get a proper
response to the first CRCX, so the specific endpoint name
is not known, eventually preventing from doing an MDCX.
However, the testcase responds to incoming DLCX commands,
instead setting the verdict to fail.
Also the altstep that dispatches the message after the
errornous MGCP response unconditionally catches all BSSAP
messages before entering the sub-altstep
as_clear_cmd_compl_disc() that handles the clearing of
the connection. Eventually the clear command is never
received in this sub-altstep.
- Make sure the verdict is set to fail when an MGCP
message is received after the errornous response to
the CRCX.
- Remove the unconditional BSSAP.receive in order to
be able to dispatch the clear command properly
- Update the expected-results.log file
Change-Id: I806491741d310e4410f6cb4ce0309235e9bf4300
Related: OS#2882
When the MS sends a Clear Request in the middle of a Location Updating, it
should be permitted for the MSC to send a Location Updating Reject back. Extend
with an alt that also allows a LU reject before the Clear Command.
The test explicitly hints at https://osmocom.org/issues/2862 which rightfully
forbids the MSC to send a second Clear Command after the first is completed.
However, this test so far explicitly permits a second Clear Command, so it was
probably passing in error all the time. Set verdict to failure if a second
Clear Command is received before the DISC_IND.
This changes the test verdict to failure with current osmo-msc master,
rightfully so; the failure will be fixed by the upcoming MSC subscr conn FSM
refactoring.
Change-Id: I7bc5555b829d61b0a2529107bc9b58446865545d
Compare current test results to the expected results, and exit in error on
discrepancies.
Add compare-result.sh: (trivially) grep junit xml output to determine which
tests passed and which didn't, and compare against an expected-result.log,
another junit file from a previous run. Summarize and determine success.
Include an "xfail" feature: tests that are expected to fail are marked as
"xfail", unexpected failures as "FAIL".
In various subdirs, copy the current jenkins jobs' junit xml outputs as
expected-results.log, so that we will start getting useful output in both
jenkins runs and manual local runs.
In start-testsuite.sh, after running the tests, invoke the results comparison.
Due to the single-line parsing nature, the script so far does not distinguish
between error and failure. I doubt that we actually need to do that though.
Related: OS#3136
Change-Id: I87d62a8be73d73a5eeff61a842e7c27a0066079d
In Change-Id: I52a4c8118828c1605cf672889982f987568ad17d we introduced
config file syntax errors. It seems that change was not tested at all
before pushing :(
Change-Id: I80577798b502957afaa46abb510bcca3dc174ee4
The upcomming tests for inter-BSC handover make it necessary to
simulate multiple (two) BSCs to the MSC, while the current
Implementation can only handle one BSC instance at a time.
- Allow multiple BSC instances to be created
- Add a simple reset-test to test what happens when
two BSC instances are started (BSSMAP reset from two
different BSCs)
Change-Id: I52a4c8118828c1605cf672889982f987568ad17d
Related: OS#1609
The MMSC_Tests.cfg config file lacks most of the test comments.
- make sure the control section of MSC_Tests.ttcn and MSC_Tests.cfg
match up.
Change-Id: I89e6c65427a993261cab6a284e6cc3dbc5a5562f
The functions f_mt_call and f_mo_call establish a call, hold it
for 3 sec. and tear it down again. However, there may be test
situation where one wants to establish a call and then hold it
in order to perform other actions.
- split up the function into an _establish and _hangup part.
- add a replacement f_mt_call and f_mo_call function for the
already existing testcases
Change-Id: I0da9cf64d10de4036eb037ef5e491bfe3088670b
The problem is that Junit-XML doesn't have a mapping for inconclusive
results, and hence they show up as 'passed'.
By introducing this change, we make sure all tests that don't pass
show up as failed.
Change-Id: Iddd13d0055c91f9bd304ce9833fba0485abf4c4e
Test the reaction of osmo-msc when the DLCX at the end of a call
is not answered. Normally osmo-msc should time out and clear the
connection.
Change-ID osmo-msc:I78f1b6a9149488a4ad3f120c1e190a83c07d4b89 fixes
a regression that causes osmo-msc to segfault due to a use after
free. This testcase provokes the situation that leads to the
crash.
Change-Id: Ic124ea116496209f9a1d8e74ae3e3a36cf866db0
Related OS#2881
Related OS#2882
Not all tests were waiting/expecting the complete connection
shutdown, which results in the possibility for CLEAR CMD to arrive
during shutdown of the TITAN components and cause related errors.
Change-Id: I3a6c2e1f78b58f86ef84d4e323f432016a9afa7e
It may very well be that the MSC is first accepting the SCCP connection
and possibly sending a L3 (error) message before clearing/closing
the SCCP connection in case of errors in the COMPL L3 info.
Change-Id: I4cf08608413e9e1fb54848849baed79204f5dcd1
Until recently, OsmoMSC didn't distinguish 2-digit from 3-digit MNC,
and the config file states '42' as MNC while the tester used '042' in
several locations. This causes almost all MSC_Tests fail with recent
osmo-msc.
Let's fix the tests to use '42', as they should always have.
Change-Id: Id02bfd74127cf5551923912934240035106a8a4e
Originally, this code was not yet in an official upstream git repo.
However, it has been for many months, so let's remove our local copy
and use upstream git repositories like for all the other modules.
Change-Id: I2c616fb865df32cfec323d42e5d0d06de40c497b
Add another macro ignore_pp_results to gen_links.sh.inc and call from all
gen_links.sh files, to add results of *.ttcnpp files, i.e. generated *.ttcn
files, to .gitignore.
Change-Id: Ic7fb176226771212d7700dafaf27ac71f12a4a61
Provoke a timeout error in the MGCP FSM which then triggers a
release on the CC layer. Ignore this release and let the CC leyer
timeout. The MSC is expected to clear the SCCP connection.
Change-Id: If3e0bee11763f1c6b2cfae91f2a818ff7d0df9e7
Related: OS#2881
Related: OS#2882
The following tests still lack support for wildcarded endpoints:
MSC_Tests.TC_lu_and_mo_call
MSC_Tests.TC_emerg_call_imsi
MSC_Tests.TC_mo_crcx_ran_reject
MSC_Tests.TC_mt_crcx_ran_reject
- Also add support for wildcarded endpoints for those tests.
This is a follow up patch for:
Change-Id I0efeae0f8a6e98deb843e79648f84a262f1d98f8
Change-Id: I16cb2582b9d1764d7cb7e4b787368a4dd5ddf69c
Related: OS#2710
In each subdir that is a target for symlinks, automatically ignore the results
of gen_links():
- At the top of gen_links.sh.inc, clear the .gitignore.
- In the loop, add each link name to the local .gitignore.
- In selected gen_links.sh, there is also a "manual" link creationg. So that
this also ends up in the local .gitignore, have the link creation as separate
gen_link() macro which at the same time adds to ./.gitignore.
- in the root .gitignore, ignore all the subdirs' generated */.gitignore files.
Change-Id: I73c11fe8362358bf7e1bdf0e1be53399b5d3351b
First of all, use one common place to define the gen_links() macro, in
gen_links.sh.inc.
In this new file, add a 'shift' to exclude the $DIR arg from also appearing in
$FILES.
This prevents the following wrong symlinks in the source dirs:
M3UA_CNL113537/src/src
MTP3asp_CNL113337/src/src
SCCP_CNL113341/src/src
Change-Id: Ia8493e77df1ba8723f2c5d2a49816247b0fb55f7
At the moment the testsuite is unable to detect when the call agent
performs a CRCX request with a wildcarded endpoint.
- Set a default endpoint name in cpars in case the MSC does
a CRCX request with wildcarded endpoint name.
- Detect if the MSC supplied a wildcarded endpoint name. Do
not overwrite the default setting in cpars then.
- Attach the endpoint name as Z: parameter in the response so
that the MSC knows which endpoint to use. (Unconditional,
does not harm on non wildcarded requests)
Change-Id: I0efeae0f8a6e98deb843e79648f84a262f1d98f8
Related: OS#2710
The testcase TC_mo_crcx_ran_timeout does not respond to the BSSMAP
relase request that is sent when the MGW times out.
- Acknowledge the release request before waiting for the MSC
to clear the SSCP connection
Change-Id: Ifcf9ebd2cc5184524ecae735257ed12a0ca70f71
Related OS#2881
Related OS#2882
This testcase triggers a bug in the BSSMAP reset logic that tricks
the MSC into a deadlock situation. The bug can only be triggered on
a freshly started MSC, otherwise the testcase will not have any
effect at all. That's why it its important that this is the first
testcase to be executed. If the IUT (MSC) is still affected by the
bug. It will enter the deadlog situation and all subsequent testcases
should fail until the IUT (MSC) is restarted. The matching real-life
scenario would be that the MSC restarts. The BSC is not informed by
the restart, so it continues to make connections (which fail) until
it notices that the MSC was down and the execution of a BSSMAP reset
procedure is required.
See also Gerrit Change Id:
I3fdcec5dbeaa0e21fd6a92568a623faa368239be
Closes: OS#4120
Change-Id: I1d7575e5bec9edabcc832c754d19dc5ba489861a
To trigger the segfault described in OS#2947, run TC_lu_imsi_auth_tmsi_encr_3_1
with logging category for MSC to set to debug.
Change-Id: I72a1dbb30e0a39dbf4b81c7e378d5607b62e10d3
This is a variation on TC_lu_imsi_auth_tmsi_encr_3_1 that "indicates" inability
of A5/3 by completely omitting a Classmark2.
Add flag send_cm_update to f_tc_lu_imsi_auth_tmsi_encr_3_1() so that we can
easily omit the classmark update. Set this flag to true in existing
TC_lu_imsi_auth_tmsi_encr_3_1, and add pass false from the new test.
Change-Id: I903136d5acbd88f2e0e26fee22e3878258e04786
Previously, f_start_handler() would initialize the BSC_ConnHdlrPars instance,
making it impossible to change those parameters before the test function was
invoked.
Add separate f_init_pars() function that sets the default parameters.
Change f_start_handler() to take a BSC_ConnHdlrPars argument; i.e. that
f_init_pars() can be called first, the parameters can then be modified and
finally fed into f_start_handler().
Change-Id: I46de36a032c2473025d0eb01e5909dbcdaf394f7
By moving to the BSC_ConnHdlrPars, also the tests that expect a LU failure able
to indicate a send_cm_update flag.
All current callers of f_perform_lu() pass send_early_cm as 'true', all are
covered by a default of 'true'.
Change-Id: Ic882293f199a33133a171bff14ff433f99cc8576
Let's use the preprocessor to avoid IPA_Emulation pulling *all*
dependencies into each and any of our projects. The code readability
suffers a bit from the many #ifdefs, but compilation speed increases
if we don't have to pull in all those (recursive) dependencies.
After all, a BTS test case will never need SCCP, GSUP or MGCP.
Change-Id: Ic0231adbd2171214de133d26b3fbf36130ee8aa0
Channels not being closed/cleared at the end of the test is a clear
failure, so don't mark the test as inconc.
Change-Id: Ie9188111da744f0aafaac02841d36a957bfc8d86
Let's make sure we share common configuration between the test
suites and split the config file into a "default" part which is
used (but not copied) in the Docker images, and a "local" part
which is basically those overrides that the user (or docker image)
wants to do from the default.
Change-Id: I3db452e24e5238aa05254d903739c64d202e61db
This fixes TC_emerg_call_imsi with current osmo-msc master. The old
implementation was broken as it didn't deal with MGCP yet.
Change-Id: Ic35797931387b078205269365421ad730db7af15
Neels Hofmeyr
Pau Espin
Philipp Maier
Oliver Smith
Harald Welte
Daniel Willmann
Neels Hofmeyr