Currently we execute both test cases on *all* available dedicated
channels from g_AllChannels[]. Given that SACCH is slow, and in
some cases we intentionally wait for a timeout of 3.0 seconds to
expire, the overall execution time is quite long. We have a risk
of the test execution being aborted due to the guard timeout.
I agree that using g_AllChannels[] makes sense for TC_ho_rach, which
tests handover RACH detection. There we want to be sure that detection
works on all slots of all DCCH types (especially when running a setup
with real MS/BTS hardware).
But for both TC_sacch_chan_act_ho_{sync,async} it's enough to run
on different channel types (see g_AllChanTypes[]), because what
we actually want to test is the Downlink SACCH operation.
Change-Id: Ic1937edd72ff842cb619e153d0f6a624ceb95281
Related: SYS#5838, OS#4008, OS#4009
According to 3GPP TS 48.058:
* 4.1.3 async handover: "If the MS Power IE is present the BTS
*may* start transmission also on the SACCH".
* 4.1.4 sync handover: "If only the MS Power IE is present the BTS
*may* start transmission also on the SACCH".
"May" does not mean "shall", so osmo-bts does not.
Change-Id: I5e97944e56b7860f2d912cd8d3c978a0f1e08645
Related: SYS#5838, OS#4008, OS#4009
TTCN-3 offers a very convinient way of matching an octetstring
against a record template (decoding target) on the fly, so that
there is no need to attempt decoding it manually beforehand.
This can be done by using the 'decmatch' keyword (see B.1.2.9).
Unfortunately, decmatch fails if an octetstring is longer than
the encoded variant of the decoding target (e.g. has padding).
Let's work this around by adding a 'padding' field, so during
decoding all remaining octets will be stored in it.
Change-Id: I0151adf7790127617f7cb57c9a9ec6c28721e95a
Related: SYS#5838
This eliminates the need for using log2str() and improves readability.
Change-Id: Iaf9b03fb81ec4fa2ca4f0a0b2f0b50491c6a9d80
Related: SYS#5838, OS#4008, OS#4009
Test new osmo-sgsn Iu attach with UEA (encryption) enabled
Related: SYS#5516
Depends: I27e8e0078c45426bf227bb44aac82a4875d18d0f (osmo-sgsn)
Change-Id: I1a7c3b156830058c43f15f55883ea301d2d01d5f
Due to a bug in the current osmo-bsc master, osmo-bsc inverts
the band indicator bit in SI6 Rest Octets. This change extends
testing coverage to demonstrate the problem (see TC_si_default).
Change-Id: I93e1fcfaea973ec2461e30f656d5f5f0d829909b
Related: osmo-bsc.git Iaa8377919a144e7f3799b76249f579c8f3874145
We'll start emulating other Diameter-based interfaces soon (Gy), so
let's rename existing stuff which is Gx specific.
The DIAMETER_Emulation only supports handling 1 application-id per
component, and that's fine anyway since the OCS is in general expected
to run in a different conn/node from PCRF.
Change-Id: I1eb03d907b46c4bb24491f390ef468e831190e08
Otherwise a new test may reuse the same GTP seqnum, and if it's still in
the gtp retransmit resp queue of the GGSN, it may be identified as a
duplicate retransmittion of a previous message (previous test) and send
back the previous response instead of processing the request.
Related: OS#5485
Change-Id: I1b04691987b883f63c95c0322a477db4a43df2b1
So far, osmo-bsc ignored the Codec List (MSC Preferred) in inter-BSC
incoming HO Request messages. Starting with osmo-bsc
I117cc29d6d11db77d160de654f43f5993db6ee21, a missing codec list on AoIP
causes incoming inter-BSC HO to fail, as it should (3GPP TS 48.008
indicates that a codec list shall be included on AoIP). To avoid test
fallout when merging above osmo-bsc patch, add a codec list to HO
Request on AoIP.
Related: OS#5839
Change-Id: If06de9c9b43d79f749447a4e2a340176eef75c79
Test inter-BSC incoming HO where the Handover Request message is not
included in the initial SCCP N-Connect, but follows in a separate DT1.
Related: SYS#5864
Depends: I535c791fa01e99a2226392eb05f676ba6c3cc16e (osmo-bsc)
Change-Id: I6732153cdd0d529bfaf0925387e765f3403a756b
Since I just fixed the encryption behavior, I also want to know whether
the case of no A5 intersection is handled properly.
The tiny test comes with a lot of changes to allow a handover failure
code path. The 'expect_ho_fail' flag goes via function arguments to
g_pars and the general ho test code uses it to branch for exp-failure.
Related: SYS#5839
Change-Id: I44b464a0bedbff09c467c4bccd7c985480fb883a
Expect IEs Speech Codec (Chosen) and Codec List (BSS Supported), they
are missing in current osmo-bsc.
Related: SYS#5839
Depends: I3c0576505a3ceb3cd5cc31dc69c5bc4a86a4ea08 (osmo-bsc)
Change-Id: Ib2b4e27be241e2a92c0c3bffdf906bf22c09352b
This catches up with a recent change in simtrace2.git
(Change-Id I4cdb250d2e1dbc5b8b0169f8b7c21e288b492e1d) adding
a new optional field to CardEmu_BD_Config
Change-Id: Id29584764a2f27b9de5fa9ff67fd0ae3e912f02e
Doing this when receiving an IPv4 EUA thwos an error:
"if (not match(cpr.endUserAddress, tr_EuaIPv4(?)) and not match(cpr.endUserAddress, tr_EuaIPv6(?)))"
Dynamic test case error: Performing lengthof() operation on an octetstring template with no exact length.
This happens if for instance received spare bits are set to '0000'.
Change-Id: I70ad3c10e2ecfed8f733ff906272a9597b2ab9bd
This should prevent following race conditions at shutdown:
"""
131 - Terminating component type PCUIF_Components.RAW_PCU_BTS_CT.
...
PCUIF_Components.ttcn:642 Dynamic test case error: Sending data on the connection of port BTS to 131:PCUIF failed. (Broken pipe)
"""
Change-Id: I17b2cfed2edbea7427e608380059bb1b422ca600
Internal BVC components in BSSGP are now created as alive. We have to
create also BSSGP one as alive in order to avoid having the BVC
component sending stuff to the BSSGP when it has already been killed:
BSSGP_Emulation.ttcnpp:1133 Dynamic test case error: Sending data on the connection of port BVC to 486:BVC failed. (Broken pipe)
Change-Id: I369a5e2246204416c2f29a114bde6bc21f7eaf4f
Otherwise, during shutdown of all components we may end up in a
situation where the BVC is already killed and BSSGP Emulation receives
a packet which tries to forward to BVC and fails.
This can be seen quite a lot in PCU_Tests.TC_pcuif_suspend:
"""
PCU_Tests.ttcn:394 setverdict(pass): none -> pass
...
PCUIF_Components.ttcn:246 Stopping test component execution.
...
GPRS_Components.ttcn:222 Connection of port BSSGP[0] to TC_pcuif_suspend-BVCI1234(6):BSSGP_SP was closed unexpectedly by the peer.
...
GPRS_Components.ttcn:222 Port BSSGP[0] was disconnected from TC_pcuif_suspend-BVCI1234(6):BSSGP_SP.
...
Component type BSSGP_Emulation.BSSGP_BVC_CT was shut down inside testcase TC_pcuif_suspend
...
BSSGP_Emulation.ttcnpp:317 Dynamic test case error: Sending data on the connection of port BVC to 6:BVC failed. (Broken pipe)
"""
Change-Id: Ib0adcf64eb5ca876cd9e9b91f2b597804c03bdc2
Should fix following TTCN3 warning during runtime of
PCU_Tests.TC_pcuif_suspend:
"""
BSSGP_Emulation.ttcnpp:462 Timeout operation on timer g_T2 failed: The timer is not started.
"""
Change-Id: Ic74572a21b5abee8e530741466360ff7e16a357d
The test was expecting to always receive at least 1 DL packet with
USF_UNUSED, but since we implemented idle blocks in PCUIF that may not
always be the case anymore. If the TBF is freed in between last
requested block and next one, there may be no TBF and hence no MS
listening on the TS, so PCU will optimize and send an idle block.
Change-Id: Ia301c01a3f5c3fd0b11d8f20e39061aa7abc6127
If the RAN_Emulation is started before the VTY reconfiguration we could
get a BSSMAP Reset/ResetAck with Osmux support advertised even though
the test expects it to be disabled (or vice versa).
Do the VTY configuration before starting the RAN_Emulation.
Fixes sporadic/load-related TTCN3 failures with message
"BSSMAP: Timeout waiting for RESET-ACK after sending RESET"
(e.g. TC_iu_and_mt_call_osmux, TC_iu_and_mo_sms in run +1567)
Change-Id: Ife23f70c6523034f3c3c53b6c1c81428566fd43e
The templates ts_RANAP_RabAssResp and tr_RANAP_RabAssResp miss the
option to send a RAB_FailedList. This is needed to simulate a RAB
assignment that fails at the HNB
Change-Id: I95c7c51587981d9f478b9d31fcde139f228fa87f
Related: OS#5152
This test should be failing as it is, because A5/4 is not permitted in
the BSC's configuration! It only passed all this time because osmo-bsc
is/was/is going to have been flawed and just takes the Chosen Encryption
Algorithm IE as the basis for choosing an encryption algorithm. Instead
it should intersect the pemitted algos with the BSC config. It will soon
do that, and then this test would fail as it should have. After fixing
the BSC config for the test with this patch, we'll not see it failing in
the transition.
Related: SYS#5839
Change-Id: Ic6bbbeea36e6ea26d16bbb510fd08f5c0defb955
Report: in inter-BSC incoming handover, when the MSC omits the Chosen
Encryption Algorithm IE in the Handover Request message, then osmo-bsc
starts an unencrypted lchan even if A5/0 is not permitted.
This test verifies that the Encryption Information is present in the
Channel Activation when the Chosen Enc Alg is omitted.
Related: SYS#5839
Change-Id: Ia94cc29bf66339ed782cb5101f3640f69cf73131
Clean up: absorb pars.encr_exp_enc_alg into TestHdlrEncrParams as
pars.encr.alg_expect.
Remove the automagic encr alg choice from test procedures, instead put
all magic in the pars.encr configuration setup; like this all encr alg
values remain fixed through the tests, less confusing.
Add separate alg_chosen for BSSMAP: So far, we have only one algorithm
field for both the mask of permitted algorithms in the Encryption
Information IS and the Chosen Encryption Algorithm IE. However, in the
Chosen Enc Alg there must be only one bit set. Thus we cannot easily run
a test where more than one alg is permitted and where the BSSMAP Chosen
Enc Alg IE is involved.
We've recently come to realize that the Chosen Encryption Algorithm IE
may also be omitted from BSSMAP messages, in which case osmo-bsc should
still work. To be able to test BSSMAP messages with omitted Chosen
Encryption Algorithm, allow to set alg_chosen == omit.
Keep t_EncrParams() in a way that all current tests (that set only one
bit in alg_permitted) still run the same as they always did.
Add t_EncrParams2() for a proper template.
Add a convenience function to configure encryption testing.
Related: SYS#5839
Change-Id: I6590ecf4a146dbed494d9d72f5a79441877e9010
This test validates that changing the local TEID through UpdatePDPContext
is correctly followed by the GGSN.
Change-Id: Ic6af25866bf7efc2cabf029e49abaf15d5857592
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Harald Welte
Daniel Willmann
Philipp Maier