Next to AuthVector vec, add boolean vec_keep. When set to true,
as_GSUP_SAI() skips the vector regeneration.
An upcoming patch adds encryption to inter-BSC handover, which will use
vec_keep := true. (See I57e43c60d4389bd301d0195179321a34401bd1dc )
Rationale:
Usually, a random auth vector is generated during as_GSUP_SAI(). For
inter-BSC handover, there are two separate virt-BSC components running.
But to be able to verify that the correct key is passed on from the old
to the new BSS, both titan components need to have the same AuthVector
data. The easiest solution is to generate the AuthVector before
launching the components, and then prevent that it is changed by
as_GSUP_SAI().
Related: SYS#5324
Related: I57e43c60d4389bd301d0195179321a34401bd1dc
Change-Id: I4bca739c2aad8342915e00a218f90fc19be7eafe
Instead of overwriting the ck of the original auth vector, generate the
Milenage-on-GERAN Ck key only for the expected ciphering IEs, centrally
in f_get_expected_encryption().
Related: SYS#5324
Change-Id: Iec618ba7fddb2290fc0137d99a9b8d5e2b428b98
Move the ciphering calculations from f_mm_common() to new function
f_get_expected_encryption(), so that it can be re-used for ciphering in
inter-BSC handover (upcoming patch).
Add tr_BSSMAP_CipherModeCmd2() to conveniently use the values returned
by f_get_expected_encryption().
To verify the Ciphering Mode Command in f_mm_common(), use the new
tr_BSSMAP_CipherModeCmd2(), and rely on template matching instead of
checking each IE individually.
Related: SYS#5324
Change-Id: I1f775889fb801d441ea6c8b0f0c34718b814c09e
The current paging load tests only test what happens when the paging
load is introduced from the PS side. However there are no tests that
tests what happens when PS pagings are introduced from the PCU side
into an already overloaded system.
osmo-bts was equipped recently with a mechanism that detects congestive
situations. Once a congestion is detcted osmo-bts will drop pagings from
the BTS side. The rationale of the new testcase is that the behavior
must not change when the PS pagings start since osmo-bts is dropping
them.
Change-Id: Ie72e788d9ebff6ca4e50314746127a9689948062
Depends: osmo-bts I30f97672d7a0c369c4a656e878ab8cbbd83e31ea
Related: SYS#5306
In the inter-BSC 'Handover Required', do not send a LAI cell identifier,
but a CGI one.
Rationale:
As explained in OS#5188, 3GPP TS 48.008 allows a LAI identification only
in the Cell Identifier List IE, but not in the single Cell Identifier
IE.
In the inter-BSC HO test's Handover Required message, we so far send a
LAI identifier in a List IE to osmo-msc. And so far, osmo-msc simply
echos that in the Handover Request message's single Cell Id IE.
The LAI is, as actually defined in the spec, omitted from the single IE
in deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn, and when
osmo-msc sends the non-standard LAI Id, ttcn3 fails to parse the BSSMAP
Handover Request message: the Cell Identifier IE gets wrong values, and
all remaining IEs are parsed as 'omit' even though they are present on
the wire. So as long as osmo-msc sends back a LAI Id, we cannot sanely
verify the Handover Request received from the MSC.
The CGI identifier type is supported in both IEs. So when the test sends
a CGI identifier in the Handover Required, osmo-msc will also reflect a
CGI identifier in the Handover Request, and ttcn3 parsing works.
This prepares for adding verification of the ciphering in inter-BSC
handover, in turn a preparation for adding tests of A5/4.
Related: OS#5188 SYS#5324
Change-Id: I48276acf923626db171683dfa03ef43614a71380
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
Sometimes, VAMOS related test cases fail due to a DTE:
Dynamic test case error: Sending data on the connection of port
CCHAN_PT to 1:RSL_CCHAN failed. (Broken pipe)
Call f_shutdown() to ensure that all components are properly
terminated, so there will be no race conditions like this.
Change-Id: I690412a29b24571109415d32b09543de459076d1
Related: SYS#4895
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
Since recently, we do have NOPE indications in the virtual Um
environment. Somehow this broke test cases for the MS power
control. Releasing the channel makes everything work again.
Change-Id: I6a204bbecfe116aa302eae28ff24d6bb899fa8b7
Related: SYS#5313, OS#1569, OS#1866
This adds a few tests that ensure that the encryption algorithm dynamically chosen is
1) one actually supported by both the sgsn and the UE
2) the strongest one available both have in common
Change-Id: Iad65cbf9840aa883cb34e53554b94a4142c82638
Related: SYS#5324
RAW_NS used previous a single TTCN3 port for a single UDP port
(source/listen side).
This has the limitation that only a single NSVC could be tested for a
local UDP port. However SNS tests require multiple NSVCs over a single UDP port.
NS_Provider_IPL4 already supports multiple NSVCs for the NS_Emulation.
Extend the support in NS_Provider_IPL4 to also allow RAW_NS to use
multiple NSVCs.
Related: OS#5036
Change-Id: Iafd9310e04066958914201da0cbdcd563bd5c976
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
As 3GPP TS 48.016 § 7.4b.1.1 specifies this behaviour.
1. do success SNS configuration
2. change sig weight of the seconds inactive bind
3. add second bind to SNS
4. stop reacting to NS_ALIVE on first NSVC (only NSVC with sig weight)
5. expect SNS SIZE
Related: OS#5039
Change-Id: Id06e34e7235d94a06152a0015487a507d6492a97
1. do SNS configuration
2. add a bind
3. receive the SNS_ADD
4. before answering the SNS_ADD, change the weight via vty and remove the bind
Related: OS#5036
Change-Id: Ibc565bba4c7e0a0b4dd28a48847dbdb998c8528d
Recent changes [1] to osmo-bts make it periodically send the
RF RESource INDication messages for each transceiver over the
A-bis/RSL. These messages block the queue of 'RSL_CCHAN' port
and make the paging related test cases fail. Ignore them.
Change-Id: I18b879235c6eefb2dd89a3f4502b0830efeac6bb
Related: [1] Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Some test cases change the weight of the binds. Ensure all test cases
starts with the same configuration.
Related: OS#5036
Change-Id: Iae2ba130b2f7d29ec8b417f07d0bef87f74ce5a4
The SGSN/PCU will use a different NSVC as the NSVC which will be changed weight'ed.
Related: OS#5036
Change-Id: I5766afaa74db30d94318312ab775e7933b9df783
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
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Philipp Maier
Eric Wild