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
reasons:
* TC_assignment_fr_a5_4() runs an unusual sequence of messages: it first
fully assigns an lchan, and after that sends a Cipher Mode Command.
Usually, the ciphering happens as part of attaching (Compl L3).
The new test TC_assignment_fr_a5_not_sup() does the ciphering in the
usual sequence, and properly expects a Cipher Mode Reject.
* TC_assignment_fr_a5_4 means to ask for an *unsupported* encryption
algo. Since we are going to introduce A5/4 support shortly, we'll need
to free up this name, for a successful A5/4 encryption test.
New test TC_assignment_fr_a5_not_sup() asks for A5/5 encryption, which
is not supported.
Related: SYS#5324
Change-Id: I83eca18d1b3d8d58177aa3750935ec5a3a985ca4
The function didn't wait to receive the 2 messages from the BSC. As a
result, they may have arrived while tearing down the test components
shortly after exiting the function and provoke a Dynamic Test Error
while pushing the messages up the stack since some of the stack layers
may already be unavailable.
Test TC_ho_out_of_this_bsc() workarounded this by using a f_sleep(1),
but TC_srvcc_eutran_to_geran_ho_out() didn't, making it fail sometimes.
Change-Id: I590b09353900dfe6c4f648812ab675fed1908589
BSC_Tests_VAMOS.ttcn is separate from BSC_Tests.ttcn in order to
instruct osmo-bts-omldummy to pass BTS_FEAT_VAMOS == true in the OML BTS
attributes.
Add tests:
TC_chan_act_to_vamos()
TC_mode_modify_to_vamos_fr()
TC_mode_modify_to_vamos_hr()
TC_assign_to_secondary_lchan_fr()
TC_assign_to_secondary_lchan_hr()
TC_vamos_multiplex_tch_f_tch_f()
TC_vamos_multiplex_tch_h_tch_h_tch_h_tch_h()
Change-Id: I2c504099163a30ea102cbd26d3615ca2e5ce1e64
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
osmo-bsc does now support intra-cell re-Assignment of lchans with active
voice. Test re-Assignment of TCH/F, triggered by VTY command.
Change-Id: I05fecefb9d6f9f23a0362f133170bca4da92e308
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
Update TC_si2quater_*_earfcns test to trigger Tx of SI2quater eutran
neigh list properly, by sending a CommonID with "Last Used E-UTRAN PLMN
ID" IE. This should have been updated in a recent commit (see
below).
Fixes: 841b90daf2
Related: SYS#5337
Change-Id: I3073152475a338b29214393a9b550891d52e1f24
CSFB indicator shouldn't be used as stated in the specs. Rather, BSC
should act based on "Last Used E-UTRAN PLMN Id" found in messages such
as Common Id, or Handover Request/Required.
Related: SYS#5337
Related: osmo-bsc.git Change-Id I5d290ac55eca5adde1c33396422f4c10b83c03d5
Change-Id: I7b2e5a3ad24c10e279a7f1c447804100168203ba
The IE contains a cell list for the MS to register after the channel
is released. The IE is used in CSFB, but not only in that case: it's
also used in SRVCC.
Hence let's remove the CSFB references since the scope is more wide.
Related: SYS#5337
Change-Id: Ia1eeda98fc21aa92bb2e41b5e4761c5cf6516a7e
This param is not needed anymore sincenew releases used in -latest don't
need to disable it.
Let's keep the possibility to change behavior from within test and leave
v6 enabled by default as it used to be.
Related: OS#5042
Change-Id: Ic693885dd3d4259dc6ce80643d25c7d432148d3d
Since Idb453fc894584ccf4f5f8b45a24421db958e9478, osmo-bsc does send
ip.access specific Measurement Pre-Processing Defaults. This message
currently blocks the 'alt' statement in f_recv_next_si1(), so all
test cases calling it fail due to the guard timeout.
What's even worse, both TC_si_acc_rotate() and TC_si_acc_ramp_rotate()
dynamically configure the IUT in order to re-generate and send System
Information messages periodically. If any of them fails prematurely,
the related configuration parameters would remain active, so the IUT
would continue sending System Information messages, causing failures
in subsequent test cases.
Let's simply ignore all unmatched messages in the 'alt' statement.
Change-Id: I1a85a046e1a8ebcd494354dddcbcc9707fdf5ee9
There is a global boolean flag that would make f_init() return
early if it's called twice. This is exactly the case here.
Change-Id: Ic33786c4851d2682deec7c22fafb99043c1c1cf6
Calling f_shutdown_helper() in f_tc_chan_rel_rr_cause() leads to
premature test case termination, so only one out of 6 cause values
gets checked. Move it to TC_chan_rel_rr_cause().
Change-Id: Ic7df15b496fc0750e4f694b1ae79398216f498a7
This test shows that in current osmo-bsc, the start-mode fails to
propagate to the MultiRate Config IE, the only start-mode so far has
always been zero.
Change-Id: I75515baf8cda04567cad8a93c5aa88361c2d259f
Make sure that when a 'start-mode auto' is set, that the previous start
mode setting does not linger in the unused bits.
- after I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1, osmo-bsc sets its
ICMI bit properly, but passes this test only because it *always* sends
smod (start-mode) bits as zero.
- in I49691df01745a7c485bf165e897872c35fc4b147, the smod bits are
properly sent on RSL, but this test shows that when ICMI becomes zero
for 'start-mode auto', the smod bits will remain whatever start-mode
was set in the previous osmo-bsc config. Instead, osmo-bsc should
clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
- in I1ec5bad0bce01cc425ee05ecf70c83ec662a226a, clearing smod is
implemented and this test is expected to pass.
Change-Id: I151678f64e680f30f35b6bb2b0036d63efde9f2c
osmo-bsc currently has a bug that fails to reflect the correct
start-mode in the AMR MultiRate config IE.
And it went unnoticed that the ttcn tests expect a MultiRate config of
ICMI = 1, even though the used configuration should yield ICMI = 0.
See mr_conf = '2804'O, where the '8' indicates ICMI = 1.
As a first fix of the ttcn3-bsc-tests, configure the BSC according to
the expected ICMI value and Start Mode, i.e. ICMI = 1 and StartMode = 0,
which is configured by 'amr tch-[fh] start-mode 1'. This should make
these tests pass as-is for both the current osmo-bsc as well as an
osmo-bsc where the bug is fixed, with minimal changes to the current
tests. See also OS#4868.
An upcoming patch will add tests for 'start-mode auto'.
Related: OS#4868
Change-Id: I4cff01c37d5c7e301e9a01f773b7e009a789519b
These allow passing N vty configurations on the bts / msc node without
requiring subsequent 'exit'.
As an example, use f_vty_cfg_msc() in BSC_Tests.ttcn AMR config.
Change-Id: I9f3e485f692acb3d2a7620e9b454b372651be78e
When a RESET-ACK times out, the logs currently are indistinguishable between
BSSMAP and BSSMAP-LE. Add protocol naming for each RESET / RESET-ACK logging to
make sure the information does not need guesswork.
Example of a test failure shown in jenkins:
BSC_Tests.TC_unsol_ass_compl
Stacktrace
Timeout waiting for RESET-ACK after sending RESET
BSC_Tests.ttcn:8295 BSC_Tests control part
BSC_Tests.ttcn:4274 TC_unsol_ass_compl testcase
Nothing conveys that it is (presumably) the background *BSSMAP-LE* timeout
halting the test 5 seconds in, and not an A-interface failure.
Change-Id: I874567e68b8279bf2460b9474241f0a9fe5ff0ff
Adding LCS to OsmoBSC creates the possibility of a Paging for LCS, where the
Paging Response should not emit a Complete Layer 3 on the A-interface.
Change-Id: Icb402b7436d844d939790f3cfb3725ffcf1136d2
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
Without this, subsequent vty commands become "% Unknown command".
(Triggered by the test start vty "logp" in f_start_handler() that is going to
be added by subsequent patch.)
Change-Id: I51ace11883256ee0725caae46ea22adb2ea5eb39
We cannot use a random 8bit value as RACH request, as some of that
space actually maps to emergency call RACH, which is rejected unless
we enable it in the config.
Change-Id: Ie073fe721022c392278e8632ab52122b4b89cbe1
Since If4d479a54cad467f53b49065c1c435a4471ac7d2, osmo-bsc started
to send more concrete DLCI values on the A/BSSAP interface. In
particular, the control channel identification bits now indicate
whether it's SDCCH/FACCH or SACCH channel.
Let's use '?' as the default DLCI template that we expect to get
from the IUT, so those test cases, for which DLCI is not a part
of the testing scenario, would not fail.
Change-Id: Ida659d53e0d31f9aa0ea2ccccefc94d8c659eb76
Neels Hofmeyr
Pau Espin
Harald Welte
Vadim Yanitskiy