From running this test repeatedly, I noticed that osmo-msc's new patch
to avoid storing a TMSI may also trigger more evil twin situations in
the VLR as described in OS#4721.
Always run this test twice, to probe for the evil twin problem.
This test will pass from osmo-msc patch
Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd on.
Depends: osmo-msc Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
Related: SYS#6860 OS#4721
Change-Id: I5e596597add7d585efd27c850067b8d7ba34ecc0
Add test case for handling a LU by TMSI MI when 'no assign-tmsi' is
configured.
This test will pass from osmo-msc patch
I583682d1a35a70b008d7bb2d89ba7c3109a60b21 on
Depends: osmo-msc I583682d1a35a70b008d7bb2d89ba7c3109a60b21
Related: SYS#6860 OS#4721
Change-Id: If10b9987395670b084ff8ad6d1f033ff46896d75
Allow testing Location Updating by TMSI MI.
Prepares for TC_lu_tmsi_noauth_notmsi in
If10b9987395670b084ff8ad6d1f033ff46896d75
Change-Id: I31aad8eb751528f7237a892702e87ee5855cabbb
Obviously, when only a TMSI has been used, searching for an IMSI will
return no subscriber. Don't fail in that case when testing for
verify_vlr := false.
Prepares TC_lu_tmsi_noauth_notmsi in
If10b9987395670b084ff8ad6d1f033ff46896d75
Related: SYS#6860 OS#4721
Change-Id: I4d719928f04e5a47d415c38f835451b1f10c713d
When a received Paging mismatches, instead of waiting for Tguard
timeout, fail immediately. Add a local timer and wait 4.0 seconds
by default.
Change-Id: I30273e3882e348a2ded88b7b96a5ec1473a56913
Tweaked-By: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
The by_tmsi argument so far had no effect. But I actually need exactly
this in upcoming MSC_Tests.TC_lu_tmsi_noauth_notmsi(): expect a Paging
with explicitly no TMSI included.
Related: SYS#6860 OS#4721
Change-Id: I9434745b7faeb738caafed8080b9f7b1a6a8079a
This testcase is failing sporadically ever since it was introduced
back in 2019, during 36C3. The problem is that osmo-msc does not
react to the malformed MM IDENTITY RESPONSE immediately, but only
after timeout of timer X1 (5 seconds, by default); while the
testsuite expects the LU REJECT to be received within 5 seconds.
We should ideally fix osmo-msc to react immediately, but for now
let's enlarge the LU REJECT waiting timeout in the testcase.
Change-Id: I5d2b5d49df8f7ae1eb12fc137f4256fe6fab9117
Related: OS#6426, OS#4340
This testcase is not Iu-compatible yet, but let's make life a bit
easier for those trying to make it such in the future.
Change-Id: I8185153502d31163fcb4c718690ee0f1cc912f5b
Previous commit [1] uncovers a problem in f_tc_mt_crcx_ran_reject():
this function uses as_clear_cmd_compl_disc(), which is expecting
A-interface (GERAN) specific BSSMAP Clear Command. The Iu-interface
(UTRAN) specific RANAP Iu-ReleaseCommand is not handled at all.
The testcase was passing so far due to a bug in as_optional_cc_rel(),
which would unblock the alt-statemtnt on receipt of CC RELEASE, so
that we would never respond to RANAP Iu-ReleaseCommand.
Let's derive a new altstep from f_expect_clear() and use it.
Change-Id: Idd679bbf720a56a76cf37ab414b1e6d90e53278b
Related: [1] I0143b4d33b1ebe4cce99c09018540524c4626eec
We do activate() this altstep in several testcases, so that it's
kinda "running in background". In reality, the defaults in TTCN-3
are just a syntax suggar, and the following code:
```
var default foo := activate(as_foo_bar());
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
}
PORT2.receive(tr_Msg3);
```
actually evaluates to:
```
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
[] as_foo_bar();
}
alt {
[] PORT2.receive(tr_Msg3);
[] as_foo_bar();
}
```
If as_foo_bar() contains no 'repeat' statement, then whenever it
triggers it would efficiently cancel (unblock) the current alt
statement, resulting in weird behavior due to messages not being
dequeued from ports as expected. And this is exactly what we
saw happening in OS#6414.
Change-Id: I0143b4d33b1ebe4cce99c09018540524c4626eec
Related: OS#6414
Assuming n_sd should be 3 is only valid for non-A5 testcases, in which
we are *not* doing ciphering and authentication. For the A5 testcases
(TC_ho_inter_bsc_a5_*), this assumption is incorrect and osmo-msc is
definitely not happy about that:
Duplicate DTAP: bin=0, expected n_sd == 0, got 3 (ran_msg.c:159)
Dropping duplicate message ... (msc_a.c:1363)
Why and how the A5 testcases passed so far? It was a pure luck, which
sailed away when we started executing ttcn3-msc-test with io_uring.
The A5 testcases were passing thanks to the as_optional_cc_rel() that
gets activate()d in background before calling f_call_hangup(). This
altstep does not have the 'repeat' statement, and as a side effect it
may cancel any normal alt-statements and even standalone receive()
statements.
In the successful scenario, it would cancel (unblock) the following
receive operation in f_call_hangup():
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
// ^^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
which is a pure luck because our CC RELEASE was sent with incorrect
sequence number and got dropped, so osmo-msc would never send us
CC RELEASE COMPLETE. It would instead send us CC RELEASE due to
expire of T306, and the as_optional_cc_rel() would kick in handling
this message and responding with CC RELEASE COMPLETE.
In the failing scenario though (when running with io_uring), that
same altstep running in backround may trigger *earlier* and unblock
another standalone receive() statement:
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
// ^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
so that we will be stuck waiting for CC RELEASE COMPLETE until the
Tguard expires.
This patch fixes n_sd patching, so that our CC RELEASE message is
handled properly and the call gets released as expected, without
requiring as_optional_cc_rel() to kick in. The missing 'repeat'
is to be added to as_optional_cc_rel() in a follow-up patch.
Change-Id: Iddde391eade716ca5c6c48cb631450ddb543e0d4
Related: OS#6414
Fix the issue that MSC rejects call termination, because talker can't
be identified as originator of the call.
Fixes: OS#6325
Change-Id: I0381e25e15624e6b7577910c95700a355ed3f811
Old osmo-msc versions do not include the Source Name IE in SMS related
GSUP messages, unless it's set explicitly in the config file ('hlr' /
'ipa-name'). Recent osmo-msc versions (see the related osmo-msc patch)
do include this IE even if it's not set explicitly ('unnamed-MSC').
Because of this, some testcases in ttcn3-msc-test are currently
failing for osmo-msc master, but still passing for the -latest.
Let's set the 'ipa-name' explicitly in osmo-msc.cfg, and expect the
Source Name IE to be present in SMS related receive templates.
Change-Id: Ic24d3082fe3dce08e43e8f3ecb6d6132503c55c6
Related: docker-playground.git I7757aae1d01b679f530b5c0a6c95b224cb9f204f
Related: osmo-msc.git I7bacd001b81326c32bc262c7d0c0491ded822fa8
Related: OS#6135
Prepare to add new CSD related tests that also need to configure the
call parameters for CSD.
Related: OS#4394
Change-Id: I49c29af736cc37c393cecde4c45c4ffd41322bf7
Verify that the MSC sends the CSData codec in the Assignment Request and
send this codec in the Assignment Complete towards the MSC.
Related: OS#4394
Change-Id: I7906e6fdb82c27f071aa55f2f73ba4108bfb46db
The expectation table is used to deliver new connections with Handover
Request as well as with VGCS/VBS Setup and VGCS/VBS Assignment Request.
"handoverRequest" is renamed to "n_connect".
Related: OS#4854
Change-Id: I941c5db5235785841f3368ef908a409bbb12150e
Add the missing rx of MNCC_REL_cnf to f_call_hangup for the MO case
(called with release_by_ms = false, see f_mo_call()).
This is in preparation for running f_mo_call several times in a row to
test multiple bearer services in a CSD test (follow up patch). Without
this patch, calling f_mo_call_establish() for the second time fails to
rx the MNCC_RTP_CREATE because the REL cnf is still in the port. This
leads to a timeout of X2 and OsmoMSC sending a CC RELEASE.
Adjust the log numbers next to f_call_hangup to re-use numbers 2 and 3
from above, as only one of the two code paths gets executed (similar to
numbers 5 and 6 below).
Related: OS#4394
Change-Id: Ia2ed7ce092e73e17c4243e83bfd239ead8266b49
It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
expectancies.
Change-Id: If48ca06f2cc3c0986daa5f6264d80138d468332a
Fix the missing call to f_ran_unregister_imsi when running f_mt_call.
This is in preparation for calling f_mt_call multiple times during one
test, to test various CSD bearer services. Without this patch, it will
result in a "No space left in ImsiTable" error.
I've also considered adding it to f_call_hangup instead, but this gets
called by f_mo_call (mo instead of mt) as well, which does not run
f_ran_register_imsi.
Related: OS#4394
Change-Id: Ie9b180b95348d7e84650c14a331c5091a1e67d1f
Fix for:
BSC_ConnectionHandler.ttcn:1546 Dynamic test case error: Using the value of an unbound boolean variable.
Fixes: 92b280c8 ("msc: new test: TC_lu_and_mo_csd")
Change-Id: I733db4dbc3ba3dd52ba501901b8b0ed36ff13344
Check if the AoIP Transport Layer IE is present before checking its
value. This gives a more meaningful error than Dynamic Testcase Error if
it is not present.
Change-Id: I52fc829b017848b6afe7e637f1911a0976f9c91d
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
function.
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Change-Id: I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
When CN RTP is missing, the X2 timer will fire after all other call
signalling looks successful. So far we establish an MT call, wait three
seconds and directly disconnect, long before X2 or X2427 can fire.
Make X2 shorter. (By means of f_vty_config() from ttcn, so that we don't
need to edit various osmo-msc.cfg in various repositories. The short
timer is always critical for the test to be accurate.)
Add proper function to detect premature disconnect. Otherwise we just
get a cryptic message like "Couldn't find MnccExpect for incoming call"
because of MNCC messaging after the unexpected release event.
Change-Id: I3ccf541360cc8440e664f0e29494b9ce7b6f8943
In f_tc_call_re_establishment_2(), after Assignment Complete, optionally
allow an MNCC_RTP_CREATE.
When Re-Establishing a call, the Assignment Complete usually affects
codec and RTP address, so an MNCC_RTP_CREATE should happen after the
Assignment Complete message.
Current osmo-msc master does not send this MNCC_RTP_CREATE. This is
unlikely to be correct (would be ok if no RTP port changes), likely
omitted due to a bug.
An upcoming patch adds the MNCC_RTP_CREATE in Call Re-Establishment to
osmo-msc.
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I06d19947ba2e9b6696269db0e4f3d47d4b98bde6
Test 12 permutations of
(auth optional,required) x (a5 '0', '0 3', '3') x (hlr has auth info)
In TC_auth_options_2(), expect behavior after implementing OS#4830: if
the HLR fails to return auth info and auth + ciph are configured
optional, fall back to no authentication. This test will start
succeeding starting with commit
I5feda196fa481dd8a46b0e4721c64b7c6600f0d1 in osmo-msc.git.
All other tests yield the current behavior of osmo-msc.
Related: I5feda196fa481dd8a46b0e4721c64b7c6600f0d1 (osmo-msc)
Related: OS#4830
Change-Id: I8e3b02ca83e56ef5349d85f08407509e19fa353c
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Andreas Eversberg
Oliver Smith