To trigger the segfault described in OS#2947, run TC_lu_imsi_auth_tmsi_encr_3_1
with logging category for MSC to set to debug.
Change-Id: I72a1dbb30e0a39dbf4b81c7e378d5607b62e10d3
This is a variation on TC_lu_imsi_auth_tmsi_encr_3_1 that "indicates" inability
of A5/3 by completely omitting a Classmark2.
Add flag send_cm_update to f_tc_lu_imsi_auth_tmsi_encr_3_1() so that we can
easily omit the classmark update. Set this flag to true in existing
TC_lu_imsi_auth_tmsi_encr_3_1, and add pass false from the new test.
Change-Id: I903136d5acbd88f2e0e26fee22e3878258e04786
Previously, f_start_handler() would initialize the BSC_ConnHdlrPars instance,
making it impossible to change those parameters before the test function was
invoked.
Add separate f_init_pars() function that sets the default parameters.
Change f_start_handler() to take a BSC_ConnHdlrPars argument; i.e. that
f_init_pars() can be called first, the parameters can then be modified and
finally fed into f_start_handler().
Change-Id: I46de36a032c2473025d0eb01e5909dbcdaf394f7
By moving to the BSC_ConnHdlrPars, also the tests that expect a LU failure able
to indicate a send_cm_update flag.
All current callers of f_perform_lu() pass send_early_cm as 'true', all are
covered by a default of 'true'.
Change-Id: Ic882293f199a33133a171bff14ff433f99cc8576
We permit other subscriber data that's not the MSISDN, but we require
the MSISDN be somewhere within the IEs of the ISD_REQ
Change-Id: Ic63cd5c9a5e9ed46c70f7d7869b4ece281b97e44
This tests whether the HLR is sending an InsertSubscriberData to the VLR
of an active/registered subscriber after the MSISDN is updated in the
HLR.
Change-Id: I597a3c2d49aa6fa65007304105363a3e99fa4ae9
Related: OS#2785
The altstep as_handover does not exit as each of its branches is
equipped with a repeat statement on the end. This trapps us in
an endless loop.
- remove the repeat statement at the last logical step which is
at the RSL_REL_REQ.
Change-Id: I8cb57a9fef606f459542708206f5ea4de1def7a1
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
The existing BTS testing code was based on a ~1 week old version
of trxcon+fake_trx from osmocom-bb.git fixeria/trx branch, which
has meanwhile evolved:
* port number change for TRX protocol
* FAKE_TIMING -> FAKE_TOA
* we can now expect responses to our UDP control commands
Let's adapt the testsuite to those changes
Change-Id: I6d0122202e5d23308421e76b75e608d206aab56e
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
this adds a new test that uses VTY to enable TOA256 support in
the uplink supplementary measurement and then tests TCH/H measurement
reports
Change-Id: Id39a71429596d46289a82e539796308816ad86f3
as fake_trx keeps running during the entire test suite run, and
the protocol being UDP based, it doesn't know when BTS_Test will
re-start and hence the old TA/FAKE_TIMING value will remain until
it is set.
Let's explicitly set a FAKE_TIMING of two bits at start-up of each
test case during f_init()
Change-Id: I9f07768346e0d68a4dbe36780e36b799d27a7f06
TITAN will print warnings if a still-running timer is res-started.
It will also warn if a not-started timer is stopped, so we need
a conditional stop + start if we want to avoid any warnings in a
convenient way.
Change-Id: Iee83b4905cce3a84eb007ffd189b55f4b54f7cb6
As L1CTL is using a stream socket, we need to give the UNIX_DOMAIN
port some clue as to where our L1CTL message boundaries are in the
stream.
This requires a patched UNIX_DOMAIN_SOCKETasp test port with the
following commit applied:
commit 655cb4ab2ac006b3a73d1b679c83081d9743410a
Author: Harald Welte <laforge@gnumonks.org>
Date: Sun Feb 25 23:25:46 2018 +0100
Add "getMsgLen" function similar to IPL4asp_PT
Change-Id: Iab33f57cb4311180e521a76307a552d16287b062
This imports those tests from ../sysinfo/Tests.ttcn which deal with
the scheduling of SI, not with the actual payload/correctness of their
contents. (the latter tests must move to the BSC test suite, as the BTS
is only concerned with scheduling the opaque SI blocks as received from
the BSC).
Change-Id: I65f4b91e81174717a0c484ba5c22bede68683ae1
The way how TTCN-3 templates work it's not possible for us to have
a parametric template for both generating DLCX with conn_id and without :(
Change-Id: Icb772ca5b9661ab39b1c161fa4ebc70544275d8f
The way how TTCN-3 templates work we cannot use a template parameter
to decide if we want to match only on messages that contain a matching
RTP_PT2, or (alternatively) on any messages whether or not they have
a RTP_PT2 IE at all :(
Change-Id: I7a4f5d7e1d44994316717da5b769e278ea188b12
We're testing at 80% and 200% of PCH capacity, both for either IMSI-only
or TMSI-only paging requests. The way how we test ensures:
* the expected number of paged mobile identities end up on the Um interface
* we implicitly check the queuing limit of 200 paging records by
overflowing it in the 20-seconds-of-200%-load cases
* we implicitly check the batching of mobile identities into different
paging types
* we test the PCH load reporting over RSL
As a side note, in case you were ever wondering what's the expected
paging throughput / capacity, there are now helper functions to compute
it. For our combined CCCH/SDCCH4, it's about 16 IMSIs per second or
about 32 TMSIs per second.
Change-Id: I0b80b72bdab3d80d915296d70e1174623fbd8610
The BTS needs some of the SI3 parameters like BS_AG_BLKS_RES for
internal computations, so make sure we send it after the connection
has been established.
Change-Id: I5dc3724f79e669f52593cd776806d84b4dd4bf5c