In [1] I forgot to invert an if statement. This regression caused
most of GERAN specific test cases to fail due to "Tguard timeout".
Change-Id: I8cbaff00abfd9eb252dc3011df848e2e24fe5a1e
Fixes: [1] Ib7ebe8fd675295beb02cadebb19d8465dffeb732
Related: OS#5333
Reduce nesting and improve readability by splitting GERAN/UTRAN
specific CMC/SMC message handling into separate functions.
Change-Id: Ib7ebe8fd675295beb02cadebb19d8465dffeb732
Related: OS#5333
Also provide a blank receive template for CallParameters which is
needed to receive a CallParameters record via the COORD port.
Will be used by MSC_Tests.TC_call_re_establishment in
Ifdff5573eeb3b3d41e8599b9b0228411d2576864
Change-Id: Iba3a5304fa40159bc2c31cdc3a71ee56ed08bd12
Next to AuthVector vec, add boolean vec_keep. When set to true,
as_GSUP_SAI() skips the vector regeneration.
An upcoming patch adds encryption to inter-BSC handover, which will use
vec_keep := true. (See I57e43c60d4389bd301d0195179321a34401bd1dc )
Rationale:
Usually, a random auth vector is generated during as_GSUP_SAI(). For
inter-BSC handover, there are two separate virt-BSC components running.
But to be able to verify that the correct key is passed on from the old
to the new BSS, both titan components need to have the same AuthVector
data. The easiest solution is to generate the AuthVector before
launching the components, and then prevent that it is changed by
as_GSUP_SAI().
Related: SYS#5324
Related: I57e43c60d4389bd301d0195179321a34401bd1dc
Change-Id: I4bca739c2aad8342915e00a218f90fc19be7eafe
Instead of overwriting the ck of the original auth vector, generate the
Milenage-on-GERAN Ck key only for the expected ciphering IEs, centrally
in f_get_expected_encryption().
Related: SYS#5324
Change-Id: Iec618ba7fddb2290fc0137d99a9b8d5e2b428b98
Move the ciphering calculations from f_mm_common() to new function
f_get_expected_encryption(), so that it can be re-used for ciphering in
inter-BSC handover (upcoming patch).
Add tr_BSSMAP_CipherModeCmd2() to conveniently use the values returned
by f_get_expected_encryption().
To verify the Ciphering Mode Command in f_mm_common(), use the new
tr_BSSMAP_CipherModeCmd2(), and rely on template matching instead of
checking each IE individually.
Related: SYS#5324
Change-Id: I1f775889fb801d441ea6c8b0f0c34718b814c09e
All msc tests involving classmarks suffer from the same problem: if a
existing subscriber is reused the old classmarks will stick, since the
msc only overwrites updated parts of the cm when receiving a new cm, so
"downgrading" the existing classmark information is not possible.
This is circumvented here here by using different imsi suffixes,
the last param passed to f_start_handler.
Additionally the handler will now properly respond to cm requests
by the msc, i.e. in case the early cm is not sufficient for a5/4
because it lacks cm3, so the msc attempts once to query the cm,
hoping to get a cm3.
Related: SYS#5324
Change-Id: Idc055a006b325f58a5eafa88bc4415181b3500a2
Validate in test that MSC sends Last Used E-UTRAN PLLMN Id IE when call
is started by SGs (CSFB).
Related: SYS#5337
Change-Id: I161529fd9c8cacb7d17ea18660998df06bb0b575
These params are not needed anymore since new releases used in -latest don't
need to disable it.
Change-Id: I16575ae4f615bf7c42d5921917003007ba4872a0
Related: OS#5042
It tests IPv6 Transport Address are passed correctly through BSSAP, and
forwards handles them correctly as an MGCP client too.
Change-Id: Id616926dd4a9febc4268eea2ee1e377b2d22753a
As of osmo-msc Change-Id I2552736477663adb250c55728093500e8ae83ebb,
osmo-msc is always sending BSSMAP CommonID to the BSC. Let's adjust our
test expectation, while allowing the user to start the tests with
BSC_ConnectionHandler.mp_expect_common_id := false
to get the existing behavior (expect no bSSMAP CommonId) can be
restored, e.g. for testing 'latest'.
Change-Id: I4976d9bb1f07c8ab4ffa02848414f8ddd1bdfd3f
Related: OS#2969
osmo-msc failed to record the Complete Layer 3 Information LAC and CI in the
MSC-A as well as the VLR record. Since osmo-msc
Iee1781985fb25b21ce27526c6a3768bf70d4dc9a and
I194271af2acb37b4f8cc2d106ab2fd2b0d443589, osmo-msc properly records these for
successful Complete Layer 3 procedures.
Incorporate verification of the LAC and CI in all tests calling f_perform_lu()
and f_expect_clear(). Implement by scraping the output of vty
'show subscriber imsi 1234 conn'
Some tests model a failure to attach, or expire the VLR record: for those, add
parameter verify_cell_id to g_pars, and pass it as false, to skip checking the
LAC and CI.
Disable CI checking for all Iu tests globally in f_verify_vty_lac_ci(), see
OS#4634.
For the latest build, which does not yet record LAC and CI properly, provide
mp_enable_cell_id_test, which skips all cell id verification if set to false.
Put to effect by docker-playground I052fea208021509e12826c50474b96474e7a58c2.
Related: OS#4627
Depends: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a (osmo-msc)
Change-Id: Ie410714a96353f74a52a104c56fa0a08683e0004
Start a second
- MT SMS
- MT call
while a Paging is already ongoing.
The second trans being an SMS works.
The second trans being a call fails with current osmo-msc master; a fix is in
the related patch (s.b.).
Related: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
Change-Id: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
All the records related to Mobile Identity IE (see 3GPP TS 24.008,
section 10.5.1.4) are defined in [1], so there is no real need to
dumplicate them. Moreover, most of the related templates in
library/L3_Templates.ttcn are based on these records.
[1] titan.ProtocolModules.MobileL3_v13.4.0/src/MobileL3_CommonIE_Types.ttcn
Change-Id: I27c2743c59db770d6f7e9447dc8c1f539b228ced
Since [1] we started to match the SMSC Address in f_mt_sms_expect().
That change caused test case failures because OsmoMSC hard-codes
a different SMSC Address. Let's fix this.
[1] Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Change-Id: I3bdb6a74c8b02e4bf8dc88634e2380c924242b4b
When sending MO or MT SMS, we never include both SM-RP-DA/OA IEs
at the same time. In case of MO SMS, SM-RP-OA is omitted, and in
case of MT SMS - SM-RP-DA is omitted.
Change-Id: Ia60bdd2498034b6b849f874cf1eee272abef2b47
Make sure that osmo-msc doesn't crash if a successful CRCX response contains an
invalid IP address.
Originally/recently, osmo-msc did not validate the IP addresses at all. In an
intermediate patch I added error handling, releasing the call. That uncovered a
use-after-free problem in libosmo-mgcp-client. This problem is fixed by
osmo_fsm_set_dealloc_ctx() and an osmo-mgw fix (see
I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 in osmo-mgw).
Add this test to make sure the crash is not re-introduced.
Change-Id: I0c76b0a7a33a96a39a242ecd387ba3769161cf7a
* Semantic:
We don't really know which side the MSC first creates a CRCX for. Instead of
assuming that the RAN side is always CRCX'd first, simply handle a "first" and
a "second" CRCX, not making any assumptions which is for which side.
Notably, there still are quite a few places assuming which CRCX corresponds to
the RAN/CN side, but the changes are sufficient to still pass the tests when
osmo-msc swaps the CRCX order; sometimes for slightly obscure reasons, for
example because it doesn't matter that the wrong port number is returned during
a subsequent MDCX... Cleaning up the rest is still todo for later.
Remove code dup from call establishing code, particularly for MGCP.
Use f_mo_call_establish() and f_mt_call() where ever possible, to make all of
the call establishing tests handle upcoming changes in osmo-msc's order of
messages, without re-implementing the changes for each test individually.
The X-Osmux parameter was so far expected to appear in the first CRCX received,
assuming that this first CRCX is for the RAN. Instead, detect whether X-Osmux
is contained in a CRCX, and reply with an Osmux CID if so, regardless of it
being the first or second CRCX. Count the number of X-Osmux parameters
received in CRCX messages, and compare after call setup to verify X-Osmux
presence.
Since f_mo_call_establish() can't handle RANAP assignment, a few Iu tests that
worked with the older code dup will break by this patch. This is fixed by a
subsequent patch, see I0ead36333ab665147b8d222070ea5cf8afc555ec.
* Details, per patch chunk:
Change ts_BSSMAP_IE_AoIP_TLA4 to a non-value template, so that we can use a
wildcard for the assigned port number from MGCP (depending on RAN or CN CRCX
first, the RAN port number can be one or the other).
In CallParameters, move MGCP handling instructions into a separate record
"CrcxResponse", and have two of them for handling the first and the second
CRCX, replacing mgw_rtp_{ip,port}_{bss,mss} and mgcp_connection_id_{bss,mss}.
In CallParameters, add some flags for early-exiting call establishment with a
particular desired behavior, for specialized tests.
In CallParameters, use common default values and don't repeat them in each and
every call establishing test.
Set cpars.mo_call := {true,false} implicitly when f_{mo,mt}_call_establish()
are invoked.
Remove CRCX comments implying RAN or CN side, instead just talk of the "first"
and the "second" CRCX.
Implement one common f_handle_crcx() function, which is used by
f_mo_call_establish(), f_mt_call_complete(), as_optional_mgcp_crcx(), and
implicitly uses the first/second CRCX handling.
For Assigment, use a wildcard RTP port so that we don't have to assume which
CRCX was for the RAN side.
In f_mo_call_establish(), insert special case conditions to make it enact
errors at specific times, for individual tests. That saves re-implementing the
entire call establishment (code dup).
For error cases, add expectation of a CC Release message in the call
establishment. This should not apply for normal successful operation, but
because interleave does not support conditionals, add flags
got_mncc_setup_compl_ind and got_cc_connect to break the interleave when
establishing is complete, so that the CC Release is skipped.
A CC Release always breaks the interleave, at whatever time it arrives.
Tests adopting f_{mo,mt}_call instead of code dup:
f_tc_mo_setup_and_nothing()
f_tc_mo_crcx_ran_timeout()
f_tc_mo_crcx_ran_reject()
f_tc_mo_release_timeout()
f_tc_mo_cc_bssmap_clear()
Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
- Fix error log for a missing final DTMF.
- Instead of code dup to establish a call, use f_mo_call_establish(). This
will make the test benefit from changes to f_mo_call_establish() (which will
soon come up to accomodate changes in osmo-msc's codec negotiation).
- Instead of hardcoding the expected N_SD counter values to detect DTAP
duplicates, use f_bssmap_last_n_sd() and f_next_n_sd(), so that the N_SD
counter is correct regardless of how many DTAP were sent in
f_mo_call_establish().
- Instead of hardcoding a correct N_SD in the end, use skip_seq_patching ==
false, so that the ttcn DTAP correctly tracks N_SD for subsequent call
release messages.
- Release the call.
Change-Id: Ibfa8b906764f2d5ed75fe74125be42af4546e864
Before this, if an Assignment Request contains an unexpected Transport Layer
Address, the test completely rejects the Assignment Request.
Instead, accept any tla in the Assignment, and compare the expected tla in the
Assignment's interleave action. Thus we directly get logging hinting at the tla
instead of a T_guard timeout.
Change-Id: I04847c10d6c3bf9e04cfda6e343dfd4a65be71a5
Extend BSC_ConnHdlr with new check IMEI related parameters. Add tests
for check IMEI and check IMEI early for multiple auth variations, as
well as variants where the HLR would respond with NOK or ERR.
Note that we can safely set "check-imei-rqd 0" in f_init(), because the
latest OsmoMSC version already suppors this VTY command.
Two tests do not always pass, sometimes the RAN connection breaks
before the test finishes (TC_lu_imsi_auth_tmsi_check_imei_err and
TC_lu_imsi_auth_tmsi_check_imei_nack). I have added them as expected
errors in the expected-results.xml.
Related: OS#2542
Change-Id: Ic34bb8dc8547cafb5a53df03884554dd4f72956d
This will allow RAN_Emulation to have better knowledge on the protocol
stack in use, and behave differently based on that information.
For intance, forthcoming commit will append OsmuxSupport IE only if
transport is BSSAP AoIP.
Change-Id: Ife62e328af2d3f2475ff93249f2138820c7ddabb
Even if ciphering it not enabled, osmo-msc still sends a
SecurityModeCommand to use IntegrityProtection, and as a result osmo-msc
assumes implicit ACCEPT in all UTRAN CM service requests.
Fixes: OS#3991
Change-Id: Ida91f907dd6dfae68cbc63752ddc6f2948792689
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
Add three tests which exercise MSC behaviour when a CIPHER MODE
COMPLETE command lacks the optional chosenEncryptionAlgorithm IE.
Check for behaviour with A5/1, A5/3, and A5/1 + A5/3 configured
in the network, and expect the location update to succeed.
These tests pass on master, but they should somehow verify the
cipher the MSC ends up using. I am not quite sure how to do that.
Would inspecting the MSC's VTY be a reasonable approach? How
could his be done by code which runs on BSC_ConnectionHandler?
Change-Id: I1a2a126795c544613a7a87e238e1fc8c4e943885
Related: OS#2872
In some cases we might want to match on (and perform) the GSUP
SEND AUTH INFO without also expecting/performing a MM authentication
on the Iu/A interface. Hence it makes sense to split those two.
Change-Id: I7b298d589930bab976b478ac84553a6352f25c93
We were using '?' for the protocolExtensions in RANAP messages,
which required that such extensions existed. In reality, we want
to use '*' which accepts paging messages whether or not there
are any protocolExtensions present. As this is the default in
all our RANAP receive template, callers don't even need to specify
it.
This should fix all Iu paging related test failures in MSC_Tests*.ttcn
Change-Id: If22e16ecb301c86b9073ffde0af9e03bc85fbcc7
Both f_mo_call_establish() and f_mt_call_establish() were testing barely half a
voice call setup. For example, f_mo_call_establish() used to be satisfied with
just two CRCX, but no actual RTP connections being made.
Add numerous MNCC and MGCP messages more closely resembling an actual call.
The main reason is to achieve a state that passes both current osmo-msc master
as well as the upcoming inter-MSC Handover refactoring.
Add log markers to f_*_call_*(): often when a test halts, it is not at all
clear why. With these log markers it is saner to figure out what has happened
and what hasn't.
Change-Id: I162985045bb5e129977a3a797b656e30220990df
This function is required not only for the MSC_Tests, but also for
the upcoming Iu related SGSN tests
Change-Id: Ic23669671ce79151046f2330726bb68542faeb0e
This might look a bit like copy+paste programming for our testcases.
However, we actually want the Iu related tests show up as separate
'testscase' in the TTCN-3 sense, so there's no way that's more elegant
than this :/
Change-Id: I3b56e17487c9df839e67ed390a1ff89979683e8e
The new function will check the RAN type and dispath to
f_bssap_compl_l3() in case of 2G/GERAN and to f_ranap_initial_ue()
on case of 3G/UTRAN.
Change-Id: Ia27afa265d441d1a0cbb40cc2d938aff46fa25f9
Vadim Yanitskiy
Neels Hofmeyr
Eric Wild
Pau Espin
Harald Welte
Oliver Smith