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
Vadim Yanitskiy
Daniel Willmann
Philipp Maier
Harald Welte
Neels Hofmeyr
Pau Espin