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
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
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
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
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
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
Otherwise it's impossible to run the CBSP test cases locally, because
the remote peer address in osmo-bsc gets set to '0.0.0.0', so indeed
it cannot establish connection to the server.
Change-Id: I5b1d215818255717ed955c9f1a9c45505ab11a65
Fixes: OS#5351
With Icaa2775cc20a99227dabe38a775ff808b374cf98, osmo-bsc no longer allows
configuring CBSP as both server and client at the same time, and the 'cbc' VTY
section has a different structure.
Adjust the 'cbc' section in osmo-bsc.cfg.
For each CBSP test init, switch osmo-bsc's CBSP link to server or client mode
by new vty command 'cbc' / 'mode (server|client|disabled)'.
Related: Icaa2775cc20a99227dabe38a775ff808b374cf98 (osmo-bsc)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Related: OS#4702
Change-Id: I7eea0dd39de50ed80af79e0f10c836b8685d8644
When receiving the instruction to CBSP RESET, osmo-bsc should stop CBSP
broadcasting on all affected BTSes. Expect the according zero-payload ETWS CMDs
on all CBSP relevant RSL ports.
This behavior is implemented by osmo-bsc
I925a041936c6163483d70fe6d158af368ec8c444
This is expected to break all CBSP tests until above bsc patch is merged,
particularly the 'latest' tests will see this breakage until the next release
is tagged.
Depends: I925a041936c6163483d70fe6d158af368ec8c444 (osmo-bsc)
Change-Id: Ifee313369a433a6a638c5fffdedee5363b8e47c2
the argument given to tr_ASP_RSL_UD() needs a 'present' qualifier, as it
cannot be 'omit'
BSC_Tests_CBSP.ttcn:524.1-537.1: In testcase definition `TC_cbsp_write_lac':
BSC_Tests_CBSP.ttcn:532.2-535.2: In interleave statement:
BSC_Tests_CBSP.ttcn:533.5-41: In guard operation:
BSC_Tests_CBSP.ttcn:533.5-41: In receive statement:
BSC_Tests_CBSP.ttcn:533.37-40: In actual parameter list of template `@IPA_Emulation.tr_ASP_RSL_UD':
BSC_Tests_CBSP.ttcn:533.38-39: In parameter #1 for `rsl':
BSC_Tests_CBSP.ttcn:533.38-39: warning: Inadequate restriction on the referenced template variable `tr', this may cause a dynamic test case error at runtime
BSC_Tests_CBSP.ttcn:531.27-82: note: Referenced template variable is here
BSC_Tests_CBSP.ttcn:534.5-41: In guard operation:
BSC_Tests_CBSP.ttcn:534.5-41: In receive statement:
BSC_Tests_CBSP.ttcn:534.37-40: In actual parameter list of template `@IPA_Emulation.tr_ASP_RSL_UD':
BSC_Tests_CBSP.ttcn:534.38-39: In parameter #1 for `rsl':
BSC_Tests_CBSP.ttcn:534.38-39: warning: Inadequate restriction on the referenced template variable `tr', this may cause a dynamic test case error at runtime
BSC_Tests_CBSP.ttcn:531.27-82: note: Referenced template variable is here
Change-Id: Id64e8e135b690c34293487304d7a175b5b56265b
Some tests may stop without cleaning up the CBSP state. Avoid affecting
subsequent tests by clearing the state for each f_cbsp_init_server().
Some ETWS CMD may still be left in the RSL queue (from the time period passing
between a stopped test and the next test starting up), so clear all RSL ports.
To be able to do so, move f_cbsp_reset_bss() to the cbsp_test_CT, from where it
can access both CBSP and IPA_RSL[] ports. All current callers are on
cbsp_test_CT anyway.
This patch should fix TC_cbsp_emerg_write_bts_cgi_cchan and
TC_cbsp_emerg_write_bts_cgi_cchan_disable, which so far break because of
leftover ETWS CMDs in the RSL queue from the preceding test run.
Change-Id: If7400a6624bb6dd9cacbcc733bdeba102d19e29c
For each CBSP test, define one global set of CBSP msg id and serno for use by
that test.
Each CBSP test should use a distinct message id and serial nr, to not get mixed
up with previous state. But keeping those numbers manually is a confusing pain,
and as a reader it is hard to follow how these numbers change (if they do).
In f_cbsp_init_server(), require a preset of msg id and serno to be used in
that test, and from then on only use g_cbsp_msg_id and g_cbsp_ser_no instead of
magic numbers. If they change, write it out explicitly, making it easy to
follow what is expected to happen, and also making it easy to copy-paste code
snippets without having to manually adjust magic numbers.
Choice of numbers: pick a simpler scheme where both msg_id and ser_no share a
common "prefix" in the 1000s range, and for a ser_no add 500 to keep distinct
numbers (that avoid confusion when reading the logs):
test prefix msg_id ser_no next-ser_no
1 1000 1001 1501 1502
2 2000 2001 2501 2502
3 3000 3001 3501 3502
...
E.g. the first test has the prefix of 1000.
msg_id: 1001, ser_no: 1101.
Change-Id: I43ba196974614d1aea2b6055be2fe82059b38974
It might be part of initialization, but what this function does is expect to
receive a CBSP RESTART, period.
Change-Id: Ieffe70cf43eb79b798d93717bbce294ee809f0e2
Recently fixed errors in the last_block counting as well as encoding ask for a
proper test coverage of various lengths, which also verifies the expected
blocks count explicitly.
Implement this in TC_cbsp_write_bss():
Run f_tc_cbsp_write_bss() multiple times with differing fixed payload lengths,
at all block count transitions, plus some arbitrary lengths in-between.
Before this patch, TC_cbsp_write_bss() would pick a different random payload
length for every test run, which, until recently, then sporadically hit
last_block value errors. That's not good for reproducability.
Change-Id: I3cace19f9e5adc8ebab13ef2328a36dc150b2b31
Subsequent patch I3cace19f9e5adc8ebab13ef2328a36dc150b2b31 adds a test with
specific payload lengths. To verify the correctness of the number-of-blocks
calculation (recently fixed), allow pinpointing the expected blocks count.
Change-Id: Ie58a6175e55ab2679dc69f9e191d0efc0e84cde0
Keep the default of using a random payload length, but also allow picking one
specifically. TC_cbsp_write_bss() will use this in a subsequent patch.
Change-Id: I259da42cbcbfdfe930aabb45c9de8a2b67c69629
Fix the length calculation to provide a range of [1..82].
f_rnd_int() generates [0..max[ (i.e., < max), so f_gen_page() so far has a
payload len range of [0..81]. We want no zero payload, and we want a maximum of
82 bytes (page max of 88 minus 6 header bytes).
Change-Id: Id521b6038a23dc8e71ea25475bcdef7bc8917531
When dividing the payload by 22, the initial 6 header octets must also be taken
into account.
And, the last_block value indicates 4 as 0, which is not encoded correctly
before this patch. Add a separate f_cbsp_block_count_enc() to fix the
calculation.
Change-Id: I06cc144bd92e94d461dac3f56a738da8e055b73a
Expecting a CBSP RESTART when connecting as CBSP client does not work, osmo-bsc
doesn't send any. Let's ignore this to get the CBSP tests running at all first.
We should clarify expected behavior and apply that, later (OS#4702).
Related: OS#4702
Change-Id: Ib93530691344c6dc4c0a8318bee2edf87e309a42
An upcoming patch adds a test series (of various payload lengths) to
TC_cbsp_write_bss(), which then needs a bit longer than 30 seconds to run
through those. That test will pass a longer guard_timeout.
Change-Id: I54e1b3994074f4d0caf5b201588fce0ec41dda89
The BSC must not only pass the ETWS Primary Notification from CBSP
down every dedicated channel, but it must also send it via an
Osmocom-specific RSL message to enable the BTS to brodcast it via
the PCH (P1 Rest Octets) and pass it to the PCU for PACCH.
Change-Id: Ia418095844aaa418a4e2ff6fd75d8a4b3c8bb9c0
Related: #4046
When the BSC receives an ETWS PN via CBSP, it must send it through all
established dedicated channels of the matching BTSs.
Related: OS#4046
Change-Id: Ib057bd251604e9bae968e71de245b3bbf737a356
In this testsuite, we simulate BTS and CBC by attaching to RSL and CBSP
protocol interfaces of the BSC. We then issue a variety of CBSP
commands to the BSC and check for corresponding action on both the BTS-
facing RSL as well as responses on the CBSP side.
Change-Id: Ia6ffac181f50586d06d2f29bca1c57285179e861
Pau Espin
Vadim Yanitskiy
Harald Welte
Neels Hofmeyr