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
In the pooling case it is not clear where the message will be forwarded
to so allow reception on any SGSN.
Change-Id: I6669ed0b49e9f278f16a67dc05ae208884ee535e
Related: OS#4472
When back on the A interface, the subscriber should no longer contain a
Last Eutran PLMN Id related entry in the VLR, since the SGs association
is no longer alive.
Related: SYS#5337
Change-Id: I8c72eaa4d41b8523f483ac3a343b782d1ef7c937
This way functions like f_inet_addr() and f_inet6_addr() can be
used directly without converting between bytes and integers.
Change-Id: I389a8cb95c025c9dddc751789223621c15d9b48f
Fixes inter-MSC handover tests: in the inter-MSC 'Handover Required', do
not send a LAI cell identifier, but a CGI one.
This is analogous to the fix applied to inter-BSC HO in
I48276acf923626db171683dfa03ef43614a71380.
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-MSC 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.
Related: OS#5188 SYS#5324
Change-Id: I525b5deaa9634fcdb63fbd2c97c767aff045767c
TC_ho_inter_msc_out fails on jenkins in a way that i cannot reproduce. A
possible source is the decmatch for the Handover Request message. The
jenkins logs show:
MSC_Tests.ttcn:6005 Warning: Decoded content matching failed, because the buffer was not empty after decoding. Remaining octets: 22.
Change-Id: I20b5594c7e083af791525231f24d3ed089c18910
Recently, encryption testing was added to the inter-MSC HO test. Instead
of sending the chosenEncryptionAlgorithm from the receive-template side
forward the actual received one (rx "*" usually means tx is "omit").
Change-Id: Icae084cfd63d666f3b0778fade7ba558bd161a0f
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
Pau Espin
Neels Hofmeyr
Vadim Yanitskiy
Oliver Smith
Daniel Willmann
Philipp Maier