So far we're sleeping a hole second before verifying the PDCH status of a
dynamic timeslot. That is just to ensure that osmo-bsc has read the message
from its queue and changed its status.
Change to a sleep of 0.1s, cutting a couple of seconds off the test execution.
Change-Id: Ic6cd373e18aea6eff14f2be5432705b9838e6054
When receiving the instruction to CBSP RESET, osmo-bsc should stop CBSP
broadcasting on all 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
These uncover crashes of current osmo-msc master, when a Paging Response
contains an unknown mobile identity. Hence run them last.
The crash is fixed by osmo-msc Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11
Related: OS#4724
Related: Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11 (osmo-msc)
Change-Id: I40496bbccbbd9c496cfa57df49e26f124a2b1554
We already have TC_cmserv_imsi_unknown, but lack a test that shows CM Service
Request behavior for an unknown TMSI.
Looking at OS#4721 I vaguely expected an ID Request to also happen during CM
Service Request, but instead we reject the unknown TMSI completely, and require
the MS to perform a proper LU subsequently.
Related: OS#4721
Change-Id: I54e5efcf4c31625205c99338379a2055633acde9
The test currently fails with osmo-msc master. It uncovers the evil twin aspect
of osmo-msc's VLR, for an attached IMSI re-attaching with an unknown TMSI.
Related: OS#4721
Change-Id: Ia53733fc5bc414b0e3d3897f25b549f5183c862d
As of osmo-msc Change-Id I2552736477663adb250c55728093500e8ae83ebb,
osmo-msc is always sending BSSMAP CommonID to the BSC. Let's adjust our
test expectation, while allowing the user to start the tests with
BSC_ConnectionHandler.mp_expect_common_id := false
to get the existing behavior (expect no bSSMAP CommonId) can be
restored, e.g. for testing 'latest'.
Change-Id: I4976d9bb1f07c8ab4ffa02848414f8ddd1bdfd3f
Related: OS#2969
The existing code passed -1 as TCP port number to the SMPP client.
This - very unintuitively - causes TITAN to always chose port number
9999, as that's the default value in IPL4asp. Let's use '0' instead.
Change-Id: I4db38f4099c388bed23f9a3611619866ede9cbc5
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
Keep a local next_idx so that lengthof() doesn't fail after adding a '*' entry.
Fixes this error in BSC_Tests_CBSP.TC_cbsp_write_then_kill:
Dynamic test case error: Performing lengthof() operation on a template of type @CBSP_Types.CBSP_IEs with no exact length.
Change-Id: I4d95a8ca311f145fa5ea371b6aed099db771d7b8
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
The bsc/BSC_Tests_CBSP.ttcn rely on a configuration where the first three BTS
carry out SMSCB messaging, and the fourth BTS does not. That requires a CBCH
channel config on bts 0, 1, 2.
Side effects:
- adjust the number of available SDCCH (for TC_chan_exhaustion).
- there now is a CBCH channel description in SI4, add this to
SystemInformationConfig_default.
Related: Idbcc703ace7012fb395f0eef3e445df28b368d74 (docker-playground)
Change-Id: Iac46ee2cc5bc0978d5f5baa550baf493a7c56b1b
In the ttcn3-bsc-latest tests, there are no 'msc 1' and 'msc 2' configured, so
stepping into 'msc 1' and '2' creates two new, empty MSC configurations.
osmo-bsc latest actually still tries to use them and fails 2/3 Compl L3.
So do not step into 'msc' config scopes if no such MSC is mentioned in the
running config yet.
This should finally fix the bsc latest tests after I broke them in
I02ad58ed7d0d0aac61e393b415e09c6c5c8a70ca and
Ibd5adb359b3fb302e2c70700d911878aef605ff3 and
I75295d638072df9f5213a7e74e4a960c009c2865.
Yes, I know :/
Change-Id: Ibfeeea98c2a962dec58ad03beb35bb7f83cad228
osmo-mgw recently added support for E1 trunks via libosmoabis. While the
actual E1 plane may be difficult to test, there is some functionality
that can already be tested without having E1 support in TTCN3.
Lets add three testcases:
- TC_e1_crcx_and_dlcx_ep:
Does a CRCX to an E1 endpoint followed by a DLCX
- TC_e1_crcx_with_overlap:
Not all E1 endpoint combinations are possible at the same time. This
test verifies that invalid endpoint combinations are prevented.
- TC_e1_crcx_loopback:
Opes an E1 endpoint and tests if RTP loopback works (NO E1 traffic
involved)
Change-Id: I673eeffcb3012b42f039789960c54d99282e1aad
Related: OS#2659
Invoke Clear Command with various Cause codes and verify that the RR Channel
Release reflects them.
Depends: I734cc55c501d61bbdadee81a223b26f9df57f959 (osmo-bsc)
Change-Id: Ie6c99f28b610a67f2d59ec00b3541940e882251b
Add a DCHAN and release to recently added SI2quater tests (because these tests
already configure various amounts of EARFCNs in osmo-bsc).
Verify that the RR Channel Release for CSFB contains all configured EARFCNs.
In GSM_RR_Types.ttcn, add coding for "Cell selection indicator after release of
all TCH and SDCCH IE".
In f_expect_chan_rel(), add optional arg csfb_expect_cells, and, if present,
decode the RR Channel Release message's L3 part, and in turn the Cell Selection
Indicator Value contained. Match against csfb_expect_cells.
In f_tc_si2quater_n_earfcns(), also compose a list of EARFCNs as found in the
RR Channel Release, and pass to f_expect_chan_rel().
Depends: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab (osmo-bsc)
Change-Id: I882c5e1f70bcc4833fc837a95c900ce291919cc5
Test that a CHAN RQD that indicates an emergency call is rejected if
emergency calls are disabled.
Change-Id: I9084df86e8f808e3c1d948ab88e07e7458761a71
Related: OS#4548
The testcase TC_chan_act_ack_noest_emerg tests if an emergency causes a
channel assignment. This can only work if emergency calls are allowed,
but the testcase does not make sure that this actually is the case.
Related: OS#4548
Change-Id: I0ddac0ba8ed4afe993d566dcbea87cdc62ed9fe4
During patch grooming of the previous fixup, one patch line went missing, which
breaks the ttcn3-bsc-test-latest completely. Add that change now.
Change-Id: I75295d638072df9f5213a7e74e4a960c009c2865
The EMERGENCY SETUP is an L3 message that normally gets passed through
transparently to the A interface. Nomrally the BSC will not look into L3
messages. However if EMERGENCY CALLS are allowed on a BTS or not is set
in the system information. Also osmo-bsc has the option to deny
EMERGENCY CALLS globally for all BTSs.
Since EMERGENCY CALLS are a crucial application, the BSC should not only
send the appropiate sysinfo messages that forbid emergency calling. It
should also make sure that any attempt to make an emergency call is
rejected early if emergency calls are denied.
Lets add some checks to verify that the allow/deny mechanisms for
EMERGENCY CALLS are working as expected.
Depends: osmo-bsc Ia6eb38370ce4165d221d2ffbe1cd105c0628313c
Change-Id: I486d99953529a1ce9f0a3950c9a97900922eee92
Related: OS#4548
The function f_establish_fully may be called with template ass_tpl set
to "omit". In this case we must make sure that we do not pass ass_tpl on
to isvalue().
Change-Id: Ie094e5b56a851351671327b475d5e597a5a94bf6
In f_vty_wait_for_prompt(), this:
testcase.stop(fail, "VTY: Unknown Command")
outputs:
failVTY: Unknown Command
The first stop() argument 'fail' is not actually a test verdict, but gets
rolled into a log output string, becoming "failVTY".
Fix that by simply using the normal pattern of setverdict() followed by
mtc.stop().
Change-Id: Id09986444de02c10b4fba582d454d54568b6e8a2
For the VTY "Unknown Command" code path, we must actually call 'repeat', to
avoid racey VTY behavior from cruft stuck in the VTY pipe.
The missing 'repeat' caused massive random fallout in the 'latest' builds,
which often hits the 'Unknown Command' code path; fixed by this patch.
Change-Id: Ibd5adb359b3fb302e2c70700d911878aef605ff3
TC_chan_act_ack_noest requests a channel and then releases it again.
However, this does not test yet what happens if the requestor (BTS) uses
a request reference that indicates an emergancy call. Depending on the
configuration the BSC should reject or allow the channel to be
established.
Change-Id: If828c0f5786d89efa7608f38d648e2a2b8f6f675
Related: OS#4549
Neels Hofmeyr
Harald Welte
Daniel Willmann
Philipp Maier