OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit makes sure TTCN3 tests pass valid l3 payloads to osmo-bsc,
so that they keep working once osmo-bsc starts rejecting invalid IEs it
parses.
Related: SYS#6280
Change-Id: I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit is another step towards passing proper l3 data to osmo-bsc
in TTCN3 tests.
Related: SYS#6280
Change-Id: I012dbdc673ff98a6647280ce3d0245abff86cfa4
Adjust the test to also check the special case ARFCN=0, which is at the
end of each sub list.
Related: OS#5717
Related: osmo-bsc Ic5e4f0531e08685460948b102367825588d839ba
Change-Id: Ia8f94d72651061427afc9e34f678544f89d0149b
For the purpose of testing MGW pooling, test cases TC_mgwpool_*
configure an additional MGW instance by calling f_vty_mgw_enable()
and then remove it by calling f_vty_mgw_disable().
Unlike the other two TC_mgwpool_* test cases, TC_mgwpool_pin_bts
does not call f_vty_mgw_disable() - this breaks LCLS testcases
executed after it. Add the missing call.
Change-Id: I3157203888d704b25aabd2569035cd95d48c48b2
Fixes: 3f41e321c7
Fixes: OS#5727
Add a couple tests to validate some MGW pool features, like load
balancing and skip selection blocked MGWs from the pool.
Related: SYS#5987
Change-Id: I6a8c30309be406e37190dc67b6ee5af13e1b9e68
OsmoBSC has supported this VTY interface since more than a year ago.
Let's update the config files to use the new "mgw" node.
The recently submitted VTY commands without the redundant "mgw" prefix
are still not used here in order to have the config file work with
latest release which still doesn't support those.
Related: SYS#5987
Change-Id: I9b869e6bf4a3910f38014d570dce27e67af6e0d6
The RSL_IE_MultirateCfg was implemented and added to union RSL_IE_Body
in [1]. Before this change, this IE was decoded as RSL_LV (basically
an octetstring). Now this IE is decoded as RSL_IE_MultirateCfg, while
some AMR tests still expect RSL_LV. Let them use RSL_IE_MultirateCfg.
Change-Id: I40dab41d5dc5d14e358ba5a070ce174e7d8d4a4b
Fixes: [1] I0a5ddce570c0fd70f096d897b0b609d20b552ff7
Currently this testcase fails:
RSL MR CONFIG IE does not match expectation.
Expected: { other := { len := 2, payload := '2804'O } }
Change-Id: Icc5381eccb924803b1117b46d2b4c47cee6dabd7
This way it's easier to see that the only difference from other
tests using c_mr_conf_5_90 is the ICMI field set to false.
Change-Id: If7b491fa55a9366520c2d665a700c5badb187fae
* This is a global constant, so prefix with 'c_' for consistency.
* The RSL_IE_MultirateCfg is all about AMR, remove redundant 'amr'.
Change-Id: I72405b7139fcfd0dbe90afc469ed4db71b43a87c
The per-BTS VTY command 'osmux (on|off|only)' was added to osmo-bsc.git
recently, and is not available in -latest yet. Use it conditionally.
Change-Id: Id501d3f4b5eb18b096d8baffcb5f38e583f7a3d8
Fixes: I6e82eb9d995de988b812001e1c4cf6923509de66
New TC_assignment_osmux_bts is added which tests Osmux used only
BTS<->BSC.
Existing TC_assignment_osmux is renamed to TC_assignment_osmux_cn,
and a new TC_assignment_osmux is added which tests using Osmux on both
sides (towards BTS and CN).
Related: SYS#5987
Change-Id: I6e82eb9d995de988b812001e1c4cf6923509de66
In cases a), b), c), d), and e) we're sending one or more Measurement
Reports via the A-bis/RSL, and then immediately triggering a traffic
channel assignment by calling f_TC_chan_alloc_algo(), which sends an
Assignment Request via the A interface.
The above-mentioned messages are sent immediately all together, so it
may happen that the BSC handles the Assignment Request earlier than
the Measurement Report(s). In this case there will be no RxLev
samples, so the BSC would fall-back to ascending allocation order.
Recently we saw this race condition actually happening on Jenkins:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1583/
Let's introduce an artificial delay before sending the Assignment
Request, so that the BSC has enough time to process received MRs.
Change-Id: I2fd6508488e935d208a7aba8e2f215b1cc14ad32
We want to add more options later on, and we don't want to be passing
all of them as params. Let's simply set the global fields directly in
the test and let f_init() use the confgured values.
Change-Id: I27b685c2c22cf876b5eba79cf8ad151a2643ecb1
That config is used to control the use of osmux between BSC<->MSC. Since
we'll add support for Osmux in BTS<->BSC, we want to test that in a
separate way. Let's rename it so that we can add a "use_osmux_bts" later
on.
Change-Id: I3bde4e6772c18043dd763d7747b5dbe40e0da3b8
BSC_Tests_CBSP was sending an ETWS message but using non-ETWS templates
to match the response, which may differ from an ETWS one (for instance,
ETWS related messages have no channel_ind).
Change-Id: I42941655081af6d5b04b1e061e6259d8dee94665
This test case verifies the new channel allocation mode, which
is expected to switch between ascending and descending modes
dynamically based on the following two configurable parameters:
* Uplink RxLev threshold (and min number of samples),
* C0 (BCCH carrier) channel load threshold.
The test case scenario includes:
Case a) Unknown Uplink RxLev => fall-back to ascending.
Case b) Not enough RxLev samples => use ascending.
Case c) Uplink RxLev below the threshold => use ascending.
Case d) Uplink RxLev above the threshold => use descending.
Case e) Uplink RxLev above the threshold, but C0 load is not.
Change-Id: Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
The aim of these new test cases is to verify both ascending and
descending modes of the BSC's channel allocator. Both tests are
using BTS2, which has 4 TRX instances.
The common test scenario can be described as follows:
1. Establish an SDCCH channel, send some dummy payload on it.
2. Send a BSSMAP Assignment Request for a TCH/F channel.
3. Expect RSL CHANnel ACTIVation for a TCH/F channel.
4. Respond with RSL CHANnel ACTIVation NACK (*).
5. Expect a BSSMAP Assignment Failure.
These steps are repeated several times. Note (*) that for the
sake of simplicity, I am aborting the assignment procedure by
sending a NACK, so that the requested logical channel becomes
BORKEN and behaves like an occupied one until the A-bis/OML
link is re-established. This reduces the overall complexity.
Change-Id: Ic74a9cd264320a9a17648f9331b67fb2c2404122
Related: SYS#5460
As described in 3GPP TS 48.049:
7.8.2: "The RESTART message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
7.9.2: "The FAILURE message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
Related: osmo-bsc.git Change-Id I6668b55868cf534a3b59da5e11542abb8131d604
Related: SYS#5910
Change-Id: I05da2f61d26a1124d30793184d81aabf212cddda
New versions of osmo-bsc send CGI instead of LAC+CI, which provides more
information (PLMN).
Related: SYS#5910
Change-Id: I48e86150f499f0f458f75f132087319d80f86448
Recently I noticed sporadic CBSP test case failures on Jenkins:
Timeout waiting for RSL_OSMO_ETWS_CMD (disable)
BSC_Tests_CBSP.ttcn:1209 BSC_Tests_CBSP control part
BSC_Tests_CBSP.ttcn:1056 TC_cbsp_emerg_write_bts_cgi_cchan_disable
The related timeout is set to 5.0 seconds in f_exp_rsl_etws(), what
matches the Warning Period IE sent in CBSP WRITE-REPLACE message.
Adding a debug log printing T.read on receipt of RSL_OSMO_ETWS_CMD
reveals that we're cutting it too close: the message arrives just
a few milliseconds before the timeout expires.
f_exp_rsl_etws(): T := 4.999196s, remaining 0.000804s
f_exp_rsl_etws(): T := 4.998683s, remaining 0.001317s
f_exp_rsl_etws(): T := 4.999344s, remaining 0.000656s
Let's increase the timeout value (+0.5s) to avoid sporadic failures.
Change-Id: Ia40a268f9780ffbcfa2bb962d7c1ac25d16193de
A follow-up patch is adding BSC_Tests.f_shutdown_helper() calls to all
CBSP testcases, what makes TC_cbsp_emerg_write_bts_cgi_dchan fail due
to talloc count mismatch. All dchans need to be released to avoid this.
Change-Id: I8b707c821693f930ab10bd8feea08ba5007da967
This allows BSC_Tests_CBSP to import friendly API from BSC_Tests.
The line importing stuff from BSC_Tests BSC_Tests_CBSP.ttcn is moved
on top for consistency with an existing friend - BSC_Tests_VAMOS.
Change-Id: Ie0bb5c2e33aadd4858f0f6d001468985c40ab152
The TC_imm_ass_pre_chan_ack_dyn_ts sporadically fails on Jenkins.
Similar to [1], this is happening because the VTY command setting
the 'immediate-assignment' strategy back to 'post-chan-ack' is
being sent/processed earlier than the CHANnel REQ message.
TC_imm_ass_pre_ts_ack_dyn_ts is likely affected too, also fix it.
Change-Id: I1e38142d29d0fa2946a858eac13319aa05b42aa3
Related: [1] I38cd31041741b69eb15098a089b4d4b6b918ffd4
Recent commit changing the layout of bts/trx port config made
IPA_CFG_PORT be connected severa times when calling f_ipa_rsl_start()
for each BTS/TRX.
Let's have separate ports per BTS/TRX as done in other ports in the
test_CT component.
This avoid this error when calling f_ipa_rsl_stop():
"""
Dynamic test case error: Port IPA_CFG_PORT has more than one active
connections. Message can be sent on it only with explicit addressing.
"""
Change-Id: I916186c87c398ebb2d7f82f73b94de75034e346d
So far it was possible to communicate with multiple BTS instances,
however we were limited to only one IPA/RSL connection per BTS.
Communicating with additional TRX instances requires establishing
additional per-TRX IPA/RSL connections. This patch extends the
testsuite infrastructure, so that it becomes possible to have
up to 4 individual TRX instances for each BTS.
* Introduce record 'BtsParams', store per-BTS params in an array.
* IPA_RSL_PT: test_CT.IPA_RSL[NUM_BTS] -> test_CT.IPA_RSL[NUM_BTS][NUM_TRX].
* BTS_State: test_CT.bts[NUM_BTS] -> test_CT.bts[NUM_BTS][NUM_TRX].
* f_init_bts_and_check_sysinfo() accepts number of TRX instances.
* f_init_bts() accepts number of TRX instances to configure.
* f_ipa_rsl_start() accepts a BtsTrxIdx param.
* Introduce record BtsTrxIdx allowing to specify BTS/TRX index values.
* f_ipa_tx(), f_exp_ipa_rx() accept a BtsTrxIdx param (default {0, 0}).
* f_est_dchan[_dyn]() accept a BtsTrxIdx param (default {0, 0}).
** and store the given BtsTrxIdx in returned DchanTuple.
* f_chreq_act_ack() accepts a BtsTrxIdx param (default {0, 0}).
* f_expect_chan_rel() accepts a BtsTrxIdx param (default {0, 0}).
* f_exp_ipa_rx_nonfatal() accepts BtsTrxIdx (default {0, 0}).
* f_exp_chan_rel_and_clear() uses BtsTrxIdx indicated in the given DchanTuple.
* Fix CTRL/statsd expectations in TC_stat_num_bts_connected_[123].
* Fix CTRL expectations in TC_ctrl_trx_rf_locked.
The major limitation is that MSC_ConnHdlr components still have no
access to additional TRX instances - this can be implemented later.
Change-Id: Ic0fd97234464ef624010a5f01189aa61f3393b84
Related: SYS#5460
When running ttcn3-bsc-test against osmo-bsc in SCCPlite mode,
TC_lost_sdcch_during_assignment fails with the following output:
Local verdict of MTC: fail reason: "Timeout of T_guard"
Final verdict of PTC: fail reason: "Unexpected DLCX received"
One key problem is that in f_TC_lost_sdcch_during_assignment() we
expect to receive a DLCX message on port MGCP, but somehow it gets
caught by the as_Media_mgw earlier than we attempt to receive it.
* Fix this race condition by activating the as_Media_mgw with
fail_on_dlcx := false, so that it does not catch DLCX messages.
Another problem is that for SCCPlite we're running the MGCP_Emulation
component with multi_conn_mode=true, so that all MGCP messages are
arriving at port MGCP_MULTI (not MGCP) wrapped into MGCP_RecvFrom.
* Expect the DLCX message on either of the two ports depending
on the value of g_pars.aoip (AoIP or SCCPlite mode).
This change makes BSC_Tests.TC_lost_sdcch_during_assignment pass.
Change-Id: If4807d3d7d196682f7f22732ad47bcbb72858ed3
These test cases sporadically fail on Jenkins and 9/10 times on my
machine. The problem appears to be that we are sending both the
RSL CHANnel ReQuireD and the VTY command simultaneously, and the
later may be handled earlier than the former by osmo-bsc.
Ensure that the RSL message is handled first by sending the VTY
command after we have received the RSL CHANnel ACTivation message.
Change-Id: I38cd31041741b69eb15098a089b4d4b6b918ffd4
Test this scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
(Do not send Clear Request immediately);
Location Request is completed, locating the emergency.
Related: SYS#5912
Related: Ib44dd05b0adee84234f671313b156ff6625357cc (osmo-bsc)
Change-Id: Idea690a4aa4aecbe4642a16e96d086cc0538564a
First, page only on BTS0, not all the BTS. This simplifies the test and
also makes the subscriber be refcounted only on BTS0.
Then, drop the OML connection after receiving all the expected paging
requests; it will make the BSC flush the paging queue and hence avoid
TTCN3 checks erroring due to dangling subscriber talloc contexts.
Change-Id: Ibbd9168f3ac2c1cd4f4577644d75499d49c2823f
The paging CCCH Load Ind should only be sent when the BTS is over the
threshold, which is not the case when it starts up.
The BSC should underststand that the BTS under threshold and be able to
send paging requests.
Change-Id: I19a97e97ec96ba8ea2e28b1be8ac3b706b43e1b7
This adds new tests:
* TC_cbsp_emerg_write_bts_cgi_noreplace
* TC_cbsp_emerg_write_bts_cgi_replace
* TC_cbsp_emerg_write_bts_cgi_kill
All of the above relate to improved / fixed handling of emergency
broadcasts in some corner cases.
Related: SYS#5906
Related: OS#5539, OS#5540
Change-Id: Ic0f0b3d620f3ca73bab3d45997d0c1b9433ac1f7
A more clear reading of TS 48.049 is that the KILL COMPLETE should
*only* contain a Cell List IE if it relates to an Emergency message;
only the Number of Broadcasts Completed IE indicates successful
cells.
osmo-bsc fixes this in I9a43d386da01f085663d231a555b8b5acc99faca
Change-Id: Ia50e50f9812d9934d35d32b25e1079240df04a82
Related: SYS#5906
After osmo-bsc Change-Id I1ae6d97152c458247bc538233b97c2d245196359,
initial requests are prioritized over retransmits.
Before that feature was in place, when sending 500 requests in this test
to the BSC, it could happen that the paging scheduler triggered (every
500ms) before all the 500 requests were received at the BSC. As a
result, the scheduler would put some requests to the end of the queue
after sending an initial request for it towards the BTS. If later more
requests where received from TTCN3, they'd be put at the end, after the
retransmissions.
As a result, the emulated BTS would in general receive retranmits for
the first bunch of requests before receiving the initial transmit of the
later requests.
Ths is no longer the case since the osmo-bsc is prioritizing now the
initial requests. Hence, we'll only start receiving retransmits after
all the new paging requests are received.
Depends: osmo-bsc.git I1ae6d97152c458247bc538233b97c2d245196359
Change-Id: I5876f828b43e1e51bd892ce3c9a4dbed6b53f066
On the first TCH, establish Layer 3 so that the BSC will issue a Clear
Request at all.
Verify the cause value of the Clear Request.
Tear down the established Layer 3: clean up for the leak check.
Related: OS#5535
Depends: I20108f7b4769400b89b7b0d65c8dab883bf87c46 (osmo-bsc)
Change-Id: Ib13be73119cfc96712f32899c02e655e1751d547
Rename chan_nr to first_tch, and more clearly show that the TCH that is
released gets assigned to the emergency call.
Related: OS#5534
Change-Id: I0c540d76eedfd4115b410921bf5a0b6c2d00b5c2
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. osmo-bsc is including this IE as of Change-Id
I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
This change updates the test suite to expect this IE to be included.
Change-Id: I5b56676c93479ec7b32cff66c9738fff7d0228cf
Related: SYS#5906
The default AMR link adaptation parameters have been changed in
the recent osmo-bsc, so set the old expected default explicitly.
Change-Id: I320d91a35bc50bdfe87c0384035a10b8672ef23c
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917
Deactivate as_Media() once the handover is completed, so that it does
not fail on the expected MGCP DLCX from release.
Fix fallout seen in these tests:
SCCPlite
BSC_Tests.TC_ho_into_this_bsc
BSC_Tests.TC_ho_into_this_bsc_a5_0
BSC_Tests.TC_ho_into_this_bsc_a5_1
BSC_Tests.TC_ho_into_this_bsc_a5_3
BSC_Tests.TC_ho_into_this_bsc_a5_4
BSC_Tests.TC_ho_into_this_bsc_a5_1_3_no_chosen_enc_alg
BSC_Tests.TC_ho_into_this_bsc_a5_1_3
BSC_Tests.TC_srvcc_eutran_to_geran
BSC_Tests.TC_srvcc_eutran_to_geran_a5_3
BSC_Tests.TC_srvcc_eutran_to_geran_src_sai
BSC_Tests.TC_srvcc_eutran_to_geran_forbid_fast_return
BSC_Tests.TC_ho_into_this_bsc_sccp_cr_without_bssap
All of these tests use f_ho_into_this_bsc().
(It is not clear to me why only the SCCPlite tests show the fallout, the
AoIP should be similarly affected, but isn't.)
The failures were introduced by recent merge of
I0633f60f09d58802f6be0238ef41a632d93a4327, which made as_Media()
stricter by failing on early DLCX.
Related: SYS#5916
Change-Id: Ic5650a48eb3d90f2b42f16685178c97b54473429
An emergency call often comes with a Location Request. Make sure
osmo-bsc handles it well.
Related: SYS#5916
Change-Id: I95037374c45943cb14401bc48f16a39c2fcbe1f5
as_Media_mgw() is used to establish a voice stream. If a DLCX happens as
part of that, that should be flagged as a problem.
In fact the Mode Modify test with current osmo-bsc does exhibit a DLCX
right upon the Assignment Complete message, which is a bug fixed in
I5ab10ee7fd9c5d7608e8a06893881d990943feed.
This patch now correctly flags this as a failure.
In the two tests
TC_ho_in_fail_no_detect, TC_ho_in_fail_no_detect2
the expected failure causes expected DLCX, so exempt those.
Related: SYS#5916
Change-Id: I0633f60f09d58802f6be0238ef41a632d93a4327
ranops was not isvalue because bssap_reset_retries was not set and not
explicitly omitted either, so the ran adapter decided not to create a ran
emulation...
Change-Id: Ibbef035929ec861fec1e8554460e22650b386f83
Using a guard statement makes no sense given that we match the
cellSelectionIndicatorValue conditionally within the alt branch
itself. Removing that guard statement eliminates the need to
have an additional alt branch with identical body.
Change-Id: I373376637a083637ce01f3ac59fe5fd2836ac6cd
RR Cause is a mandatory IE, so it cannot be omitted. Therefore it
makes no sense to check if istemplatekind(expect_rr_cause, "omit").
Change-Id: I564d00a4715b86d248bce449d2b9193ac5e99008
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
In f_ho_into_this_bsc(), check presence and correctness of the Cipher
Mode Setting IE. Add TC_srvcc_eutran_to_geran_a5_3, which is similar
to TC_srvcc_eutran_to_geran, but enables ciphering on the target channel.
This patch makes all SRVCC relates test cases fail, until [1] is merged.
Change-Id: Ic3dfc4e31a7ed078cdfdaced9986ee9551c5aa7c
Related: [1] osmo-bsc.git I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
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
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 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
Properly clean up conns in the end. Use COORD and new COORD2 ports to
daisy-chain coordination between the four components.
Related: OS#5444
Change-Id: I3b1dfc3b11e990893cbf182fb9f8840e198eb8aa
Properly clean up conns. To know when the multiplex is ready, use the
COORD port to tell the other component.
Related: OS#5444
Change-Id: I82b7eccd2ae30fdc3794ea9dad5d2d8f875d702d
This change makes the following test cases pass:
* TC_mode_modify_to_vamos_fr
* TC_mode_modify_to_vamos_hr
Change-Id: Icb47e39a5466a1232cda03e1e04b0c88f3927659
Related: OS#5444
Keeping the logical channel active may affect test cases executed
after TC_chan_act_to_vamos. Clean up after the test to avoid that.
Change-Id: Id0e3fb6a2f7e97ef854bff95adbc715d6f41f069
Related: OS#5444
This parameter allows to enable/disable checking of the IUT's talloc
report in f_shutdown_helper(). This may be useful when running the
test suite against '-latest' with unfixed memory leaks.
Change-Id: Ic7bf8d9def21083ebda1b94659d72dde2bb5e664
Three tests fail after recent patch
"bsc: properly clean up conn after each test"
I9396efcabc085d2850244c6468b83c5f3a3ff3a2
In TC_assignment_emerg_setup_deny_bts(), do not expect an RR Rel.
In TC_assignment_emerg_setup_deny_msc() and TC_cm_reestablishment(),
drop the additional f_expect_dlcx_conns().
Related: OS#5337
Change-Id: I1d1d27f0927e640a430b24c6dc3d5d851a5c4cb9
Make all tests clean up BSSAP conn and RSL link. Now all
f_verify_talloc_count() in f_shutdown_helper() should pass, verifying no
conn or bsc_subscr leaks.
Related: OS#5337
Change-Id: I9396efcabc085d2850244c6468b83c5f3a3ff3a2
ACK any MGCP DLCX or RLL REL REQ during f_perform_clear(), which makes
it more universally applicable to invoke at the end of a test.
Related: OS#5337
Change-Id: Ie5b77c266a5d8f47edd187c474df281a799a81de
Invoke f_verify_talloc_count() for bsc_subscr and
gsm_subscriber_connection, expecting none to remain after each test.
This makes numerous tests fail, where the test does not properly release
the RSL and BSSAP connections. An upcoming patch fixes all of those
cases: I9396efcabc085d2850244c6468b83c5f3a3ff3a2
Related: OS#5337
Change-Id: I69d4c5c6f8d499bb7f0b96a48af045361433c57b
To be able to invoke perform_clear() also in tests where the VTY isn't
used, in f_logp() only access the VTY when it is actually ready.
Otherwise this causes an error and a failed test, for no good reason.
Related: OS#5337
Change-Id: I8116075f32937bd06ba14b426010bf6fec2ef402
Cause GSM0808_CAUSE_MS_NOT_EQUIPPED is to be transmitted only in the case
BSC receives a RelInd from the MS/BTS. In this test, an ErrorInd is
sent, as in TC_rll_err_ind_sapi_n_reject, so it is expected that the
BSC will send the N_Reject message with cause
GSM0808_CAUSE_BSS_NOT_EQUIPPED.
Related: OS#4728
Related: SYS#5047
Fixes: 999ceb6637
Change-Id: Ieebe3465b31d98fcae0e2c1993477c5021c99b3b
IPA_Emulation component was marked with the "alive" type recently, in
order to avoid race conditions leading to errors during tear down of the
test.
It turns out, the way "alive" keeps the component alive is by means of
not closing the sockets when the component is stopped. As a result,
TC_rsl_drop_counter test stopped working properly because it was
specting a TCP FIN to be sent to osmo-bsc when the component was
stopped.
In order to fix it, add a new CFG port to the IPA_Emulation component on
which one can operate. Add a a new method to tell the component to close
the socket.
Then, put that in BSC_Tests into a function which was actually unsued
until now, and use it in the test in order to have the specific logic
enclosed in a function helper.
Fixes: 7138913d66
Change-Id: I68163b053313d9907ba8e40954a5933d14cb7db6
Pau Espin
Vadim Yanitskiy
Oliver Smith
Neels Hofmeyr
Harald Welte
Eric Wild