For the sole reason that f_vty_sms_send() was put on MTC_CT for no apparent
reason, we start the test function and send an SMS with an arbitrary two
seconds delay.
Instead move it to BSC_ConnHdlr and place SMS sending in the actual test
function flow where it belongs.
Change-Id: I5f348b3d30342b7c4871a1fc8f94648923e82eea
When aborting a call with a Clear Request, it is actually a good idea to
release an ongoing call with a CC Release message from the MSC. Allow this.
Change-Id: I8378f7602fecac8262b31b47ad9327a3782c1bcd
Also log the testcase name in tcpdump-start.sh.
The output now looks like
------ MSC_Tests.TC_mo_cc_bssmap_clear ------
Thu Mar 7 13:21:00 UTC 2019
[...]
Thu Mar 7 13:21:04 UTC 2019
====== MSC_Tests.TC_mo_cc_bssmap_clear pass ======
The reason to log start and end dates came up like this: I noticed a segfault
in a tested program at a specific time. From the timestamp I tried to find out
which of the tests saw the failure. (After a segfault, all subsequent tests run
and fail, but it is not obvious which failure occured because of a segfault,
and which ones just normally failed before that.) Looking at the timestamps of
the log files didn't help, because the ttcn3_logmerge touched those after the
tests completed. So the only way is to cat each individual log file and find
the timestamp.
So this adds an overview of the timestamps without needing to open log files.
Change-Id: I0832d9b5df599baad5dec8d3a993481b4286fbb3
Implement necessary messages for Procedure Check_IMEI_VLR (TS 23.018
Chapter 7.1.2.9). This lets the VLR ask the EIR to check if an IMEI
is valid. In the Osmocom stack, we don't have an EIR and this request
is handled by the HLR. We are able to store the IMEI in the HLR as
side-effect (OS#2541).
This is roughly based on TS 29.002 8.7.1 MAP_CHECK_IMEI service, but
only implements the bare minimum required IEs (imei and imei_result).
Related: OS#3733
Change-Id: Ie1ae5c66ad3f9b42b345020de62a0c276cd8d709
Let's split the PCUIF-side component from the NS-side component
and create a new RAW_Test_CT which derives from both.
Change-Id: I15021c5dea16e39a530d8d9080e37a7f2a6c4fa7
The SNS-enabled Gb interface has no RESET/BLOCK/UNBLOCK procedures,
but introduces a bunch of new SNS procedures. Most importantly the
SNS-SIZE and SNS-CONFIG procedures.
Change-Id: I0fe3d4579960bab0494c294ec7ab8032feed4fb2
Related: OS#3372
The MGW recentenly adds support to convert between ts101318 and rfc5993
when GSM-HR is used. Lets add a testcase for that.
depends: osmo-mgw Iceef19e5619f8c92dfa7c8cdecb2e9b15f0a11a1
Change-Id: I96df45fe45b53088e07b26f14173a75498a84143
Related: OS#3807
The configuration of the RTP Emulation (RtpemConfig) allows to set a
fixed RTP payload that is then used when RTP packets are transmitted.
However, when packets are received, then the payload is not checked.
Lets check the received data against some user configurable rx payload,
that is by default set to the tx payload.
Change-Id: Id0b125aaf915497d0a4f051af890fc34e09da61d
Related: OS#3807
Previously the first timeout in TC_rach_content() caused test to
fail. Related TC_rach_count() test shows that there're some (13-16 out
of 1000) RA values which are problematic. Let's log all such values in
TC_rach_content() before failing the test to, hopefully, spot the
pattern which sets such RA values apart.
Change-Id: Ibfeb377101f406608c0193f08729c0e6d084281e
Related: OS#1854
When a CSFB voice call is cleared by the MSC, it must include the
CSFB INDICATOR in order to trigger the BSC to perform actions
required for Fast Return to LTE.
This patch changes TC_sgsap_lu_and_mt_call() and
TC_bssap_lu_sgsap_lu_and_mt_call() to ensure the CSFB INDICATOR IE
is present as expected.
Change-Id: I6ce3a34f85aca7143cf7925cb9319bc679e8d395
If we have tests stated in the .default file and we have them stated
again in the .cfg file, they will be executed twice. Let's align
the PCU tests suite with those of other network elements.
Change-Id: Ieeaf70153f4dc61978569d06e20947fa939cabdd
Test BTS_Tests.TC_dyn_osmo_pdch_act_deact was sporadically failing due
to receiving IND_INFO on the PCU port with pdch_mask related TS bit set
to 0 after sending a PDCH ACT. That happened due to a race condition
because PCU send IND_INFO periodically. As a result, it can happen that
BTS sends an IND_INFO after PCU.clear was called and before the PDCH ACT
is handled.
Change-Id: If11ef05d97aa5f6caaa731f3817c1fecfc3edf7c
The existing (unused) PCU_Tests are operating on top of a NS + BSSGP
emulation, i.e. they're aimed at testing higher protocol layers. Also,
they required BTS+BSC to run next to the PCU.
The new PCU_Tests_RAW introduced in this patch are the exact opposite:
* they test the PCU alone (attach to PCUIF and Gb interface)
* they don't require BTS or BSC to run
* they don't use NS + BSSGP emulation but raw NS/BSSGP frames to
test the very NS/BSSGP implementation inside of OsmoPCU.
Change-Id: I7ad76b96974cf0a686ad0f00ccd09d1a9df8b4d5
Related: OS#2890
The MGCP_Test testsuite currenty lacks VTY access capabilities, lets
add them so that future testcases can access the VTY in order to change
options on the fly.
Depends: osmo-ttcn3-hacks Ife949c61156222de3026280071226ef6f5dbd959
Change-Id: If383f81af3306f8f5bdf50152498ae1303d390df
Related: OS#3807
In TTCN-3, a 4-byte octetstring is the more usual representation for
IP addresses, not an integer type. This is also what functions like
f_inet_addr() etc. are using as types, and we may want to use them
in combination with the PCUIF.
Change-Id: Ia08e1bb8a9bfbd5bf5b63922c77bb221ce1a12f5
Our TTCN-3 PCUIF code so far was only used to simulate the PCU side
of the interface: connecting to the socket as a client. However,
it's also useful to emulate the BTS side of the interface: Listening
for a connection as a server.
Also, the send/receive templates are prepared for the inverse role.
Change-Id: I779ff2903cab8c13ffb8fe10a4cacd996bafe69a
Newer eclipse-titan makefilegen already sets CPPFLAGS like this:
CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include$(TTCN3_SUBDIR)
where TTCN3_SUBDIR expands to '/titan' and TTCN3_DIR to '/usr'
If we add /titan after include we end up with
-I/usr/include/titan/titan/ which will cause the compile to fail due to
a missing TTCN3.hh include.
Check the titan version so we retain backwards compatibility.
Change-Id: If9fef29ce243be112d3735f0236335197f8f140f
Related: OS#3179
Sponsored-by: On-Waves ehf.
At the moment the SGs interface is started and connected in all tests in
the testsuite. This may be a problem because the IUT may lack the SGs
support. In this case all tests would fail because of the missing SGs
interface.
Lets initalize and connect the SGs interface only for SGs related tests
to prevent unrelated test failures.
Change-Id: I8e012e3599ad00db2e132b6463499f8a4a2307f1
Related: OS#3614
The testcase TC_gsup_mt_multi_part_sms is known to fail osmo-msc in a
way that meaninful sms delivery is not possible anymore. This is due to
a bug in osmo-msc, but in the testsuit it makes running certain normally
working testcases impossible. Lets move at at the end of the testsuite
so that it rus late and other tests won't get blocked.
Change-Id: I581cd80895ea992a15389c6f73816769864e6d4c
Related: OS#3614
The IMSIs used with the SGs tests are partially re-used in other SGs
testcases and also in unrelated testcases. Lets give each SGs test a
unique IMSI to prevent unrelated interference with other tests.
Change-Id: I417d9c5f0fbab7483d1b31dc20a99f63ee1bbfe6
Related: OS#3614
When a MSC releases a connection using the BSSMAP CLEAR CMD, it can
specify that this call was part of CSFB.
The BSC is then supposed to add a special IE to the RR RELEASE
message which will help the phone to switch back to LTE as soon
as possible.
This commit adds a new test case testing for exactly that behavior.
The test does *not* verify if the EARFCN information contained is
actually correct, only that the IE is present in the RR RELEASE.
Change-Id: I7501fb25578412c882ff92da5d388f3079bbce7f
Requires: osmo-bsc Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Related: OS#3777
The 'decmatch' keyword allows us to match the decoded version of some
octetstring, which is very useful in the situations where we have
the L3 message only as octetstring but want to check if it matches
some L3 template.
Change-Id: I0a91e067f7e8062bf991fef8b0d4d8da740bfafc
The RR RELEASE message does not always have to be '060D00'O,
which constrains it to:
* not having any optional IEs
* not having a cause value != 00
Let's relax the matching to accept any RR RELEASE message, whatever
the cause may be, and whether or not there are any optional IEs at the
end.
At the same time, also remove some copy+pasting but rather have one
template that gets used everywhere.
Change-Id: I4b9d078c9b66f040fe673b5d957cf8e2c6d5892c
The idea of this test case is to verify SM-RP-MR assignment for
a few concurrent MO/MT SMS being sent over GSUP.
Basically, the algorythm is the following:
1.0 establish a RAN connection,
1.1 send CM Service Request for MO SMMA indication,
1.2 submit MO SMMA indication on DTAP,
1.3 expect MO-ForwardSM-Req on GSUP,
2.0 send MT SMS using MT-ForwardSM-Req on GSUP,
2.1 expect CP-DATA/RP-DATA for MT SMS on DTAP,
3.0 compare both SM-RP-MR values (for MT, assigned by the MSC),
3.1 send MO-ForwardSM-Res for MO SMMA on GSUP,
3.1.1 expect CP-DATA/RP-ACK for MO SMMA on DTAP,
3.2 send CP-DATA/RP-ACK for MT SMS on DTAP,
3.2.1 expect MT-ForwardSM-Res for MT SMS on GSUP.
Change-Id: I17cbbaa64d9bce770f985588e93cd3eecd732120
The idea of this test case is to verify SM-RP-MR assignment for
a few MT SMS being sent over GSUP. Basically, the algorythm is
the following:
1.0 send the 1st SMS using MT-ForwardSM-Req on GSUP,
1.1 expect Paging Request on RAN,
1.2 establish a RAN connection,
1.3 expect CP-DATA/RP-DATA for the 1st SMS,
2.0 send the 2nd SMS using MT-ForwardSM-Req on GSUP,
2.1 expect CP-DATA/RP-DATA for the 2nd SMS,
3.0 compare both SM-RP-MR values assigned by the MSC,
3.1 send CP-DATA/RP-ACK for both 1st and 2nd SMS messages,
3.2 expect MT-ForwardSM-Res for both 1st and 2nd SMS messages.
The SM-RP-MR values for both 1st and 2nd messages shall not match.
Change-Id: I3a52d44f4abde9b6b471b9108c1cee905884c9bc
The tests presented in Change I109d986dd7ece1a56422a669ca64353ed46f7ed6,
are using a slightly outdated vty syntax and fail because of that. Lets
update the VTY syntax.
Change-Id: I302e8872dbdc8e65d51902a881f777863de22915
Related: OS#3503
When a channel is assigned via the assignment request throught the A
interface, the MSC may offer either FR, HR or both. When FR and HR are
permitted, a preference is set on one of the two.
At the moment we do not check how the bsc is reacting to those
preferences and its also not checked how the behavior is when the
preferred rate is not available because all lchan of that type are
already in use. Lets add a set of tests to verify this.
Change-Id: I109d986dd7ece1a56422a669ca64353ed46f7ed6
Depends: osmo-bsc I397e68e26d6a1727890353fa34f4897b54795866
Related: OS#3503
Oliver Smith
Neels Hofmeyr
Harald Welte
Philipp Maier
Pau Espin
Daniel Willmann