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
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
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before
the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a
few corrections of the VTY command format.
Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
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
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
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
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
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
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
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
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 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
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
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
Vadim Yanitskiy
Philipp Maier
Harald Welte
Daniel Willmann