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
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
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
This way functions like f_inet_addr() and f_inet6_addr() can be
used directly without converting between bytes and integers.
Change-Id: I389a8cb95c025c9dddc751789223621c15d9b48f
Only ho-into-this-bsc tests are required, since the out-of-this-bsc
message (Handover Required) does not involve any encryption information.
Related: SYS#5324
Change-Id: I8de65eb9a5bd9a58add55e821f2a559c9a81edc1
In f_tc_ho_int(), verify encryption information for the handover
target's chan act.
Add test cases calling f_tc_ho_int() with various A5/n encryption modes.
Related: SYS#5324
Change-Id: Iaab26c708c106a61b762234d42ed9a52cdc2998c
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
Allow only A5/4, but omit the Kc128 IE from MSC's msg. Expect Cipher
Mode Reject.
Related: SYS#5324
Change-Id: I7734a4a59797a9b21523c33f48815a8094f4e6ec
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
A local tccn3 test run for VAMOS looks like:
while sleep 1; do osmo-bts-omldummy -f vamos 127.0.0.1 1234; done
osmo-stp
osmo-bsc -c osmo-bsc-vamos.cfg
make compile
make -j 5
../start-testsuite.sh BSC_Tests BSC_Tests_VAMOS.cfg
../log_merge.sh BSC_Tests --rm
Change-Id: Iabda4c864b02e6ddbf03386c75d67a37f92992f4
In BSC_Tests_VAMOS.ttcn, in f_est_and_reassign_to_secondary_lchan()
there is a missing channel release ack. By allowing ASP_RSL_UD, this rel
ack can be sent trivially.
Change-Id: Icd04184ed87c359349d86c5e0893c2ce9de2f7f1
Oliver Smith
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy