The problem is that Junit-XML doesn't have a mapping for inconclusive
results, and hence they show up as 'passed'.
By introducing this change, we make sure all tests that don't pass
show up as failed.
Change-Id: Iddd13d0055c91f9bd304ce9833fba0485abf4c4e
Verify that the BSC does not page a subscriber when a cell identifier
with an unknown MCC/MNC is provided by the MSC.
This test introduces a magic value which represents an unknown MCC/MNC
combination: MCC=678 MNC=f90
Change-Id: I0b0af14a9a1cb7e5a7a4ec12cc489473fd7ead02
Related: OS#2980
After all, we don't want stale queue entries especially in those where we
are not expecting any paging.
Change-Id: Id876b68087ef13d58177027b7e664404e6b7b2d9
The TTCN-3 data types are abstract data types, Encoding artefacts
like 'F' for padding shouldn't be seen by the user. Hence, let's
pass a 2-digit-long or 3-digit-long hexstring into the encoder
functions and let them determine if they should introduce any 'F'
for padding or not.
Change-Id: If4d3dfc16381493d7e710be746ed963975051fc1
If 5 seconds expire, the BSC will automatically re-fill a credit
of 20 paging slots [to work with BTSs where the paging buffer space
indications somehow are missing]. Let's make sure we don't hit
that case, even if the operating system sleeps for more than 5s
in this test .
Change-Id: I1c65096a685b70dc5183592382ec03553ba3628f
We are testing purely IPA/RSL/OML, and half-starting the BSSAP/M3UA
emulation is not a good idea, if it generatees events that we don't
catch
Change-Id: Ie90cd88e63ba6062e4ea2592045e9c97bc11887e
The cell identifier used by the paging tests is 001-01, i.e. uses a
2-digit MNC. With the introduction of 3-digit MNC support in osmo-bsc,
the paging tests became incompatible with a osmo-bsc config with:
network country code 1
mobile network code 1
Explicitly declare a Cell_Identity with 2-digit MNC (includes an 'f').
Also, fix f_enc_mcc_mnc to properly encode 2-digit MNC values.
Related: OS#2847
Change-Id: Ide5228b403e43de8649b6eda18749ea2a9f592a9
bsc: add TC_bssmap_clear_does_not_cause_bssmap_reset(), but the same triggered
by an MS Rel Ind and a BSSMAP Clear Request sent to the MSC first.
This test will only succeed once TC_chan_rel_rll_rel_ind() succeeds, i.e. with
below osmo-bsc fix.
Related: OS#3041
Depends: I0f8c9c4e6b6850b15c70250fd3f88bdf75f9accf (osmo-bsc)
Change-Id: Ie4aa2f01c83b40303fa40ed64dbfce372b7cd96c
This test sends a REL IND from the MS and immediately expects an lchan release.
Instead, osmo-bsc patch I0f8c9c4e6b6850b15c70250fd3f88bdf75f9accf decides to
signal full BSSMAP Clear Request to the MSC first, so expect that first.
Note that this test currently fails, and said osmo-bsc.git patch will make this
test pass.
Change-Id: I737be141b69a250eb6eb38007f8042981c1a31cf
Same as TC_bssmap_rlsd_does_not_cause_bssmap_reset(), but with a proper BSSMAP
Clear from the MSC first.
Related: OS#3041
Change-Id: If6ca85d7b80a727cbfdabbf07529ced22602734e
A test with BSSMAP Clear involved would also be a nice addition, but this so
far tests a direct RLSD from the MSC.
(One way to invoke a typical release situation would be a scenario like in
TC_chan_rel_rll_rel_ind(), but that test currently fails; another would be to
directly invoke a BSSMAP Clear from the MSC first.)
Related: OS#3041
Change-Id: I168cf240383485a5ffbbde377b4f89c5d1f5ab93
If the T_guard runs out, unless we self.stop, we might run into this
potentially confusing follow-up error:
00:23:04.206712 mtc BSC_Tests.ttcn:322 Dynamic test case error: Copying an unbound value of type @RSL_Types.RSL_Message.
00:23:04.206778 mtc BSC_Tests.ttcn:322 setverdict(error): fail -> error
Change-Id: I1d373159483bdd9f74e8944e430913e73c289e03
Currently we use isbound() in f_start_handler() to check if the BTS
which we want to connect is indeed populated. However. isbound()
seems never become true in this particular situation.
- Use isvalue() instead of isbound()
Change-Id: I25ddd55b7626087570311999b85ec7632b162c06
When the test component ends and the underlaying
components are shut down. Messages from the system
under test may still be picked up and forwared. When
a message is handed from one component to one that
is already shut down, the testcase is flagged as
errornous setverdict(error).
An idea to fix thisis to stop all test ports using
all port.stop. However, this does not solve the
problem entirely. We still observing errors.
- add f_shutdown_helper() and call it from the
end of each testcase
- perform an all port.stop; in f_shutdown_helper()
to freeze all communications between the ports
of the different components.
Change-Id: Id3bc840c0428d08dfbeedacc408b3dd1cd0fa7ec
The testcase TC_paging_imsi_a_reset sends a paging request that
causes pagings on all cells. Then it performs a BSSMAP reset and
checks if the paging has stopped. In order to be sure that paging
requests from before the reset procedure are not mistakenly
detected as after-reset-pagings the RSL queue is cleared. However
this is only done for IPA_RSL[0], which means IPA_RSL[1] and
IPA_RSL[2] still contain old paging requests, which lets the test
fail.
- Clear IPA_RSL[1] and IPA_RSL[2] as well.
Change-Id: If0cdc0325fd0e1dcf3e4ce52e4de27adb4d9cf48
RSL_Emulation has recently gained a port for the common channel
management messages, but BSC_Tests was not updated with this port,
resulting in RSL_Emulation enqueuing messages to the port which then
creates dynamic test case failures.
Let's simply connect to the port, even though we currently are not
interested in any of the messages received there (mainly
RSL_MT_BCCH_INFO during startup).
Change-Id: Id8a3c4409599783ca4cd0b49f2570bcb3bb34952
The testcase TC_paging_imsi_nochan assumes that a paging for no
channel, with no specifc cell associated and without TMSI is
illegal. This is not correct. All these fields have legal values
and the TMSI field is optional.
- Replace the testcase implementation, use f_pageing_helper() to
create the paging.
Change-Id: I6a56fb0ee06ae7e72a7ac2b6b058ad54f94127ab
This adds two new tests: One for RSL, and a second one which performs
the same test on the OML port. Both tests open an IPA connection and
send a unit ID which is unknown to the BSC. The tests expect the BSC
to close the connection immediately.
We need to add handling for a socket error in IPA_Emulation because
otherwise these tests do not pass reliably as some closed connections
are not properly detected.
Change-Id: I6a947d7411a016e4d7650031396cae3575756453
The testcase TC_paging_counter is missing in the control section.
This means that if it is not started explicitly, it is not executed.
- Add TC_paging_counter to control section
Change-Id: Ie37b8cb554ea1db64a8d7927eb300d368ce67137
When f_expect_chan_rel() is called after receiving the BSSMAP
RESET and DISC.ind f_expect_chan_rel() is called. The flush
parameter is not set, which means the default flush = true is
valid. This leads into an early flush of the RSL Queue and
tosses the RSL RELEASE REQUEST we expect, so the test can not
pass, even when the BSC sends the RLEASE REQUEST.
Looking further up in the code. IPA_RSL[0].clear is called,
so the Queue is flushed to get rid of unwanted messages from
the IMMEDIATE ASSIGN. There is no need to flush the queue
a second time anyway.
- Do not flush the RSL queue, set flush=false when calling
f_expect_chan_rel()
Change-Id: I2962f741e0b13dec08ac6c918d326828beb65a6a
When we page an unknown/unsupported CellIdentifier format, OsmoBSC
decides to page on all BTSs to be safe. This way we have a chance of
making communication happen, rather than breaking it.
Change-Id: Ibd0ba986d9e18758b519e852c36f4dbbb6b367ea
We now test all of the cell identification types specified in BSSMAP,
and also lists with a length != 1 entry.
Change-Id: I261f948d6054d0c90078c1dd0b2785a967b0a49b
We have to wait for sime time until some RSL paging command would have
arrived, rather than continuing too quickly.
Change-Id: I63827aa3c42f77648ecad401b3cc4bae927b3b94
During assignment or hand-over, a given TTCN-3 component may be
interested in registering more than one channel number. Add an explicit
procedure port with associated registration procedure, similar to what
we already do in GSUP, MNCC and others.
Change-Id: Iba37bf9541c779b79e179f995cdfa677633fadeb
The point of this test is to verify that *no* paging messages are sent
if "No cell" is given as cell identifier list by the MSC. We can thus
not use the existing pageing_helper function, but have to handle this
a bit differently.
This makes TC_paging_imsi_nochan runs pass.
Change-Id: Iec1086bd42f42de1986bb00b91af718977f73b30
This test case was incomplete in that it didn't account for a RLL REL
REQ/RESP before RF_CHAN_REL.
Together with OsmoBSC Change-Id
I64a46b5bcd4272e3fa2ff4ee824c2f3fdff6854b, this test now passes.
Change-Id: Ia5af254d4fc572c1d324f70b5ec99d87bdaf9eb9
This test case was incomplete in that it
* applied the wrong timeout T3101 instead of T3210
* didn't account for a RLL REL REQ/RESP before RF_CHAN_REL
Let's fix it. Together with OsmoBSC Change-Id
Ie11d7d06353ba1b1e2fab6763dd7b032ce8a5d2c this check now actually
passes for the first time.
Change-Id: I9ed41d246cf153735fd4e71cc6cc174ede32a76b
In OsmoBSC Change-IdI68286d26e2014048b054f39ef29c35fef420cc97 we
introduce a proper subscriber connection state machine which fixes
the order of events during channel release after connection failure.
Change-Id: Ibe9c3205ec11dafcc305ea72aeb33e9152a6458c
When Change-Id I10fc9f60c58c6b7ed424a86ce23bf6b9802c9eb1 was merged,
OsmoBSC started to always allocate SDCCH first, no matter what the
establishment cause. This basically means we don't do very early
assignment anymore. TC_exhaustion must be adapted to allocate all
SDCCH and all TCH before failing.
Change-Id: I9d8bbfca0deebc738385f2a1a20d4a17c3853082
We create a new Osmocom_CTRL_Adapter module which can be used by
test suites using the 'extends' functionality.
Change-Id: I3ef6cfaa738900e008155013a05b8ccf3d4b7aeb
This new test exercises the new 'msc.0.connection_status' control
command which is added in https://gerrit.osmocom.org/#/c/5630/
Change-Id: I55faa1ec413629234e24831dbc05d8b0afec8099
Related: OS#2729
Don't expect the ASSIGNMENT to fail in case of unsupported A5/4,
but expect a CIPHERING MODE REJECT.
Change-Id: I15024f61e67795b7e5ce72e1b641db6ca92ff76d