When stopping the test TC_two_crcx_and_unsolicited_rtp the unsolicited
RTP stream is not stopped. As a result it could happen that between
tearing down the other flows and stopping the test an unsolicited RTP
packet is sent to a closed socket.
The resulting ICMP destination unreachable packet translates to a
"Connection refused" error on the sending socket and fails the test.
Avoid this by making sure the unsolicited RTP sender is stopped before
stopping the test.
Change-Id: Ied839596589609e75fa487046a85db48991e4c73
Previous RA value (23, Establishment cause = 0010XXXX) meant MS was dual
rate capable but was asking speciifically for only TCH/F channel. As a
result, TCH/H was not being allocated and an immediate assignment reject
was sent.
Change-Id: I3e58592c661fc004e648dbe46b67a3b3f5a20bc8
The I3e1791773d56617172ae27a46889a1ae4d400e2f was merged before
the Icf4d87c45e90324764073e8230e0fb9cb96dd9cb, and there were a
few corrections of the VTY command format.
Change-Id: Icd1133ca9f46bc2a9302deebb1e401862cf672cb
When an internal handover is performed, the BSC is expected to inform
the MSC about the event by sending a BSSMAP HANDOVER PERFORMED message.
This feature was missing in the BSC and has now been added. The tests
need to be upgraded in order to handle the additional message.
- Upgrade f_tc_ho_int so that it expects a HANDOVER PERFORMED message
Change-Id: I10f4e578c96a90317939ba49b61b14a3c7e488a7
Depends: osmo-bsc If26e5807280e0f75a423b3b04f8e3c698c82a351
Related: OS#3645
TC_paging_resp_unsol spent some time in gerrit before being merged. As a
result, other commits were merged in between the test was submitted (tested)
and merged. As a result, commit a5302c8151
was merged while this test was still in gerrit and thus was not updated
accordingly.
Similar stuff happened with the osmo-bsc commit fixing the scenario this
test was showcasing: The osmo-bsc patch (77cd1129931928d2a6e7667d0374feeeed71b0ce)
had merge conflict with other osmo-bsc commits merged in-between,
and was merged even later than the commit introducing this TTCN3 test, so
failures were expected for this test for a while.
Change-Id: I933cba41912640eb7e15be4a27bda5b4dd489962
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
According to 3GPP TS 29.002, section 12.4, MAP-READY-FOR-SM is
used between the MSC and VLR as well as between the VLR and the
HLR to indicate that a subscriber has memory available for SMS.
This change replicates this service in GSUP as READY_FOR_SM_*.
The only mandatory IE for this service (excluding Invoke ID) is
'Alert Reason' that is replicated by OSMO_GSUP_SM_ALERT_RSN_IE.
Change-Id: If2256607527ecfcb10285583332fb8b0515d7c78
Related: OS#3587
According to 3GPP TS 29.002, there are two services:
- MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2),
- MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9),
which are used to forward MO/MT short messages.
This change replicates both services as GSUP messages:
- OSMO_GSUP_MSGT_MO_FORWARD_SM_*,
- OSMO_GSUP_MSGT_MT_FORWARD_SM_*.
Please note, that only the 'must-have' IEs are introduced
by this change, in particular the following:
- OSMO_GSUP_SM_RP_MR_IE (see note below),
- OSMO_GSUP_SM_RP_DA_IE (see 7.6.8.1),
- OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2),
- OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4),
- OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7),
- OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4),
where both SM_RP_DA and SM_RP_OA IEs basically contain
a single nested TLV of the following format:
- T: identity type (see 'GSUP_SM_RP_ODA_IdType'),
- L: identity length,
- V: encoded identity itself.
According to GSM TS 04.11, every single message on the SM-RL has
an unique message reference (see 8.2.3), that is used to link
an RP-ACK or RP-ERROR message to the associated (preceding)
RP-DATA or RP-SMMA message transfer attempt.
In case of TCAP/MAP, this message reference is being mapped to the
Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not
required for other applications (other than SMS), this change
introduces a special 'SM_RP_MR' IE that doesn't exist in MAP.
Change-Id: Ibf49474a81235096c032ea21f217170f523bd94e
Related: OS#3587
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
In general, the order of IEs in a GSUP message doesn't matter.
Despite libosmocore's GSUP API encodes IEs in a fixed order,
it is capable to decode them in any arbitary order.
Meanwhile, in the current TTCN-3 definitions (i.e. templates)
the order makes a difference, because the 'GSUP_IEs' type is
a record, that according to the TTCN-3 documentation represents
an *ordered* sequence of elements.
Let's reorder the IEs of both t{r|s}_GSUP_PROC_SS_ERR templates
in a way that is used by the libosmocore's GSUP encoder.
This correction doesn't affect successful test case executions,
because we don't test possible problematic situations yet. But
if something went wrong on the HLR side (i.e. SUT), the matching
statements wouldn't match the PROC_SS_ERR message correctly
and continue to wait until the guard timer is expired.
Change-Id: I5eb2314f6a9ab0e9fc5e836390414cec6e1a12db
Both session state and session ID IEs are always being encoded
together by libosmocore's GSUP implementation. So, if a message
contains a session ID IE, session state IE shall also be there.
For some reason, the session state IE was missing in both
ts_GSUP_PROC_SS_ERR and tr_GSUP_PROC_SS_ERR templates. This
could led to incorrect matching in our test cases.
This change fixes both templates by adding the missing IE. Since
tr_GSUP_PROC_SS_ERR templete is used in HLR_Tests.ttcn, all the
affected matching statements were also corrected.
This correction doesn't affect successful test case executions,
because we don't test possible problematic situations yet. But
if something went wrong on the HLR side (i.e. SUT), the matching
statements wouldn't match the PROC_SS_ERR message correctly
and continue to wait until the guard timer is expired.
Change-Id: I44070396ce7119eab4608d9f9fb090bb223dfaa2
As at the moment, OsmoHLR doesn't support "structured" SS, such
requests are being rejected. This test case aims to verify that.
Change-Id: I147b919d0242b3b44e39a4587bf1b4660fa58bd2
Related: OS#3651
The idea of this test case is to verify channel deactivation
procedure due to no response to Immediate Assignment.
Change-Id: I00b0838c9f919303aef72280248b0d1317f42b3b
Related: OS#3709
With this test we want to verify that channels are released if BSC fails
to complete an L3 request, for instance because no pending Paging
CMD is found for a received Paging Response.
Related: OS#3680
Change-Id: Iabe8a51aa13d2fcfec4500cf7aab47d60cc138ce
With some real HW setups, there's no PCU (osmo-pcu) available locally,
for instance when using a sysmobts, or when using a nanoBTS. There's no
need to waste time and generate extra output by running this tests in
this case.
Furthermore, some tests seem to crash sometimes in that setup, probably
due to using invalid fd (-1):
MTC@801a0da9866a: Setting RSL_SYSTEM_INFO_4 (4): '31061C62F224002A4740E50400'O
/osmo-ttcn3-hacks/bts/BTS_Tests: Segmentation fault occurred
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7f0c33b48073]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7f0c321aa060]
/osmo-ttcn3-hacks/bts/UD_PT.so(_ZN12UD__PortType15UD__PT_PROVIDER13outgoing_sendERKN9UD__Types14UD__send__dataE+0xf0)[0x7f0c349e42f8]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_17PCUIF__send__dataERK9COMPONENT+0x19e)[0x7f0c37e1731a]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_26PCUIF__send__data_templateE+0x5f)[0x7f0c37e174f7]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests20f__TC__pcu__act__reqERK7INTEGERS2_S2_RK7BOOLEAN+0x411)[0x7f0c3eec3210]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests28testcase_TC__pcu__deact__reqEbd+0x15d)[0x7f0c3eec4f27]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(+0xfb65d)[0x7f0c3eeef65d]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN11Module_List15execute_controlEPKc+0x1c)[0x7f0c33af3fbc]
Change-Id: I773c7ec52dd8532bf160e92ffefc8d936ca55de2
tr_BSSMAP_HandoverPerformed matches all optional fields on "omit". This
does not make much sense as a safe default. Lets match on "*" instead.
(See also other tr_ templates)
Related OS#3645
Change-Id: Icd55afdaebdda8ba98431f358148035f7d220b8a
Implement a basic paging test for the PCU, which is passing for paging
via TMSI (but only if osmo-pcu is started after the test is started).
Previously, this test code amounted to a debugging loop which
never terminated.
Change-Id: Id0384e0742ab91983615e4f1c883bb044c1c8b18
Related: OS#2404
It's useful to see which BTS exactly has failed the test in
configuration with multiple BTS on single BSC.
Change-Id: Ib813635862c04d51a30e7bbcca4ec05ce664f7e9
tr_BSSMAP_HandoverPerformed lacks the field speechVersion, lets add it
to make the template complete.
Change-Id: Id73c0aef5caa0936aa44308faf2aae1c20c7446c
Related OS#3645
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
Previously the expectations for number of CRCX and MDCX messages from
MGW was adjusted unconditionally for LCLS tests. However this is only
necessary for MGW-loop type of LCLS. Use explicit variable (with default
value preserving current behavior) to decide whether to apply this
adjustment or not. This simplifies support for other kinds of LCLS
loops.
Change-Id: I07b2c56991977b5e80c372a5b8338f348f14c076
Related: OS#3659
Move duplicated code into separate functions to simplify adding test
cases which do not use MGW MDCX methods for closing the loop.
Change-Id: Idf9fc8e639b0ece662ab26c481899ef39fb7edfe
Related: OS#3659
Add two helper functions which retry a VTY command until the
result matches a regular expression or a configurable timeout
expires.
Use these functions in BSC test's f_ts_dyn_mode_get, which has
seen sporadic failures due to a race condition during channel
reconfiguration, in order to hopefully close this race.
Change-Id: I308ddb06e440c165fe1e73fe2c1fb78be2e1d510
Related: OS#3690
Instead of vaguely allowing any release messages to be present or not, exactly
pinpoint for each test case the exact release messages expected during lchan
release.
Related: an osmo-bsc change broke sending of RR Release messages, which was
utterly ignored and hence not caught by ttcn tests. That must not happen again.
I am not actually sure that these expectations are 100% correct; if errors
become apparent, we shall change the expectations in ttcn3 and then fix
osmo-bsc according to that.
Adjust f_expect_chan_rel() and callers,
and the Assignment procedures (as_assignment and f_establish_fully).
The current state of the bsc tests should all pass with osmo-bsc
Id3301df059582da2377ef82feae554e94fa42035
Related: OS#3413
Change-Id: Ibc64058f1e214bea585f4e8dcb66f3df8ead3845
Allow osmo-bsc sending a Deact SACCH messages in most cases. Prepare the
ttcn3-bsc-tests to not break just because of those messages that will soon be
sent.
When releasing an lchan, it makes sense to Deactivate SACCH on it, if it was
ever active. So far osmo-bsc was fairly reluctant to send Deactivate SACCH, but
osmo-bsc Id3301df059582da2377ef82feae554e94fa42035 is about to change that.
In most test cases, Deact SACCH are still optional, but in one case, the
current missing Deact SACCH will introduce a test failure: in the 'interleave'
of BSC_Tests.TC_ho_out_fail_no_ho_detect.
As soon as abovementioned osmo-bsc patch is merged, the test will pass again.
Also, as soon as Ibc64058f1e214bea585f4e8dcb66f3df8ead3845 is merged here, the
bsc tests will properly ensure whether Deact SACCH is sent or not in all tests.
Change-Id: I27da24dbe3184fa7a076a35f6fa6af457c1db8d2
Receive RR Release messages if they happen during lchan release. Add RR Release
to the alt{}s in both f_expect_chan_rel() to cover a whole bunch of test cases,
and in f_tc_ho_out_fail_no_ho_detect() which has its own release expectations.
Before this, RR Release messages would typically be lost in the RSL.clear
recently removed by Ie1be30c3f109dda8c58c523df508211f8e20aad3.
However, I still expect tests to pass after this, since the current osmo-bsc
master has a bug that omits RR Release messages (since [1]).
By applying this patch, both the buggy osmo-bsc (omitting RR Release) and the
fix of that [2] should pass the BSC tests. So far by accepting whatever comes
along, and not complaining if it doesn't come along.
A subsequent patch will more precisely ensure that exactly the expected
messages will be sent by osmo-bsc (Ibc64058f1e214bea585f4e8dcb66f3df8ead3845).
[1] osmo-bsc I4fd582b41ba4599af704d670af83651d2450b1db
commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb
"subscr conn: properly forget lchan before release"
[2] osmo-bsc I666b3b4f45706d898d664d380bd0fd2b018be358
"fix: send RR Release (e.g. after BSSMAP Clear Cmd"
Related: OS#3413
Change-Id: I4e6d266d091b140f56b28312cb3c5d67ffcc3a59
Instead of placing an own set of channel release expectations, just use the
common f_expect_chan_rel() that exists for exactly this purpose.
This will also be in line with upcoming changes to tighten checking of the
lchan release messages.
Related: OS#3413
Change-Id: Ib7dd886472337e2deb968e6f9de6cecdb7855319
When we're expecting release, it can be non-deterministic / timing dependent to
flush the RSL queue. Particularly the RR Release message is typically already
in the queue when f_expect_chan_rel() is called and would be lost.
It turns out that none of the current callers need the flush feature.
If a test needs it, we can add a separate f_rsl_flush() function and call that,
no need to clutter up the f_expect_chan_rel() argument list. I had such
function but found that no caller needs it, so dropped it.
Related: OS#3413
Change-Id: Ie1be30c3f109dda8c58c523df508211f8e20aad3
The receive template for the BSSMAP HANDOVER PERFORMED MESSAGE is
missing, lets add one.
Related OS#3645
Change-Id: I527913203b2d5bfa26c181c4bb79481a9cd283ae
* remove unused parameters
* add expected results
* use control for default test execution
* only tests which could (in theory) pass are left in control
Previously generic control had some tests which never called
"setverdict(pass)" which means they would always fail. Such tests might
be useful during development but should not be part of test set executed
by default.
Change-Id: I91910e18f108f8ee9a3b76ced16c420fdbdb665a
Related: OS#2890
Some test env may take more than 10 seconds to (re-)start a BTS, so
let's make it variable through this parameter.
For instance it was observed that running osmo-bts-sysmo through ssh
inside a sysmobts can sometimes take a good number of seconds (specially
because ssh connection can take a while to be established successfully).
Change-Id: Ieb046358d8266ac94bd7b9e916e85f84de3ad319
Drop 'return' statements after 'mtc.stop' as they cause following
warning from TTCN-3 compiler:
warning: Control never reaches this statement
Change-Id: I6210ecf5fcb39f751116ad63a69d2ae8651a60c5
Check that channel number IE is present in the received message. This
fixes following warning:
The value returned by function `@RSL_Types.f_rsl_find_ie' is not used
Change-Id: Icc6824d7acef809d76c70b5ff060a8261a82e2be
Related: OS#3659
The osmo-bsc.cfg should work on localhost. Having arbitrary IP address
in it seems confusing and might lead to hard-to-debug errors.
Change-Id: Ideb8a78348af435f9992c42bce0bb197d1e73e04
We cannot notify RSL Emulation layer about expecting a specific FN
(during ts_RSLDC_ChanRqd) because we only know the FN after sending the
RACH request, and since notification to RSL Emulation happens async, it
can happen (verified) that ChanRqd message from BTS arrives and is
handled before we register the RACH req into the ConnectionTable.
Change-Id: I438fd3ee82d88498d928dbcc89ce9bd80d37ab64
There is no need to pass session state from f_main_mo() to a
choosen EUSE handler (e.g. f_ss_echo), because a handler
itself is capable to extract the session state IE.
Change-Id: I1054baf3e7dafd05b797610b586e6202740f07b6
Unfortunately all component.stop can not be called from the non-mtc
component. f_shutdown is a wrapper that will try to shutdown a test in
the best way calling all component.stop if it is called from the mtc and
just stopping the mtc if called from any other component.
Change-Id: I9b71f7f7bd70d2da21fbad60c340d5bf8b3b9536
Daniel Willmann
Pau Espin
Vadim Yanitskiy
Philipp Maier