This hopefully prevents the verdict from changing to a dynamic test case
error during an unclean termination
Change-Id: I20e156982ae8150a9e7a145f66283de4a5d8e0bd
mtc.stop cleanly shuts down a testcase. This avoids errors influencing
the result after the test completed (such as ports being shutdown with
messages arriving on them causing a dynamic test case error).
Change-Id: I0f6e10006f46db0d68796c7082497af90f74cd07
The current osmo-bsc refactoring causes an erratic MR Config IE. This patch
ensures that the ttcn3-bsc-tests catch this error.
Add MR Config IE expectations to g_pars, set these in the two tests that expect
an MR Config IE in the Chan Activ message:
BSC_Tests.TC_assignment_codec_amr_{f,h}
All other tests now verify that there is *no* MR Config IE in RSL Chan Activ
messages -- all other tests request no voice or a non-AMR codec for Chan Activ.
Change-Id: Ie841feed9d5e478bab1fea2bb86f300e84799013
In osmo-bts Change-Id Iea4a4781481f77c6163d82dcd71a844a5be87bf2
we introduce an Osmocom specific "supplementary measurement info IE"
into the RSL MEAS REP message. This commit adds the related type
definitions and extends the related matching in BTS_Tests.ttcn.
Change-Id: I5d1114c73508c67ad7cd9864d7370367612b1241
The RTP stream tests TC_two_crcx_and_unsolicited_rtp and
TC_two_crcx_and_one_mdcx_rtp_ho, which were introduced recently
with Change-Id I556a6efff0e74aab897bd8165200eec36e46629f, use
hardcoded ip addresses (127.0.0.1) to establish the RTP streams
that are used to test how the MGW reacts on unsolicited packets.
This works fine when everything runs on local host but on docker
it failes since the containers there have different ip-addresses.
- replace hardcoded IP-Addresses with modulepar variable in
TC_two_crcx_and_unsolicited_rtp and TC_two_crcx_and_one_mdcx_rtp_ho
Change-Id: I5af5186f173c2b8564e8034249c82245acdd09f6
Related: OS#2703
The test coverage of the RTP aspects of the MGW is currently very
minima. Lets add a few more testcase to verify RTP behaves as
expected in various situations.
- Add testcase TC_one_crcx_receive_only_rtp:
Test recvonly mode of the MGW. All packets must be absorbed by
the MGW, no packets must come back.
- Add testcase TC_one_crcx_loopback_rtp:
Test loopback mode of the MGW. All packet sent to the MGW must
come back.
- Add testcase TC_two_crcx_and_rtp_bidir:
We already test unidirectional transmissions. This test does
the same as TC_two_crcx_and_rtp but for both directions.
- Add testcase TC_two_crcx_mdcx_and_rtp:
Simulate a typical behaviour of a normal call. First create
two half open connections and complete the connections later
using MDCX.
- Add testcase TC_two_crcx_and_unsolicited_rtp:
Test what happens when a RTP packets from rogue source are mixed
into the RTP stream.
- Add testcase TC_two_crcx_and_one_mdcx_rtp_ho:
Test a typical handover situation. An existing connection is
handovered to another source on one end but the old source will
keep transmitting for a while.
Change-Id: I556a6efff0e74aab897bd8165200eec36e46629f
Closes: OS#2703
When leaving TS 6 in Osmocom style dyn TS mode, the initialization of the BTS
will cause a RSL Chan Activ, which the tests BSC_Tests.TC_early_conn_fail and
BSC_Tests.TC_late_conn_fail will interpret as the channel activation that they
expect to come from the Channel Request. They will hence issue the Conn Fail
message before the lchan is established, and are getting confused on what they
expect to happen.
Change-Id: I2bde987eefe7129c9f7c3b81b624d55cb66a75d0
The test currently use a hardcoded payload type and encoding name.
This does mean in practice that even when an assignment with EFR
is happeining. The MGCP responses to the BSC tell that the codec
is AMR. This is not correct. The testcases should always pick a
suitable payload type / encoding name in the MGCP response
- Add constants for IANA/3GPP assigned payload types
- Add function to lookup the right encoding name for a payload type
- Initalize the encoding name and payload type in g_media according
to the BSSAP PDU.
Change-Id: I2735267091059e2f2169da80bdcd30abc2b1554b
Realted: OS#2728
Overlong IMSIs used to trigger an assertion failure in osmo-msc.
This problem has been fixed but there was no test for it yet.
A lazy way of testing for this problem is to send an overlong IMSI
from an existing test which already verifies related behaviour
and would fail if the MSC crashed: TC_lu_by_tmsi_noauth_unknown
However, osmo-msc currently accepts overlong IMSIs and silently
truncates them, so this change as-is currently breaks this test.
But I would argue that osmo-msc's current behaviour is unreasonable
anyway and have proposed a patch to change it:
https://gerrit.osmocom.org/#/c/osmo-msc/+/9739/
With that patch applied to osmo-msc, this test keeps passing.
Change-Id: I2c472bee76086f6c84ec684d2e58b3351ebc3147
Depends: I785c994f41a646d8d83d3d82f5a9ae6b572eb641
Related: OS#2864
Related: g#9739
The previous default behaviour was to always run 'make -j8', which
can cause C++ build failures on machines which are low on memory.
"Low" being a relative measure; I've seen failures with 4GB of RAM.
Rather than assuming a beefy 8-core box, try to detect the number
of available CPU cores with nproc(1) from GNU coreutils and set
the number of parallel make jobs to the number of CPU cores.
If this command is not available, default to a safe choice: -j1
Note that installing ccache will speed up repeated builds a lot
more than -jX ever will, so falling back to -j1 isn't very bad.
Change-Id: I61c3ea1b3cb5b64eecb08ad6c390594f70cdf785
The testcase ts_CRCX_no_lco looks at the media attributes to see
if it findes the expected default codec there. In this testcase
we expect PCMU/8000/1 as media attribute, but this is a codec from
the fixed payload type domain. The MGW may not list this info inside
the media attributes. Listing the payload type number in the media
description is sufficient. We should check this instead.
- Remove media attribute check
- Check meida description for PCMU (0)
Change-Id: I69600a1025e68011e8fc5d8bf22d842d9c63bf53
Related: OS#2658
As we are about to finish the implementation of GSM TS 09.11, in
our case it is 'SS/USSD over GSUP', OsmoMSC will not decide itself
which USSD request-code is known, and which is wrong.
Change-Id: Ic104a49bb2dce2127063bcef8443ee6b639c9f19
The 'SS Info' IE is optional for GSUP_PROC_SS_{REQ|RSP} messages,
and is not carried in some cases, e.g. when a subscriber aborts
an active transaction by pressing the 'red button'.
Change-Id: I20d9028acbe0c457d2a2cf72eff372b749d8dc30
According to GSM TS 04.80, table 2.5, the Facility IE is optional
for RELEASE COMPLETE message. So, if this IE is omitted, then the
whole TVL shall be omitted. It's time to fix this.
Change-Id: I216195ef71c95997708dad8c31b172b6f6cdc461
According to GSM TS 04.80, table 3.4, the Return Result component
may be empty, i.e. may not contain any results nor operation code.
It is used, for example, in responce to the network-originated
USSD notification.
Change-Id: Iaaff110c5f61cc87eda6143cd841f9832f6074bf
Until now, the test went from RR Handover Command directly to RR Handover
Complete, and osmo-bsc didn't mind it. However, the normal handover procedure
requires an RSL Handover Detect to be sent in-between those. Send that.
Change-Id: I6e54edcc3a99e116d852eca8e48c7a5bc685e832
The intention is to ignore RLL REL requests, and not to actually block the alt
statement in f_expect_chan_rel() if any RLL REL messages show up.
Change-Id: I3bbcdc41d186a3464cd4adb5c5b770bdec056993
Going via GSUP_Emulation (rather than using GSUP_CodecPort directly)
adds many benefits, such as:
* ability to have multiple transactions in parallel
* no silent discard/ignore of unexpected GSUP messages, like those
for IMSIs we don't expect.
Change-Id: Id2ddd6b81c374ad6350b62fcc5442436757d66cd
Those test cases simulate a BTS-originated RLL CONN FAIL IND at
"unusual" time:
a) before we actually establish any RLL
b) after / while we're tearing down the RLL
This is triggering an osmo-bsc segfault, see OS#3182.
Change-Id: I324c410d7565c189dbc91df577d92b87c036732c
Related: OS#3182
There's a sequence of commands which was repeated over at least
four test cases. Let's factor this out into the new
f_exp_chan_rel_and_clear() function, and use that function from
all the former copy+pasted sections.
Change-Id: Ic6791fce4e8787e38b818a12ed526d3e47f313ef
Previous the old entries aren't removed. This only had an
impact if two different f_TC_* were using the same imsi.
When the second function tried to remove the Client again from
the ClientList, the BSSGP_Emulation failed.
Change-Id: I71103e8f8c5f18e8ebadc057cd62d85affd7ca8c
MS <-> SGSN: Attach
MS -> SGSN: Detach Req (Power off)
VTY -> SGSN: Check if MS is NOT in subscriber cache
Change-Id: I0956d54760f19ca556fa0d16ea4c5b96ac13f2fa
PARALLEL | VERDICTOP will log when the port is dying or when other
components will change to fail. This helped to find a timeout in the
SGSN tests where a function call message timed out.
Change-Id: I770ac964dc37e2752e7d35e493f707b091c739b0
as of Change-Id Change-Id: I4f51abdf44dfc62d7e8792341aad6dafe58923da,
osmo-hlr passes HLR_Tests.TC_gsup_sai_err_invalid_imsi
Change-Id: I72fb71806c72ce29e8c6c9b25723f02009463cec
In this test case, the MSC performs a hard SCCP release of the
SCCP connection. This makes the BSC send a RLL REL REQ on the lchan,
but we simulate a broken/lost MS which doesn't respond to that.
Current OsmoBSC master will fail this test, and that's exactly why we
need it.
Change-Id: I800168499c2ab30af72625aba6fc740bc16e5653
Related: OS#3333
This test establishes an SDCCH for each iteration. However,
* due to OS#3333, osmo-bsc is currently not properly releasing those
lchan's,
* due to OS#3222, we furthermore don't allocate "larger" channels like TCH
and as a result on a combined CCCH system we only have 4 SDCCH, which
is less than the 8 that we try to use here.
Change-Id: I0f7fff54248a505387bdfe105259e8ad10ce6c77
Related: OS#3333
Related: OS#3332
For each of the SCCP/BSSMAP connections we create, let's make sure we
use a different RA and frame number, to make sure the test is more
realistic, and to aid any debugging.
Change-Id: I35540979c38d46f03702812e93742d7db772c533
While osmo-bsc was still affected of OS#3331, it would release the SCCP
connection from the BSC side. This is illegal as per 3GPP spec and
has meanwhile been fixed in osmo-bsc master. However, the testcase
BSC_Tests_LCLS.TC_lcls_connect_clear() relied on the broken behavior,
let's fix that.
The testcase now releases the SCCP connection from the simulated MSC
side in response to the BSSMAP Clear Complete from the BSC.
Change-Id: Ic3e1f8729a093b04941ec7ca72664d53adb21229
The existing test simply sent 1000 messages via RSL without checking
what actually arrived on the radio interface, or without
expecting/counting any RSL DELETE IND.
Let's fix this by introducing test sending IMM.ASS at three different
rates, with related expectations in terms of nubmer of IMM.ASS arriving
on Um vs. RSL DELETE IND arriving at BSC.
Change-Id: Ib6043b76ba1d7aaff107bb612f63b5a747d8720c
Related: OS#2990
Related: SYS#2695
The idea of this testcase is to check if MSC can correctly
handle a USSD-request during an active call.
What we do here:
1) Perform Location Update
2) Establish a MT-call
3) Perform *#100# request
4) Release the call
Change-Id: Ifa3cd1aeeb34ccf5864f78b76a88aaa6d5e51839
The idea of this testcase is to check reaction of the network on
reception of USSD request with unknown/unhandled request code.
It is not clearly defined by the GSM specs, how the network
should react in such cases, but looking at GSM TS 04.80,
section 4.3.2 "Error types description", the UnexpectedDataValue
error looks suitable. Commercial networks also use this error
when an unknown request code is sent.
Change-Id: I6a3fcaafc37972a38c13722f0b511ea5e1e3fbd8