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
Prepare to add new CSD related tests that also need to configure the
call parameters for CSD.
Related: OS#4394
Change-Id: I49c29af736cc37c393cecde4c45c4ffd41322bf7
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
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
Helped me find a failure cause: instead of T_guard timeout, immediately
show an unexpected MNCC event.
Related: SYS#5066
Change-Id: I49a15142a4b6c51ca767a884c0574f96e01d7cb1
continued from Id0c98bc267daff352fc7db7712f967111970fd4d
Upcoming changes to osmo-msc move the CN side CRCX to an earlier point
in time, reversing that order. Introduce an 'interleave' to not care
about the ordering of MGCP and BSSAP messages.
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I0ec348df08aa49ed58b3465de51b259fb74c0aea
So far, the first CRCX dispatched by osmo-msc is used for the RAN side,
and the second one for the CN side. Upcoming changes to osmo-msc move
the CN side CRCX to an earlier point in time, reversing that order.
Allow both RTP addresses from the two MGCP CRCX OK to appear in the
Assignment Request message to RAN, so that the test succeeds for both
the current osmo-msc and the upcoming patch (see below).
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: Id0c98bc267daff352fc7db7712f967111970fd4d
According to [1], 3GPP TS 48.008 does indicate that on AoIP the MSC
Preferred Codec List IE shall be present in BSSMAP HandoverRequest.
Let's verify that the IUT actually includes this IE.
Change-Id: I2e0ecbcced9f94d2b44d981db353007cad3ae959
Related: osmo-bsc.git I117cc29d6d11db77d160de654f43f5993db6ee21
Related: OS#5529
Reproduce the assertion trigger crashing osmo-msc reported in OS#5532,
i.e. a CM Service Request that contains a mismatching Mobile Identity.
Causes osmo-msc to crash with an assertion, so run it last.
Fix of the crash: I6c735b79b67108bcaadada3f01c7046e262f939b
Related: OS#5532
Depends: I6c735b79b67108bcaadada3f01c7046e262f939b (osmo-msc)
Change-Id: I3f84d00f456aaee578787059d7010c25efcdcf56
bsc-nat introduces a delay that will lead to failed tests, since the
reset attempt happens too early and times out, and the tests do not
retry.
Change-Id: I9f6db2a24e984eef31e76f9d42a80eb6a1bb6928
If the RAN_Emulation is started before the VTY reconfiguration we could
get a BSSMAP Reset/ResetAck with Osmux support advertised even though
the test expects it to be disabled (or vice versa).
Do the VTY configuration before starting the RAN_Emulation.
Fixes sporadic/load-related TTCN3 failures with message
"BSSMAP: Timeout waiting for RESET-ACK after sending RESET"
(e.g. TC_iu_and_mt_call_osmux, TC_iu_and_mo_sms in run +1567)
Change-Id: Ife23f70c6523034f3c3c53b6c1c81428566fd43e
The osmo-msc patch that makes this test pass is
I6fa37d6ca9fcb1637742b40e37b68d67664c9b60
Related: SYS#5130
Change-Id: Ifdff5573eeb3b3d41e8599b9b0228411d2576864
To allow running connect() on the COORD ports of test components before
starting the test component but after creating it, split
f_start_handler_with_pars() into f_start_handler_create() and _run().
Will be used by MSC_Tests.TC_call_re_establishment in
Ifdff5573eeb3b3d41e8599b9b0228411d2576864
Related: SYS#5130
Change-Id: Ic7e9dbb8c9db5948fe35fc3051bb988d65622782
Will be used by MSC_Tests.TC_call_re_establishment in
Ifdff5573eeb3b3d41e8599b9b0228411d2576864
Related: SYS#5130
Change-Id: Ic63fa41fa2e5d392d39f6b5f9edd3952aa6a9ee9
osmo-msc will soon have CM Re-Establishing support, and it will start
returning a different reject code instead of
GSM48_REJECT_SRV_OPT_NOT_SUPPORTED. In TC_cm_reest_req_reject, there is
no previous ongoing connection let alone a voice call, so osmo-msc will
return GSM48_REJECT_CALL_CAN_NOT_BE_IDENTIFIED.
Related: SYS#5130
Change-Id: I3eebab2b26016fb0ef7bf958208eaba6ae4c7836
There is a pars.ran_idx, no need for an explicit bssap_idx argument.
There is only one occurence passing a nonzero bssap_idx, use
pars.ran_idx instead.
Preparation for patch "msc: split f_start_handler_with_pars()"
Ic7e9dbb8c9db5948fe35fc3051bb988d65622782
Related: SYS#5130
Change-Id: Ib5c5585f098ff269920cf9d5781c4366234854c5
The MDCX OK message should contain the same connection identifier as the
MDCX contained. So far we were always sending the second conn id,
regardless of which conn id was sent in the MDCX message.
Related: SYS#5130
Change-Id: If6f7f135d95c04ee0240f3fa9ba0b18ffc6fa24a
When back on the A interface, the subscriber should no longer contain a
Last Eutran PLMN Id related entry in the VLR, since the SGs association
is no longer alive.
Related: SYS#5337
Change-Id: I8c72eaa4d41b8523f483ac3a343b782d1ef7c937
Fixes inter-MSC handover tests: in the inter-MSC 'Handover Required', do
not send a LAI cell identifier, but a CGI one.
This is analogous to the fix applied to inter-BSC HO in
I48276acf923626db171683dfa03ef43614a71380.
Rationale:
As explained in OS#5188, 3GPP TS 48.008 allows a LAI identification only
in the Cell Identifier List IE, but not in the single Cell Identifier
IE.
In the inter-MSC HO test's Handover Required message, we so far send a
LAI identifier in a List IE to osmo-msc. And so far, osmo-msc simply
echos that in the Handover Request message's single Cell Id IE.
The LAI is, as actually defined in the spec, omitted from the single IE
in deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn, and when
osmo-msc sends the non-standard LAI Id, ttcn3 fails to parse the BSSMAP
Handover Request message: the Cell Identifier IE gets wrong values, and
all remaining IEs are parsed as 'omit' even though they are present on
the wire. So as long as osmo-msc sends back a LAI Id, we cannot sanely
verify the Handover Request received from the MSC.
The CGI identifier type is supported in both IEs. So when the test sends
a CGI identifier in the Handover Required, osmo-msc will also reflect a
CGI identifier in the Handover Request, and ttcn3 parsing works.
Related: OS#5188 SYS#5324
Change-Id: I525b5deaa9634fcdb63fbd2c97c767aff045767c
TC_ho_inter_msc_out fails on jenkins in a way that i cannot reproduce. A
possible source is the decmatch for the Handover Request message. The
jenkins logs show:
MSC_Tests.ttcn:6005 Warning: Decoded content matching failed, because the buffer was not empty after decoding. Remaining octets: 22.
Change-Id: I20b5594c7e083af791525231f24d3ed089c18910
Recently, encryption testing was added to the inter-MSC HO test. Instead
of sending the chosenEncryptionAlgorithm from the receive-template side
forward the actual received one (rx "*" usually means tx is "omit").
Change-Id: Icae084cfd63d666f3b0778fade7ba558bd161a0f
Vadim Yanitskiy
Pau Espin
Andreas Eversberg
Oliver Smith
Neels Hofmeyr
Eric Wild
Daniel Willmann