Prepare to use fail_on_dlcx in a new test case. Instead of dragging the
parameter through lots of function calls, just add it to pars.
Related: OS#5787
Change-Id: I6f0c4ce543724cc6f18bae9fc2b480f5818db8b7
New TC_assignment_osmux_bts is added which tests Osmux used only
BTS<->BSC.
Existing TC_assignment_osmux is renamed to TC_assignment_osmux_cn,
and a new TC_assignment_osmux is added which tests using Osmux on both
sides (towards BTS and CN).
Related: SYS#5987
Change-Id: I6e82eb9d995de988b812001e1c4cf6923509de66
That config is used to control the use of osmux between BSC<->MSC. Since
we'll add support for Osmux in BTS<->BSC, we want to test that in a
separate way. Let's rename it so that we can add a "use_osmux_bts" later
on.
Change-Id: I3bde4e6772c18043dd763d7747b5dbe40e0da3b8
as_Media_mgw() is used to establish a voice stream. If a DLCX happens as
part of that, that should be flagged as a problem.
In fact the Mode Modify test with current osmo-bsc does exhibit a DLCX
right upon the Assignment Complete message, which is a bug fixed in
I5ab10ee7fd9c5d7608e8a06893881d990943feed.
This patch now correctly flags this as a failure.
In the two tests
TC_ho_in_fail_no_detect, TC_ho_in_fail_no_detect2
the expected failure causes expected DLCX, so exempt those.
Related: SYS#5916
Change-Id: I0633f60f09d58802f6be0238ef41a632d93a4327
ranops was not isvalue because bssap_reset_retries was not set and not
explicitly omitted either, so the ran adapter decided not to create a ran
emulation...
Change-Id: Ibbef035929ec861fec1e8554460e22650b386f83
Test inter-BSC incoming HO where the Handover Request message is not
included in the initial SCCP N-Connect, but follows in a separate DT1.
Related: SYS#5864
Depends: I535c791fa01e99a2226392eb05f676ba6c3cc16e (osmo-bsc)
Change-Id: I6732153cdd0d529bfaf0925387e765f3403a756b
Since I just fixed the encryption behavior, I also want to know whether
the case of no A5 intersection is handled properly.
The tiny test comes with a lot of changes to allow a handover failure
code path. The 'expect_ho_fail' flag goes via function arguments to
g_pars and the general ho test code uses it to branch for exp-failure.
Related: SYS#5839
Change-Id: I44b464a0bedbff09c467c4bccd7c985480fb883a
Clean up: absorb pars.encr_exp_enc_alg into TestHdlrEncrParams as
pars.encr.alg_expect.
Remove the automagic encr alg choice from test procedures, instead put
all magic in the pars.encr configuration setup; like this all encr alg
values remain fixed through the tests, less confusing.
Add separate alg_chosen for BSSMAP: So far, we have only one algorithm
field for both the mask of permitted algorithms in the Encryption
Information IS and the Chosen Encryption Algorithm IE. However, in the
Chosen Enc Alg there must be only one bit set. Thus we cannot easily run
a test where more than one alg is permitted and where the BSSMAP Chosen
Enc Alg IE is involved.
We've recently come to realize that the Chosen Encryption Algorithm IE
may also be omitted from BSSMAP messages, in which case osmo-bsc should
still work. To be able to test BSSMAP messages with omitted Chosen
Encryption Algorithm, allow to set alg_chosen == omit.
Keep t_EncrParams() in a way that all current tests (that set only one
bit in alg_permitted) still run the same as they always did.
Add t_EncrParams2() for a proper template.
Add a convenience function to configure encryption testing.
Related: SYS#5839
Change-Id: I6590ecf4a146dbed494d9d72f5a79441877e9010
Properly clean up conns in the end. Use COORD and new COORD2 ports to
daisy-chain coordination between the four components.
Related: OS#5444
Change-Id: I3b1dfc3b11e990893cbf182fb9f8840e198eb8aa
This change fixes sporadic failures of TC_cm_serv_rej:
RAN Connection table not found by component TC_cm_serv_rej(2648)
BSC_Tests.ttcn:11106 BSC_Tests control part
BSC_Tests.ttcn:10550 TC_cm_serv_rej testcase
The reason is that sometimes a BSSAP/DTAP PDU (with CM Service Reject)
gets enqueued before the SUT has established an SCCP connection to the
virtual MSC. This causes a lookup error in the RAN connection table.
A simple solution would be to add a receive statement after calling
f_create_chan_and_exp(), like it's done everywhere else:
f_create_chan_and_exp();
BSSAP.receive(tr_BSSMAP_ComplL3); // <---
But a more general solution is to expect and receive this message in
f_create_chan_and_exp(), so we can reduce code duplication and make
the API more convinient. This is exactly what this change does.
Change-Id: Ic675168e29919e1234cb49440c4a630238ff5d70
Related: SYS#4878
For intra-BSC handovers, also verify the correct Training Sequence Code
in the RR Handover Command (not only in the Channel Activation as added
in previous patch).
Related: SYS#4895 OS#5244
Related: Iae20df4387c3d75752301bd5daeeea7508966393 (osmo-bsc)
Change-Id: I32e3553581eb17812082f1f2ee96cc978e8db668
Add explicit RSL_DCHAN_PT and RSLEM_PROC_PT args to functions and
altsteps related to channel establishment and assignment. This allows
establishing and assigning a channel on cells other than bts 0.
This is required for upcoming BSC_Tests.TC_cm_reestablishment().
Related: SYS#5130
Change-Id: Ic3206b7125ee22bf98330080d9b136cefe7da03f
Verify that A5/1 is preferred over A5/2. Add encr_exp_enc_alg to
MSC_ConnectionHandler:TestHdlrEncrParams, so the expected encryption
algorithm can be different from what the MSC tells the BSC about the
capabilities of MS.
Related: OS#4975
Change-Id: I688d056bcfe73f7846f908a28f4621f944cf2178
This way functions like f_inet_addr() and f_inet6_addr() can be
used directly without converting between bytes and integers.
Change-Id: I389a8cb95c025c9dddc751789223621c15d9b48f
The verification of correct encryption information so far is part of
f_cipher_mode(); put it in a separate new function f_verify_encr_info()
so that it can be re-used for handover channel activation.
Related: SYS#5324
Change-Id: I11602d23670f436a22b891fc744fe07e470f2b79
Implement tools for OsmoBSC a5/4 support testing:
- in f_cipher_mode() and f_check_chan_act(), expect Kc128 key as
appropriate, using recently added g_pars.encr.enc_kc128
- osmo-bsc.cfg: allow a5/4
Related: SYS#5324
Change-Id: Ifa48a8498dde7d04fb29f497013bdb5a1e5f3597
Instead of passing each part individually, simply pass the entire
TestHdlrEncrParams to f_cipher_mode().
Preparation for A5/4.
Add the kc128 to TestHdlrEncrParams instead of a function arg. kc128 is
so far unused, but will be used in an upcoming patch adding A5/4.
Related: SYS#5324
Change-Id: I2cb8282e55436da5ae64ab569df87d5d5a0dd2f0
In a recent osmo-bsc patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
c33eb8d56943b8981523754b081967e6ff5f245d
Ic665125255d7354f5499d10dda1dd866ab243d24
I accidentally changed the default behavior of the Training Sequence
Code sent to BTS and MS. So now, make sure that we verify the expected
Training Sequence Code in BSC_Tests, in:
RSL Channel Activate
RR Immediate Assignment
RR Assignment Command
RR Channel Mode Modify
RSL Mode Modify
Related: OS#5172 SYS#5315
Change-Id: Id67a949e0f61ec8123976eb8d336f04510c55c01
During f_create_chan_and_exp() (part of f_establish_fully()), announce
the BSSAP L3 expectation before activating the lchan.
In RSL_Emulation f_chan_est(), we go through Chan Request, Channel Act
and Immediate Assignment followed by EST IND. Right after that, osmo-bsc
sends a Complete Layer 3 on BSSAP. But in f_create_chan_and_exp(), we
only create the expectation of the BSSAP right after the call to
f_chan_est(), i.e. only after sending the EST IND. So far it was always
juuust in time to work, but when I added a little check to the end of
f_chan_est(), or alternatively an f_sleep(0.2), then BSC tests always
fail with:
Test case TC_reassignment_fr finished. Verdict: fail reason: Couldn't find Expect for incoming connection { [...] pdu := { bssmap := { completeLayer3Information... }
With the BSSAP expectation done first, this error is avoided.
Change-Id: I1d4af737dcc0f9c9fa6cdaff3a92813d532e730c
Test the lchan mode modification code path of OsmoBSC, in preparation of
adding VAMOS bits to the mode modification procedure.
Related: SYS#4895
Change-Id: Idf4efaed986de0bbd2b663313e837352cc139f0f
I am introducing a BSC test case that runs through a assigning a TCH
channel for signalling, and then using Channel Mode Modify to change its
mode from signalling to speech. For this to work,
f_channel_needs_modify() needs to actually look up the channel mode of
the TCH and not assume that a TCH is always in speech mode.
Related: SYS#4895
Change-Id: If30e2cec65da91cb5899ee29e2afb6696437a4c9
This introduces the Lb interface stack, which allows BSC_Tests.ttcn
to emulate a SMLC towards the BSC.
In accordance with https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
we use 0.23.6 as point code for emulating the SMLC.
Change-Id: Id41246f0dd812f7ddee9d920bfd07a4e3aac3504
When the BSC sends a CRCX without an IP address in it, the testcase will
automatically assign an IPV6 address in the response. However, this
breaks compatibility with older versions of osmo-bsc that do not have
IPV6 support. Lets add a module parameter in order to be able to use
IPV4 as default if required.
Change-Id: I30c77abef63636bb02db12d2f2b2d79ea244b96c
The altstep as_handover needs to repeat until the IPACC and the MGCP rtp
negotiation is done (MDCX). By setting the norepeat flag of the sub
altsteap as_Media_mgw to true, we allow as_handover to exit early, even
when the handover is not done yet, which eventually causes the testcase
to fail.
Change-Id: I303879a9153d25a02743dc1d4713ae74918b9be7
fixes: OS#4752
This reverts commit c47fdb2e52 - as
osmo-bsc currently doesn't yet have a Lb interface, we shouldn't try
to test it yet.
Change-Id: I7898dd336cbef27553d97857ac22f1a539da1380
This introduces the Lb interface stack, which allows BSC_Tests.ttcn
to emulate a SMLC towards the BSC.
In accordance with https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
we use 0.23.6 as point code for emulating the SMLC.
Change-Id: I854618cc08de1a716784f52542a4df3c7f7ad900
The function f_establish_fully may be called with template ass_tpl set
to "omit". In this case we must make sure that we do not pass ass_tpl on
to isvalue().
Change-Id: Ie094e5b56a851351671327b475d5e597a5a94bf6