This test case fails in ttcn3-bsc-test-sccplite due to:
BSC_Tests.ttcn:10212 Dynamic test case error:
Using the value of an optional field containing omit.
Change-Id: I235027c2b53b8f2ae975e25eb7c38b1959668d6f
Related: SYS#5627
The function f_TC_fh_params_set sets frequency hopping parameters. The
ARFCN is also part of those parameters. However, this function does not
set the respective band for the ARFCN that it configurs. This results in
an invalid setting at the BSC that might cause unexpected behavior.
Lets make sure we configure the band parameter correctly before setting
the ARFCN
Change-Id: I447e4145c68c62b11b818e28f0081c19e9107647
Related: SYS#5369
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
OS#5244 reports an error in the Training Sequence Code used in the
Channel Activation for a handover target channel. Verify the TSC to
uncover this bug.
Related: SYS#4895, OS#5244
Related: Iae20df4387c3d75752301bd5daeeea7508966393 (osmo-bsc)
Change-Id: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af
Reduce code (comment) dup by having one const definition for default
TSCs instead of magic numbers.
Will add another use of this in upcoming patch testing correct TSC in
handover.
Related: SYS#4895
Change-Id: I3733ebbbfd74630e095a08b83023974aad177b34
Reproduce a segfault happening when the SDCCH (primary) lchan is lost
in-between a TCH Channel Activ and its Channel Activ Ack.
Related: SYS#5627
Related: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a (osmo-bsc)
Change-Id: I81cccdea450885d5241cab62000ad355d464dd49
In SCCPlite, there is only one DLCX. Turns out the DLCX doesn't have to
be part of the interlave, just call f_expect_dlcx_conns() which takes
care of AoIP vs SCCPlite expectations.
Related: SYS#4895
Change-Id: Id8931185dfa9f229ca7af033a97cabd040db0c2a
Fix SCCPlite run of TC_cm_reestablishment.
I'm not sure why it works for AoIP before this patch, but now it works
for both SCCPlite and AoIP.
Related: SYS#5130
Change-Id: I1c87272c5bb1ac452927054a9eef104d795e02f8
Avoid test breakage in ttcn3-bsc-test-sccplite, due to different
osmo-bsc configuration.
Related: SYS#5542
Change-Id: Iaf976ac12dbb2ee1930a7acfcf3cb452db34beed
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Depends: I1975941b790d2b30d0904d41e456220cba26ecff (osmo-bsc)
Change-Id: Ice3056dc46c94f9399f8379db7aeb7193782f2f2
Add a delay between sending the RSL Conn Fail IND and checking the stats
values, so that osmo-bsc has a good chance of receiving the message and
promoting the failure into the stats values first.
Even though jenkins shows no failures, when testing locally, this test
fails a lot for me without that bit of delay.
Change-Id: Iaf0173239528337283b23f70840d36ad25f14950
Also test the early IA feature for non-dyn TS in 'pre-ts-ack' mode, for
completeness' sake.
Related: SYS#5559
Change-Id: I6ba84b4b618dd99ec2095aaf611209e525f2b5f4
Tests have shown that the Training Sequence Set was not correct in early
IMM ASS messages. Add validation of the TSC and ARFCN in IMM ASS
messages for all early IA related tests. This makes the tests fail.
Related osmo-bsc patch linked below makes the tests pass again.
Related: SYS#5559
Related: I9f26074154600d854a0b3baee2f38a6666f4cb56 (osmo-bsc)
Change-Id: I4479244b0c53648e62e84e1ebf986f51d659484f
The mentioned bug was fixed 3 years ago, and there are already lots of
tests below so remove the comment.
Related: OS#3182
Change-Id: I3df4dbd1647dae78eccd31c49c3aec3cf9e12a6f
Test the experimental 'immediate-assignment pre-ts-ack' implemented in
I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
Related: SYS#5559
Change-Id: I2ae28cd92910d4bc341a88571599347a64a18fe5
Add tests for the new early IMM ASS feature in osmo-bsc:
'immediate-assignment (post-chan-ack|pre-chan-ack)'
Related: 0b44493d3de03d2750527e224df67b473fe39f93 (osmo-bsc)
Related: SYS#5559
Change-Id: If71f4562d532b6c5faf55f5fd073449a8a137ebf
So far the test ran both lchans on bts 0, which is not really a
realistic scenario for a CM Re-Establishment Request. Move the second
channel to bts 1, using various RSL port args added recently.
Change-Id: Ia930f7b8986ba27c5f507478dbff0a2942f207d8
So far we were often just expecting the message type. Instead expect a
release on the proper channel number.
While hunting a test error, this confused me for a while, because a
missing handler resulted in the release message handled in the wrong
place, even though the chan_nr mismatched.
Related: SYS#5130
Change-Id: I002c9273a387104bea062dec8879b4e19a72008d
To be able to run tests on a cell other than bts 0, there needs to be a
way to select the RSL_DCHAN_PT and RSLEM_PROC_PT in various places.
Upcoming BSC_Tests.TC_cm_reestablishment depends on this, to be able to
run through an Assignment on bts 1.
Related: SYS#5130
Change-Id: Ia14f46d4e5e8d4722224b97c346c0cb7973fff97
The function f_expect_dlcx_conns() is clearly related to MGCP, and
semantically should not interfere with BSSAP by also receiving the Clear
Complete.
For some tests, this incidentally makes sense, but an upcoming test
failed in a non-obvious way because of this.
Related: SYS#5130
Change-Id: I637414f4db8ea7c4b59aaee205d65926574b5ccd
After the RSL RF Release has happened, by definition the RSL_Emulation
should no longer direct RSL messages on that chan_nr to the test
component that used to own the chan_nr in the ConnectionTable.
Before this patch, re-using e.g. an already freed SDCCH would result in
non-obvious test failure. This is most relevant for generic functions
called from various tests, but fixing all occurences anyway.
Related: SYS#5130
Change-Id: I764ea2ed9af9358adeb42d7ed46b84f30f1e224c
This module parameter is not needed anymore, since latest already
supports this feature for a while.
Change-Id: I3a2a4f984443a40285440a7fc54b1797a943e4b0
With this we'll avoid running the test in latest. This way we'll not
fail after changing the TS for the test and hence other tests won't be
affected.
Related: SYS#5309
Change-Id: Ib956401030e6a97db218823c997c61c335fbd581
In the configuration file, that we use for ttcn3-bsc-test, TS5 is
configured to TCH/H. However, f_ts_reset_chcomb() would reset
it to TCH/F. This makes some other test cases fail.
Change-Id: I4c2c70381274949ed75d58723136e2f54eb3a7af
Fixes: [1] I6110fe0bf56f4dbf67265f0d4c97cdea0b410af4
Related: SYS#24876
After removing a5/4 from the default config, it also needs to be
explicitly enabled for these two tests.
Fixes: 26a3db ("bsc: change encryption a5 via VTY where needed")
Change-Id: Ibe00edb096f94b500869c46a39a694a73133c716
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
Do not assume that osmo-bsc.cfg contains "0 1 3 4" for master and "0 1 3"
for latest anymore. An upcoming test will need to change the value as
the test runs and needs a defined value to reset to.
Assume that osmo-bsc.cfg contains "0 1 3" and change it to "0 1 3 4"
only for TC_ciph_mode_a5_4.
Related: OS#4975
Related: docker-playground I55135ca00ef51de5cf6eaec75cfc20c21beef665
Change-Id: I3cf36c6ef86a0db050507f3737f4b0c10dcd52ed
Neels Hofmeyr
Vadim Yanitskiy
Philipp Maier
Pau Espin
Neels Hofmeyr
Oliver Smith