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
Handover testing required passing MSC and BSC addresses to f_tc_* functions and
added pars.handover.sccp_addr_msc and .handover.sccp_addr_bsc.
MSC pool tests added a separate sub-record pars.mscpool which also contains
these two fields.
Move them both up one level, to form a single pair of pars.sccp_addr_msc and
pars.sccp_addr_bsc.
This eliminates the pars.handover sub-record.
Change-Id: Iae81ca58001455099218ce769a97dc6402832490
The MSC pooling feature is implemented in osmo-bsc
Ifbdea197b26e88751a391c8a80c41f04e7d5e047.
A VTY command ('mscpool roundrobin next') that allows deterministic testing is
added in I2155d906505a26744966f442ffb1e87a6a9b494c.
osmo-bsc.cfg changes needed for these tests to succeed are in docker-playground
I1986e4ef43beee161c82193694421b56136c1afe
The new tests will fail until the above have been merged.
Change-Id: I21cbab193cd0de2e5692665442eae113d5f61904
Similar to the MSC tests, have several g_bssap and mp_bssap_cfg.
Prepare for MSC pool tests.
Replace g_bssap with a g_bssap[NUM_MSC] array.
Replace mp_bssap_cfg with an mp_bssap_cfg[NUM_MSC] array.
Requires patch I1986e4ef43beee161c82193694421b56136c1afe in docker-playground
to match the new required BSC_Tests.cfg format.
Related: OS#3682
Change-Id: Ibb36695b7c31f7b04eec6c5d59522fc0779b3c2f
Otherwise most tests in bsc-latest fail because in latest release BSC
never sends that IE.
Related: OS#4244
Change-Id: I725836784a7900d2ea51eae188c2c279e8639dbf
* MGCP-over-IPA handling in MSC_ConnectionHandler means we need to use
the new MGCP_CLIENT_MULTI port since we'll be managing MGCP messages
from 2 different UDP connections, and we need to be able to route
answers correctly. As a result, parameter multi_conn_mode is enabled for
SCCPlite and all code adapted to use that port in that type of scenario.
* iDuring calls when on SCCPlite, send a full (all-required-params-in)
CRCX through the MGCP-over-IPA connection towards the BSC in order to
emulate the MSC, and expect the correct answer back. This way we test
BSC funcionality to forward MGCP messages coming from MSC works as
expected.
Related: OS#2536
Depends: osmo-bsc.git I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
Change-Id: I31fed700772dd0b063f913b1e1639fd428c46e7d
Move logic handling CRCX and MDCX to function, so they can be reused for
other ports in forthcoming commits.
Change-Id: I07344657c5d1465a8e0c278adb76150ca7f449ba
Previous to this commit, BSSAP Reset (Ack) messages contained Osmux
Support IE even if transport was SCCPLite, where those IEs are actually
meaningless.
Change-Id: If6cc0f65a0f273297a4523e5d6a7564d966f0aa6
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
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